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

[Felix]

Am 22-Dec-17 um 08:25 schrieb niftybunny:
> Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I
> need 2 xeons to push 30 mbit as a guard/middle …

Do you want to share some information:

Type i)
(memory exhaustion by too many circuits)
What is the memory(top) per tor and its MaxMemInQueues ?
How many circuits per hour in log ?

Type ii)
(cpu exhaustion by too many 'half open' tor connections)
Is your number of open files normal (fw in place) and moderate
connection counts per remote IP ?

Type iii)
(One fills your server with too many long fat pipes, first ACK and RTT)
If on Freebsd, is "mbuf clusters in use" (netstat -m) moderate ?
Do you get "kern.ipc.nmbclusters limit reached" in messages ?

-- 
Cheers, Felix
___
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

[niftybunny]

Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I need 2 
xeons to push 30 mbit as a guard/middle …

Markus


> On 22. Dec 2017, at 00:25, teor  wrote:
> 
> 
> On 22 Dec 2017, at 10:08, Roger Dingledine  wrote:
> 
 (Connection refused; CONNECTREFUSED; count 18; recommendation warn;
 host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443)
 
 So - I get loads of CONNECTREFUSED whilst coming up (presumably because
 of the attack) and then come fully back online. 
>> 
>>> IMO your tor searches for guards and they are under load, gone or lost
>>> their guard flag. Finally you found a guard :)
>> 
>> Yes, I agree. (Though if they were gone or lost their guard flag,
> 
> Gone, yes.
> 
> But don't client circuits try previously selected guards, even if they don't
> have the guard flag right now?
> (I know we don't re-weight guards as new consensuses arrive. I don't know
> if we ignore them once they lose the guard flag.)
> 
>> you
>> would not have tried them and gotten a CONNECTREFUSED. So I think they
>> are all suffering from the "under load" case. Gosh.)
> 
> Yes, this is probably a lack of file descriptors, and new connections are
> punished more severely than existing ones.
> 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] Become a Fallback Directory Mirror

[Aneesh Dogra]

D8972986BE19E0287770DF51C47C630A53DC6E97

Thanks
-Aneesh

On Fri, Dec 22, 2017 at 4:51 AM, Franklin Bynum 
wrote:

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



-- 
Regardless, I hope you're well and happy -
Aneesh
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] IPv6 Issue with Relay

[Conrad Rockenhaus]

Thank you. It’s always the small things, huh? :D

Conrad

> On Dec 21, 2017, at 6:12 PM, teor  wrote:
> 
> 
>> On 22 Dec 2017, at 09:13, Conrad Rockenhaus  wrote:
>> 
 I’ve confirmed that the following entries are in torrc:
 
 ORPort 9001
 ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001
 IPv6Exit 1
>>> ...
>>> Also, you have set IPv6Exit, but Relay Search says:
>>> 
>>> IPv6 Exit Policy Summary
>>> reject
>>> 1-65535
>>> 
>> 
>> Exactly. If I have torrc set to the defaults, what’s going on here?
> 
> You did not set "IPv6Exit 1" in the torrc you attached to your last
> email.
> 
> I opened this ticket so we include IPv6Exit in the torrc templates:
> https://trac.torproject.org/projects/tor/ticket/24703
> 
> T
> 
> --
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> xmpp: teor at torproject dot org
> 
> 
> 
> 
> ___
> 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] IPv6 Issue with Relay

[teor]

> On 22 Dec 2017, at 09:13, Conrad Rockenhaus  wrote:
> 
>>> I’ve confirmed that the following entries are in torrc:
>>> 
>>> ORPort 9001
>>> ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001
>>> IPv6Exit 1
>> ...
>> Also, you have set IPv6Exit, but Relay Search says:
>> 
>> IPv6 Exit Policy Summary
>> reject
>> 1-65535
>> 
> 
> Exactly. If I have torrc set to the defaults, what’s going on here?

You did not set "IPv6Exit 1" in the torrc you attached to your last
email.

I opened this ticket so we include IPv6Exit in the torrc templates:
https://trac.torproject.org/projects/tor/ticket/24703

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






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 22 Dec 2017, at 10:08, Roger Dingledine  wrote:

>>> (Connection refused; CONNECTREFUSED; count 18; recommendation warn;
>>> host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443)
>>> 
>>> So - I get loads of CONNECTREFUSED whilst coming up (presumably because
>>> of the attack) and then come fully back online. 
> 
>> IMO your tor searches for guards and they are under load, gone or lost
>> their guard flag. Finally you found a guard :)
> 
> Yes, I agree. (Though if they were gone or lost their guard flag,

Gone, yes.

But don't client circuits try previously selected guards, even if they don't
have the guard flag right now?
(I know we don't re-weight guards as new consensuses arrive. I don't know
if we ignore them once they lose the guard flag.)

> you
> would not have tried them and gotten a CONNECTREFUSED. So I think they
> are all suffering from the "under load" case. Gosh.)

Yes, this is probably a lack of file descriptors, and new connections are
punished more severely than existing ones.
T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Become a Fallback Directory Mirror

[Franklin Bynum]

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

[tor-relays] first impression with 0.3.2.8-rcant a fast exit relay

[Toralf Förster]

With 0.3.2.7-rc the command
/usr/sbin/iftop -B -i eth0 -P -N -n -m 320M
showed every then and when (few times in a hour) for 10-20 sec a traffic value 
of nearly 0 bytes for the short-term period (the left of the 3 values).
Usuaally I do poberve between 6 and 26 MByte/sec.
With the Tor version from today now the outage is about 1-2 sec, but does still 
occur.
Not sure, if this is an expected behaviour or a local problem.

-- 
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] Recent wave of abuse on Tor guards

[Roger Dingledine]

On Thu, Dec 21, 2017 at 10:11:47PM +0100, Felix wrote:
> It's currently good to be restrictive. May-be a *per ip* limit of 20
> (slow DoS) and a *per ip* rate of 1 per sec (fast DoS) is good.

I'm getting up to speed on this issue (been absent for some days).

My current thought is that these are actually Tor clients, not intentional
denial-of-service attacks, but there are millions of them so they are
producing surprises and damage. (Also, maybe there is not a human behind
each of the Tor clients, so maybe we shouldn't value them as much as we
would value more Tor Browser users.)

> I am on Freebsd

The Freebsd relays running Tor 0.3.2 will especially benefit from
today's 0.3.2.8-rc release, because bug 24671 only affects non-Linux or
ancient-Linux relays:

  o Minor bugfixes (scheduler, KIST):
- Use a sane write limit for KISTLite when writing onto a connection
  buffer instead of using INT_MAX and shoving as much as it can.
  Because the OOM handler cleans up circuit queues, we are better
  off at keeping them in that queue instead of the connection's
  buffer. Fixes bug 24671; bugfix on 0.3.2.1-alpha.

> > (Connection refused; CONNECTREFUSED; count 18; recommendation warn;
> > host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443)
> > 
> > So - I get loads of CONNECTREFUSED whilst coming up (presumably because
> > of the attack) and then come fully back online. 

> IMO your tor searches for guards and they are under load, gone or lost
> their guard flag. Finally you found a guard :)

Yes, I agree. (Though if they were gone or lost their guard flag, you
would not have tried them and gotten a CONNECTREFUSED. So I think they
are all suffering from the "under load" case. Gosh.)

--Roger

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

Re: [tor-relays] Become a Fallback Directory Mirror

[Anders Burmeister]

Hi Tim, Be my guest
775B0FAFDE71AADC23FFC8782B7BEB1D5A92733E
EFEACD781604EB80FBC025EDEDEA2D523AEAAA2F
484A10BA2B8D48A5F0216674C8DD50EF27BC32F3
1938EBACBB1A7BFA888D9623C90061130E63BB3F
Best Regards
Anders Burmeister

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: [tor-relays] Become a Fallback Directory Mirror
> Local Time: 21 December 2017 12:50 AM
> UTC Time: 20 December 2017 23:50
> From: teor2...@gmail.com
> To: tor-relays@lists.torproject.org
>
> 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
>
> ---
>
> ---
>
> 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] IPv6 Issue with Relay

[Conrad Rockenhaus]

On Dec 21, 2017, at 3:01 AM, teor  wrote:On 21 Dec 2017, at 16:33, Conrad Rockenhaus  wrote: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 9001ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001IPv6Exit 1Are these the only ORPort entries in your torrc?Have you restarted or HUP'd the relay since you last edited the torrc?Yes sir, I did. I see Atlas now shows that IPv6 is reachable, but the exit policy is rejecting everything. I have the reject policy in the torrc set to the defaults (I have all of the exit policies in torrc commented out).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 0x0This is what Relay Search (Atlas) says:Unreachable OR Addresses[2600:1f14:ede:d601:72c2:a87d:960d:c334]:9001The last 8 bytes of the address your relay is advertising,are not the same as the address on your machine.Also, you have set IPv6Exit, but Relay Search says:IPv6 Exit Policy Summaryreject1-65535Exactly. If I have torrc set to the defaults, what’s going on here?Relay Search data is usually up to 2.5 hours behind, but it can lag more.Please copy and paste the notice-level Tor logs that mention your ORPort,DirPort, and Exit settings, so we can see what Tor is actually doing.Dec 20 21:24:17.937 [warn] Tor is running as an exit relay with the default exit policy. If you did not want this behavior, please set the ExitRelay option to 0. If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility.Dec 20 21:24:17.937 [warn] In a future version of Tor, ExitRelay 0 may become the default when no ExitPolicy is given.Dec 20 21:24:17.937 [notice] Opening OR listener on 0.0.0.0:9001Dec 20 21:24:17.937 [notice] Opening OR listener on [2600:1f14:ede:d601:72c2:a87d:960d:c334]:9001Dec 20 21:24:17.938 [notice] Opening Directory listener on 0.0.0.0:9030I have confirmed that all of the applicable Security Group rules are configured correctly:Custom TCP RuleTCP90010.0.0.0/0ORPortCustom TCP RuleTCP9001::/0ORPortCustom TCP RuleTCP90300.0.0.0/0DIRPortCustom TCP RuleTCP9030::/0DIRPortBy the way, there are no IPv6 DirPorts :-)I know that now from reading the docs, I removed that rule :DPlus, 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.What are the exact commands you used?This shows that the relay is listening on whatever IPv6 address and portyou checked, but it doesn't show which IPv6 address the relay isadvertising.I just checked if it was listening with a telnet -6  9001, but this is a non-issue now since atlas shows it reachable.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.There are a few more detailed troubleshooting things we can try,like checking consensus health and the exact content of yourrelay's descriptor and the authorities' votes.If the above steps don't help, I'm happy to go through them later,when I'm using a more capable device.My main issue now is trying to fix the issue with the default exit policy - the logs say I’m running the defaults, yet all IPv6 traffic is getting blocked. I’ve looked over the documentation and I’ve done what it says. What am I doing wrong?Just for further troubleshooting, I attached this exit’s torrc file.Thanks,Rock

torrc
Description: Binary data
T___tor-relays mailing listtor-relays@lists.torproject.orghttps://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] Become a Fallback Directory Mirror

[John Ricketts]

Tim, 

Oh.. and

C5A53BCC174EF8FD0DCB223E4AA929FA557DEDB2


John L. Ricketts, Ph.D.
Quintex Alliance Consulting
(325) 262-3488 Cell/Signal




-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Wednesday, December 20, 2017 5:51 PM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Become a Fallback Directory Mirror

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


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

Re: [tor-relays] Become a Fallback Directory Mirror

[John Ricketts]

Tim,

0077BCBA7244DB3E6A5ED2746E86170066684887
041646640AB306EA74B001966E86169B04CC88D2
155D6F57425F16C0624D7641E4EB1B47C6F0
1AE949967F82BBE7534A3D6BA77A7EBE1CED4369
1DB25DF59DAA01B5BE3D3CEB8AFED115940EBE8B
1E5136DDC52FAE1219208F0A6BADB0BA62587EE6
2ED4D25766973713EB8C56A290BF07E06B85BF12
3687FEC7E73F61AC66F7AE251E7DEE6BBD8C0252
36D68478366CB8627866757EBCE7FB3C17FC1CB8
3CA0D15567024D2E0B557DC0CF3E962B37999A79
40E7D6CE5085E4CDDA31D51A29D1457EB53F12AD
43209F6D50C657A56FE79AF01CA69F9EF19BD338
54A4820B46E65509BF3E2B892E66930A41759DE9
5649CB2158DA94FB747415F26628BEC07FA57616
5F4CD12099AF20FAF9ADFDCEC65316A376D0201C
60D3667F56AEC5C69CF7E8F557DB21DDF6C36060
66E19E8C4773086F669A1E06A3F8C23B6C079129
764BF8A03868F84C8F323C1A676AA254B80DC3BF
7A3DD280EA4CD4DD16EF8C67B93D9BDE184D1A81
7E6E9A6FDDB8DC7C92F0CFCC3CBE76C29F061799
7FA8E7E44F1392A4E40FFC3B69DB3B00091B7FD3
8B80169BEF71450FC4069A190853523B7AEA45E1
9314BD9503B9014261A65C221D77E57389DBCCC1
9C1E7D92115D431385B8CAEA6A7C15FB89CE236B
9D21F034C3BFF4E7737D08CF775DC1745706801F
9E2D7C6981269404AA1970B53891701A20424EF8
9F2856F6D2B89AD4EF6D5723FAB167DB5A53519A
A0DB820FEC87C0405F7BF05DEE5E4ADED2BB9904
A4A393FEF48640961AACE92D041934B55348CEF9
B028707969D8ED84E6DEA597A884F78AAD471971
B0CD9F9B5B60651ADC5919C0F1EAA87DBA1D9249
B2197C23A4FF5D1C49EE45BA7688BA8BCCD89A0B
B6320E44A230302C7BF9319E67597A9B87882241
B7047FBDE9C53C39011CA84E5CB2A8E3543066D0
C78AFFEEE320EA0F860961763E613FD2FAC855F5
CB7C0D841FE376EF43F7845FF201B0290C0A239E
CC14C97F1D23EE97766828FC8ED8582E21E11665
CC4A3AE960E3617F49BF9887B79186C14CBA6813
D25210CE07C49F2A4F2BC7A506EB0F5EA7F5E2C2
D33292FEDE24DD40F2385283E55C87F85C0943B6
D6FF2697CEA5C0C7DA84797C2E71163814FC2466
DF20497E487A979995D851A5BCEC313DF7E5BC51
E480D577F58E782A5BC4FA6F49A6650E9389302F
EABC2DD0D47B5DB11F2D37EB3C60C2A4D91C10F2
EC15DB62D9101481F364DE52EB8313C838BDDC29
F21DE9C7DE31601D9716781E17E24380887883D1
F7447E99EB5CBD4D5EB913EE0E35AC642B5C1EF3
FDD700C791CC6BB0AC1C2099A82CBC367AD4B764
FE00A3A835680E67FBBC895A724E2657BB253E97


John L. Ricketts, Ph.D.
Quintex Alliance Consulting
(325) 262-3488 Cell/Signal


-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
teor
Sent: Wednesday, December 20, 2017 5:51 PM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Become a Fallback Directory Mirror

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


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

Hi,

You can block inbound connections if you like, but it's only a partial
mitigation for the attack.

> On 22 Dec 2017, at 06:42, mick  wrote:
> 
> So: My logs show Tor staying up for around 10 minutes at a time before
> rebooting with the following sort of entries:
> ...
> Dec 21 16:35:20.951
> [notice] Based on detected system memory, MaxMemInQueues is set to 369
> MB. You can override this by setting MaxMemInQueues by hand.

Please set MaxMemInQueues to the amount of free RAM available
to Tor, minus a few hundred megabytes for other data structures.

Please also increase the number of file descriptors available to Tor,
if possible on your system.

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

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

[David Goulet]

On 21 Dec (22:15:00), Felix wrote:
> > If you are running a relay version >= 0.3.2.x (currently 281 relays in the
> > network), please update as soon as you can with the latest tarball or latest
> > git tag.
> Update as well if HSDir is still present? The network might loose the
> rare ones.

If you are running 032, I will say yes. Now is a good time while we still have
~2000 HSDirs. With KIST scheduler and this latest release, your relay will be
more resilient to this DDoS.

With <= 031, setting the option and then HUP will work without restarting.

Thanks!
David

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

-- 
DMdcRweJVXVbzthX2gDiX2OwwF5dP4HgkREJLd+rUJM=


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] Ongoing DDoS on the Network - Status

[Felix]

> If you are running a relay version >= 0.3.2.x (currently 281 relays in the
> network), please update as soon as you can with the latest tarball or latest
> git tag.
Update as well if HSDir is still present? The network might loose the
rare ones.
-- 
Cheers, Felix
___
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

[Felix]

Hi mick

> And I run 0xbaddad - EA8637EA746451C0680559FDFF34ABA54DDAE831 a guard
> (though whether it stays a guard depends. It keeps falling over.)
Still guard


> (As an aside, I'd be very
> grateful for any feedback from other relay operators who /have/ added
> iptables "connlimit" rules. What is your view either way?)
It's currently good to be restrictive. May-be a *per ip* limit of 20
(slow DoS) and a *per ip* rate of 1 per sec (fast DoS) is good. I am on
Freebsd so I can not give you a good idea. May-be try what
tordoswitchhunter in [1] recomments (/32 is good). You have to harvest
your own hostile IPs :/


> So: My logs show Tor staying up for around 10 minutes at a time before
> rebooting with the following sort of entries:
> 
> Dec 21 16:25:44.000 [notice] Performing bandwidth self-test...done.
> Dec 21 16:35:20.000 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) opening
> log file. Dec 21 16:35:20.946 [notice] Tor 0.3.1.9
> (git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable,
> OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. Dec 21
> 16:35:20.947 [notice] Tor can't help you if you use it wrong! Learn how
> to be safe at https://www.torproject.org/download/download#warning Dec
> 21 16:35:20.947 [notice] Read configuration file
> "/usr/share/tor/tor-service-defaults-torrc". Dec 21 16:35:20.947
> [notice] Read configuration file "/etc/tor/torrc". Dec 21 16:35:20.951
> [notice] Based on detected system memory, MaxMemInQueues is set to 369
> MB. You can override this by setting MaxMemInQueues by hand. Dec 21
> 16:35:20.952 [notice] Opening Control listener on 127.0.0.1:9051 Dec 21
> 16:35:20.953 [notice] Opening OR listener on 0.0.0.0:9001 Dec 21
> 16:35:20.000 [notice] Not disabling debugger attaching for unprivileged
> users. Dec 21 16:35:21.000 [notice] Parsing GEOIP IPv4
> file /usr/share/tor/geoip. Dec 21 16:35:21.000 [notice] Parsing GEOIP
> IPv6 file /usr/share/tor/geoip6. Dec 21 16:35:22.000 [notice]
> Configured to measure statistics. Look for the *-stats files that will
> first be written to the data directory in 24 hours from now. Dec 21
> 16:35:22.000 [notice] Your Tor server's identity key fingerprint is
> '0xbaddad EA8637EA746451C0680559FDFF34ABA54DDAE831' Dec 21 16:35:22.000
> [notice] Bootstrapped 0%: Starting Dec 21 16:35:31.000 [notice]
> Starting with guard context "default" Dec 21 16:35:31.000 [notice]
> Bootstrapped 80%: Connecting to the Tor network Dec 21 16:35:31.000
> [notice] Signaled readiness to systemd Dec 21 16:35:31.000 [notice]
> Opening Control listener on /var/run/tor/control Dec 21 16:35:31.000
> [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 21
> 16:35:32.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing
> handshake with first hop. (Connection refused; CONNECTREFUSED; count
> 10; recommendation warn; host CD14AE63A02686BAE838A8079449B480801A8A5F
> at 195.181.208.180:443) Dec 21 16:35:32.000 [warn] 9 connections have
> failed: Dec 21 16:35:32.000 [warn]  9 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 11; recommendation
> warn; host 500FE4D6B529855A2F95A0CB34F2A10D5889E8C1 at
> 134.19.177.109:443) Dec 21 16:35:32.000 [warn] 10 connections have
> failed: Dec 21 16:35:32.000 [warn]  10 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 12; recommendation
> warn; host 3DE7762DD6165FD70C74BD02A6589C8C0C1B020A at
> 62.210.76.88:9001) Dec 21 16:35:32.000 [warn] 11 connections have
> failed: Dec 21 16:35:32.000 [warn]  11 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 13; recommendation
> warn; host 03DC081E4409631006EFCD3AF13AFAAF2B553FFC at
> 185.32.221.201:443) Dec 21 16:35:32.000 [warn] 12 connections have
> failed: Dec 21 16:35:32.000 [warn]  12 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 14; recommendation
> warn; host 51939625169E2C7E0DC83D38BAE628BDE67E9A22 at
> 109.236.90.209:443) Dec 21 16:35:32.000 [warn] 13 connections have
> failed: Dec 21 16:35:32.000 [warn]  13 connections died in state
> connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
> Problem bootstrapping. Stuck at 85%: Finishing handshake with first
> hop. (Connection refused; CONNECTREFUSED; count 15; recommendation
> warn; host 500FE4D6B529855A2F95A0CB34F2A10D5889E8C1 at
> 134.19.177.109:443) Dec 21 16:35:32.000 [warn] 14 connections have
> failed: Dec 

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

[David Goulet]

On 20 Dec (11:21:57), David Goulet wrote:
> 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.

Hi again everyone!

We've just released 0.3.2.8-rc that contains critical fixes in order for tor
to deal with the ongoing DDoS:

https://lists.torproject.org/pipermail/tor-talk/2017-December/043844.html

Packagers have been notified also so hopefully we might get them soonish.

If you are running a relay version >= 0.3.2.x (currently 281 relays in the
network), please update as soon as you can with the latest tarball or latest
git tag.

For the others still on <= 0.3.1.x, we do have a fix that hasn't been released
yet and we'll hopefully have more soon.

In the meantime, I will repeat the recommendation we have until we can roll up
more DoS defenses. If you are affected by this DDoS, set the MaxMemInQueues to
a value that reflects the amount of *available free* RAM your machine, not the
total amount of RAM.

For instance, if you have a server with 16GB of RAM but only 8GB are free,
setting the MaxMemInQueues value to or below 8GB is the wise thing to do until
this DDoS is resolved. Of course, the more you can offer the better!

The reason for this is to force "tor" to trigger its OOM (Out Of Memory
handler) before it is too late. This won't reduce the load but it will make
the relay stay alive, not go out of memory and hopefully stay in the
consensus.

Thanks everyone for your help!
David

-- 
DMdcRweJVXVbzthX2gDiX2OwwF5dP4HgkREJLd+rUJM=


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] Recent wave of abuse on Tor guards

[mick]

On Wed, 20 Dec 2017 17:22:54 +0100
fco...@wardsback.org allegedly wrote:

> Hi
> 
> I'm the happy maintainer of wardsback : 
> B143D439B72D239A419F8DCE07B8A8EB1B486FA7

And I run 0xbaddad - EA8637EA746451C0680559FDFF34ABA54DDAE831 a guard
(though whether it stays a guard depends. It keeps falling over.)
> 
> 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'm still looking at mitigation. I'd rather not add iptables filter
rules because it feels like the wrong thing to do (I might hurt
legitimate connections) and at the wrong end of the stack. I'd prefer
there to be mitigations available at the application end (Tor itself).
But realistically I know that that is difficult and the Tor developer
team are still working hard at this problem. (As an aside, I'd be very
grateful for any feedback from other relay operators who /have/ added
iptables "connlimit" rules. What is your view either way?)

I'm only sticking my head above the parapet now to note what I am
seeing.

So: My logs show Tor staying up for around 10 minutes at a time before
rebooting with the following sort of entries:

Dec 21 16:25:44.000 [notice] Performing bandwidth self-test...done.
Dec 21 16:35:20.000 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) opening
log file. Dec 21 16:35:20.946 [notice] Tor 0.3.1.9
(git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable,
OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2. Dec 21
16:35:20.947 [notice] Tor can't help you if you use it wrong! Learn how
to be safe at https://www.torproject.org/download/download#warning Dec
21 16:35:20.947 [notice] Read configuration file
"/usr/share/tor/tor-service-defaults-torrc". Dec 21 16:35:20.947
[notice] Read configuration file "/etc/tor/torrc". Dec 21 16:35:20.951
[notice] Based on detected system memory, MaxMemInQueues is set to 369
MB. You can override this by setting MaxMemInQueues by hand. Dec 21
16:35:20.952 [notice] Opening Control listener on 127.0.0.1:9051 Dec 21
16:35:20.953 [notice] Opening OR listener on 0.0.0.0:9001 Dec 21
16:35:20.000 [notice] Not disabling debugger attaching for unprivileged
users. Dec 21 16:35:21.000 [notice] Parsing GEOIP IPv4
file /usr/share/tor/geoip. Dec 21 16:35:21.000 [notice] Parsing GEOIP
IPv6 file /usr/share/tor/geoip6. Dec 21 16:35:22.000 [notice]
Configured to measure statistics. Look for the *-stats files that will
first be written to the data directory in 24 hours from now. Dec 21
16:35:22.000 [notice] Your Tor server's identity key fingerprint is
'0xbaddad EA8637EA746451C0680559FDFF34ABA54DDAE831' Dec 21 16:35:22.000
[notice] Bootstrapped 0%: Starting Dec 21 16:35:31.000 [notice]
Starting with guard context "default" Dec 21 16:35:31.000 [notice]
Bootstrapped 80%: Connecting to the Tor network Dec 21 16:35:31.000
[notice] Signaled readiness to systemd Dec 21 16:35:31.000 [notice]
Opening Control listener on /var/run/tor/control Dec 21 16:35:31.000
[notice] Bootstrapped 85%: Finishing handshake with first hop Dec 21
16:35:32.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing
handshake with first hop. (Connection refused; CONNECTREFUSED; count
10; recommendation warn; host CD14AE63A02686BAE838A8079449B480801A8A5F
at 195.181.208.180:443) Dec 21 16:35:32.000 [warn] 9 connections have
failed: Dec 21 16:35:32.000 [warn]  9 connections died in state
connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
Problem bootstrapping. Stuck at 85%: Finishing handshake with first
hop. (Connection refused; CONNECTREFUSED; count 11; recommendation
warn; host 500FE4D6B529855A2F95A0CB34F2A10D5889E8C1 at
134.19.177.109:443) Dec 21 16:35:32.000 [warn] 10 connections have
failed: Dec 21 16:35:32.000 [warn]  10 connections died in state
connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
Problem bootstrapping. Stuck at 85%: Finishing handshake with first
hop. (Connection refused; CONNECTREFUSED; count 12; recommendation
warn; host 3DE7762DD6165FD70C74BD02A6589C8C0C1B020A at
62.210.76.88:9001) Dec 21 16:35:32.000 [warn] 11 connections have
failed: Dec 21 16:35:32.000 [warn]  11 connections died in state
connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
Problem bootstrapping. Stuck at 85%: Finishing handshake with first
hop. (Connection refused; CONNECTREFUSED; count 13; recommendation
warn; host 03DC081E4409631006EFCD3AF13AFAAF2B553FFC at
185.32.221.201:443) Dec 21 16:35:32.000 [warn] 12 connections have
failed: Dec 21 16:35:32.000 [warn]  12 connections died in state
connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn]
Problem bootstrapping. Stuck at 85%: Finishing handshake with first
hop. (Connection refused; CONNECTREFUSED; count 14; recommendation
warn; host 51939625169E2C7E0DC83D38BAE628BDE67E9A22 at
109.236.90.209:443) Dec 21 16:35:32.000 [warn] 13 connections 

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

[Fabian A. Santiago]

On December 21, 2017 4:26:11 AM EST, Sebastian Hahn  
wrote:
>
>> On 20. Dec 2017, at 22:46, Fabian A. Santiago
> wrote:
 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.
>> 
>> That makes me sad, :-( ;-)
>
>It's the only sensible way Tor can try and limit the bandwidth usage.
>Someone repeatedly fetching the page could make you waste tons of
>bandwidth otherwise.
>
>Cheers
>Sebastian
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

I gotcha. That makes sense. No worries here. 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

[Sebastian Hahn]

> On 20. Dec 2017, at 22:46, Fabian A. Santiago  
> wrote:
>>> 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.
> 
> That makes me sad, :-( ;-)

It's the only sensible way Tor can try and limit the bandwidth usage.
Someone repeatedly fetching the page could make you waste tons of
bandwidth otherwise.

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

Re: [tor-relays] IPv6 Issue with Relay

[teor]

> On 21 Dec 2017, at 16:33, Conrad Rockenhaus  wrote:
> 
> 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

Are these the only ORPort entries in your torrc?
Have you restarted or HUP'd the relay since you last edited the torrc?

> 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

This is what Relay Search (Atlas) says:

Unreachable OR Addresses
[2600:1f14:ede:d601:72c2:a87d:960d:c334]:9001

The last 8 bytes of the address your relay is advertising,
are not the same as the address on your machine.

Also, you have set IPv6Exit, but Relay Search says:

IPv6 Exit Policy Summary
reject
1-65535

Relay Search data is usually up to 2.5 hours behind, but it can lag more.

Please copy and paste the notice-level Tor logs that mention your ORPort,
DirPort, and Exit settings, so we can see what Tor is actually doing.

> 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

By the way, there are no IPv6 DirPorts :-)

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

What are the exact commands you used?

This shows that the relay is listening on whatever IPv6 address and port
you checked, but it doesn't show which IPv6 address the relay is
advertising.

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

There are a few more detailed troubleshooting things we can try,
like checking consensus health and the exact content of your
relay's descriptor and the authorities' votes.

If the above steps don't help, I'm happy to go through them later,
when I'm using a more capable device.

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

Re: [tor-relays] IPv6 Issue with Relay

[Toralf Förster]

On 12/21/2017 06:33 AM, Conrad Rockenhaus wrote:
> Hello,
> 
> One of the relays that I brought online yesterday, ConradsAWSExit (Hash 
> 1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A) is showing up on Atlas that the 
> IPv6 OR is unreachable.
Just a guess:

IPv6 needs ICMPv6, so you should have something in your iptables like:
$IPT -A INPUT -p icmpv6 -j ACCEPT
depending on your INPUT policy.

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