Re: [tor-relays] connlimit: better to use "DROP" or "REJECT --reject-with tcp-reset"?

[teor]

> On 6 Jan 2018, at 06:05, Zack Weinberg  wrote:
> 
>> On Fri, Jan 5, 2018 at 1:44 PM, tor  wrote:
>> For relay operators using iptables connlimit to mitigate DoS attacks (or 
>> increased load from new clients), is it better for the Tor network to use 
>> "DROP" rules, or should we use something like "REJECT --reject-with 
>> tcp-reset"?
> 
> REJECT is friendlier to clients that are not misbehaving but happen to
> be caught in the crossfire, and to the Internet as a whole.
> 
> I personally think DROP should only ever be used as a desperation
> measure when the DoS load is so high that you can't even afford to
> send RSTs.

I've tried various ways of limiting Tor's RAM and CPU.
MaxAdvertisedBandwidth was effective, as was limiting Tor's file
descriptors and DisableOOSCheck 1. MaxMemInQueues had a minor impact.

So I decided to use a firewall to limit connections.

If I send RST, a Tor client will immediately try another guard.
If I DROP, the Tor client will timeout before trying another guard.

For misbehaving clients, I want to DROP.
For regular clients, I want to RST. (Or let them connect.)

So I want to set a high connection limit, and use DROP.

I see up to 700 connections per IP, and I see normal residential
IP addresses start at around 80. I don't think that clients with more
than 100 connections per IP will get much bandwidth anyway.

I used this command:

netstat -n | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c 
| sort -rn | head

All the connections over 100 were at Hetzner, OVH, and Leaseweb.
(This command gives /16s for IPv6, but these clients aren't
using IPv6.)

So I set up this firewall rule:

/sbin/iptables -A INPUT -p tcp --syn ! --dport 22 -m connlimit 
--connlimit-above 100 -j DROP

You should replace 22 with the list of ports you use for SSH and other
important connections, just in case.

And I installed iptables-persistent to save the rules.
(It might be Debian-specific).

After I set up the firewall, the connections slowly dropped from 700
down to around 100. It only affects new connections, so it might take
a while.

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] Combined relay and hidden service, good idea or not?

[Alain Wolf]

On 08.01.2018 23:59, Dave Warren wrote:
> On 2018-01-08 14:09, Tortilla wrote:
>>
>> On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
>>> On 2018-01-08 03:21, Florentin Rochet wrote:
> Perhaps in the case that the HS operator is not trying to mask the HS
> location, the act of mixing public relay traffic can be nothing but a
> *help* to defeat anyone trying to correlate traffic coming to the HS
> with
> traffic emanating from any one client.

 Yes, if the HS operator does not want to mask the HS location, then it
 is all good. For that purpose, I agree that the warning message should
 be changed.
>>>
>>> Indeed. I run some public resources (e.g. torproject.org mirror) on a
>>> public URL with a .onion site as well. Nothing is intended to be hidden,
>>> I simply want the content of anything I mirror to be available to Tor
>>> users without relying on an exit.
>>>

I think the real issue here is once more the wording "hidden service"
for something which is, in your case, not intended to be hidden.

I believe thats why the term "Onion Service" was introduced.

A foolproof solution would be, that a relay complains and refuses to
start if a "hidden onion service" is configured on the same instance.
But would run without warning with "public onion services".

I have no idea if a distinction between "public" and "hidden" onion
services is planned or if its just change of wording until now.


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

Re: [tor-relays] Updated Fallback Directory Mirrors

[Iain Learmonth]

Hi,

On 09/01/18 01:16, teor wrote:
> The FallbackDir flags on Consensus Health [2] have been updated.
> The flags on Relay Search (Atlas) [3] might take a few days to update.

Relay Search has now been updated.

Thanks,
Iain.



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] Combined relay and hidden service, good idea or not?

[Dave Warren]

On 2018-01-08 14:09, Tortilla wrote:


On Mon, January 8, 2018 11:25 am, Dave Warren wrote:

On 2018-01-08 03:21, Florentin Rochet wrote:

Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat anyone trying to correlate traffic coming to the HS
with
traffic emanating from any one client.


Yes, if the HS operator does not want to mask the HS location, then it
is all good. For that purpose, I agree that the warning message should
be changed.


Indeed. I run some public resources (e.g. torproject.org mirror) on a
public URL with a .onion site as well. Nothing is intended to be hidden,
I simply want the content of anything I mirror to be available to Tor
users without relying on an exit.

After an "abuse" report warning me that my hidden site is "leaking" its
location, my root robots.txt and a separate README file now both display
the public and .onion addresses with a note that nothing is intended to
be hidden. (I also appreciate the individual who sent the warning!)

On the flip side, to a new/naive hidden service operator the warning
could be useful as it may not be immediately obvious to someone just
dipping their toes in Tor as to why and how this configuration might
reveal their hidden service's real physical location.


Certainly!  I'm not new to Tor/HS and still got tripped up by this,
especially seeing the issue as having been closed, not having realized it
has not in fact been "fixed" and the only thing done was to add a startup
warning.  The issue really should be re-opened.  It's not unreasonable to
conclude that if the issue linked in the warning is closed that the
warning is obsolete.


I think the issue itself should be listed as WONTFIX, as this is simply 
a reality of how the internet works. Even if Tor didn't supply any relay 
statistics, a curious and enterprising individual could "explore" by 
seeing what happens to a particular onion when one launches a DoS attack 
against an external IP that one believes might be connected to the 
.onion service.


Notifying the administrator is sufficient, but I don't think an 
otherwise harmless log WARNING is sufficient to know that the 
administrator has been notified. Given that an administrator may not 
even review the logs if everything is functioning the way they expect, I 
would like to see something that forces the administrator to make a 
conscious choice.

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

Re: [tor-relays] what are these spikes

[teor]

> On 9 Jan 2018, at 09:44, Paul Templeton  wrote:
> 
> Hi all,
> 
> just a query - I get these unusual spikes on 
> https://atlas.torproject.org/#details/867B95CACD64653FEEC4D2CEFC5C49B4620307A7
>  (have a look at the three month chart) and I notice some of the other AU 
> relays do the same.
> 
> can anyone tell me what they are

Probably your relay becoming the HSDir for a large hidden service.
This extra load lasts for about a day.

It's more noticeable in under-loaded regions, because the relays don't
get as much client load.

We have a map of over-loaded and under-loaded regions now:
Go to https://atlas.torproject.org/#map
And select "consensus weight versus bandwidth".

T

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

[tor-relays] what are these spikes

[Paul Templeton]

Hi all,

just a query - I get these unusual spikes on 
https://atlas.torproject.org/#details/867B95CACD64653FEEC4D2CEFC5C49B4620307A7 
(have a look at the three month chart) and I notice some of the other AU relays 
do the same.

can anyone tell me what they are

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

Re: [tor-relays] Nyx reported speed

[John D. McDonnell]

Yeah, I've read the lifecycle of a new relay but since I'm running exits, I 
thought it might try to use more of my bandwidth by default. So I'm not sure if 
it's just the warmup period or if it's something I've misconfigured. I'm also 
not sure if it's just a limitation of the hardware I'm running on as well. I've 
repurposed a pair of Barracuda Spam Firewall 400's for the short depth 1u form 
factor, but I don't know if that's also a bottleneck on my speed as well.

CPU: AMD Sempron(tm) Processor 3400+ (1799.99-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x40ff2  Family=0xf  Model=0x4f  Stepping=2
  
Features=0x78bfbff
  Features2=0x2001
  AMD Features=0xea500800
  AMD Features2=0x19
real memory  = 4294967296 (4096 MB)

Only a 10/100 onboard NIC, but as I've only got a 25/5 internet connection that 
I'm sharing, that won't be a bottleneck.

I have an older model of the 400 that uses PATA on a RAID card that I 
previously used as a SQUID cache at home, but after sitting in storage for a 
couple years and moving from my old house to my new, it seems to no longer want 
to boot no matter what I toss at it, else I'd have 3 relays running by now.

(On a side note, if anyone has some spare hardware in a 1u short depth form 
that they'd like to donate, I'd be in the market! I've got 5 spare 25/5 
internet connections that we don't use and I've only got relays on 2 of them. 
lol)

But for now I guess I'll just go back to waiting to see if it's just the 
lifecycle limitations.

Thank you for clearing up what the monitor was showing me though. I feel a lot 
better knowing that I'm not averaging such a low speed.

--
John McDonnell

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Damian Johnson
Sent: Monday, January 8, 2018 3:45 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Nyx reported speed

Thanks John, glad to hear the average is more in line. Sorry if you're already 
aware of this but here's a nice read that might help...

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.torproject.org%2Flifecycle-new-relay=02%7C01%7C%7Ca65a30c231664c34ef2108d556d8b8da%7C4d0a72eeba2646d58bbe6430f01b636a%7C0%7C0%7C636510411169517477=mgGJR%2BSZo%2FxFO5tZnH%2FjtTob8QOu0lhNRHiaY5M4Gbg%3D=0

It can take a long while for the bandwidth authorities to warm up to relays. If 
you're seeing slack in a new-ish relay that's likely it.



Penn Cambria School District

This e-mail and any files transmitted with it are confidential and intended 
only for the person or entity to which it is addressed. If you have received 
this email in error, please notify the sender immediately via email and delete 
this email along with any attachments from your system. Any unauthorized or 
improper disclosure, copying, distribution, or use of the contents of this 
e-mail and attached documents is strictly prohibited. The views and opinions of 
this email or attachments are reflections of the author and are not necessarily 
the views and opinions of Penn Cambria School District. We do not accept 
responsibility or liability for any loss or damage from the receipt of this 
email, its use, or for any errors or omissions.

www.pcam.org

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

Re: [tor-relays] Combined relay and hidden service, good idea or not?

[Tortilla]

On Mon, January 8, 2018 11:25 am, Dave Warren wrote:
> On 2018-01-08 03:21, Florentin Rochet wrote:
>>> Perhaps in the case that the HS operator is not trying to mask the HS
>>> location, the act of mixing public relay traffic can be nothing but a
>>> *help* to defeat anyone trying to correlate traffic coming to the HS
>>> with
>>> traffic emanating from any one client.
>>
>> Yes, if the HS operator does not want to mask the HS location, then it
>> is all good. For that purpose, I agree that the warning message should
>> be changed.
>
> Indeed. I run some public resources (e.g. torproject.org mirror) on a
> public URL with a .onion site as well. Nothing is intended to be hidden,
> I simply want the content of anything I mirror to be available to Tor
> users without relying on an exit.
>
> After an "abuse" report warning me that my hidden site is "leaking" its
> location, my root robots.txt and a separate README file now both display
> the public and .onion addresses with a note that nothing is intended to
> be hidden. (I also appreciate the individual who sent the warning!)
>
> On the flip side, to a new/naive hidden service operator the warning
> could be useful as it may not be immediately obvious to someone just
> dipping their toes in Tor as to why and how this configuration might
> reveal their hidden service's real physical location.

Certainly!  I'm not new to Tor/HS and still got tripped up by this,
especially seeing the issue as having been closed, not having realized it
has not in fact been "fixed" and the only thing done was to add a startup
warning.  The issue really should be re-opened.  It's not unreasonable to
conclude that if the issue linked in the warning is closed that the
warning is obsolete.

> I avidly dislike warnings appearing in my logs that I intend to ignore,
> I would prefer to see this be controlled by a preference in torrc,
> either by an option to disable the warning, or better, require an
> explicit switch to be set before tor will act as both a relay and a
> hidden service. By making a "allow both HS and relay function" switch
> that is disabled by default, we could place appropriate comments in the
> default torrc file which explain the risks.

Absolutely agree -- at least if the intention is not to fix the
information leak.  Less careful HS operators may never even see the
warning.  Tor should probably refuse to start without explicit permission
to act as a relay while hosting a HS.


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

Re: [tor-relays] Combined relay and hidden service, good idea or not?

[Tortilla]

On Mon, January 8, 2018 2:21 am, Florentin Rochet wrote:
> Hey Tortilla,
>
> Sorry for the late reply:
>
> On 2018-01-05 21:13, Tortilla wrote:
>>> The issue is fixed by adding the above warning message: if you care
>>> about your hidden service's "hidden" property, do not run a relay on
>>> the
>>> same process.
>> Would you mind elaborating?  As I read the tracker link, the issue was
>> an
>> informational leak in bandwidth reporting that has now been solved and
>> closed.  As such, the startup warning is misleading unless there are
>> other
>> concerns (such as Igor's below) and in which case, the warning should be
>> re-worded.  Why do you say it is *fixed* by adding a warning?
>
> https://trac.torproject.org/8742 issue is already a stronger concern
> than Igor's point, and there are more. The informational leak in
> bandwidth is still there today, since these measurements are public. The
> issue is marked as fixed because, if you do relay+HS, you got a warning
> "not secure" that links to a possible attack (#8742) to recover your
> HS's location.
>
> To be honest, I don't really get why you feel that the startup warning
> is misleading. Is it because it links a fixed and closed trac issue?

Now I understand.  The misunderstanding was because the description of the
issue lists three "Possible solutions," none of which include merely
adding a startup warning and punting on the real solution.  And yes,
because the issue is marked as closed.  Seems a little weak to consider
the issue closed, at least IF it's not considered impossible due to other
design constraints, and the comments on the issue don't give that
impression.

So I had assumed that with the issue being closed, one of the "Possible
solutions" had been implemented and the information was no longer being
leaked.  I do think it's pretty important for people reading that startup
warning and following the link to see that the issue is in fact NOT fixed.

Whoever has permission to do so really should re-open the issue!

Thanks for your other comments, Florentin.

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

Re: [tor-relays] Nyx reported speed

[Damian Johnson]

Thanks John, glad to hear the average is more in line. Sorry if you're
already aware of this but here's a nice read that might help...

https://blog.torproject.org/lifecycle-new-relay

It can take a long while for the bandwidth authorities to warm up to
relays. If you're seeing slack in a new-ish relay that's likely it.


On Mon, Jan 8, 2018 at 12:27 PM, John D. McDonnell  wrote:
> Sorry for top posting, but I don't have my mail client configured for a more 
> proper inline or bottom posting. (I did that when I first got here but was 
> forced to change it to appease my boss.)
>
> The average metric you are referring to is the one that is updated with the 
> bar graph correct? That one does show more promising numbers, but still 
> generally still tends to fall far short of my 500KB/s allocation. (Seems to 
> usually be from 70B/s to 250KB/s with bursts higher.) But if this is the 
> actual rates I'm getting, then I am going to have to assume I've either got 
> something configured wrong or my routers aren't allowing my servers to get up 
> to full speed. (Both are probably equally likely. lol)
>
> Thank you for clearing that up though, I've been quite perplexed by it 
> reporting only B/s instead of KB/s for the average.
>
> --
> John
>
> -Original Message-
> From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf 
> Of Damian Johnson
> Sent: Monday, January 8, 2018 3:10 PM
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] Nyx reported speed
>
> Sorry about the confusion! Nyx should be showing an average metric as well 
> which is based on the samplings it sees. *That* should be more helpful.
>
> Cheers! -Damian
>
>
> Penn Cambria School District
>
> This e-mail and any files transmitted with it are confidential and intended 
> only for the person or entity to which it is addressed. If you have received 
> this email in error, please notify the sender immediately via email and 
> delete this email along with any attachments from your system. Any 
> unauthorized or improper disclosure, copying, distribution, or use of the 
> contents of this e-mail and attached documents is strictly prohibited. The 
> views and opinions of this email or attachments are reflections of the author 
> and are not necessarily the views and opinions of Penn Cambria School 
> District. We do not accept responsibility or liability for any loss or damage 
> from the receipt of this email, its use, or for any errors or omissions.
>
> www.pcam.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] Become a Fallback Directory Mirror

[Spiros Andreou]

Normalcitizen: E51620B90DCB310138ED89EDEDD0A5C361AAE24E



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




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] Nyx reported speed

[John D. McDonnell]

Sorry for top posting, but I don't have my mail client configured for a more 
proper inline or bottom posting. (I did that when I first got here but was 
forced to change it to appease my boss.)

The average metric you are referring to is the one that is updated with the bar 
graph correct? That one does show more promising numbers, but still generally 
still tends to fall far short of my 500KB/s allocation. (Seems to usually be 
from 70B/s to 250KB/s with bursts higher.) But if this is the actual rates I'm 
getting, then I am going to have to assume I've either got something configured 
wrong or my routers aren't allowing my servers to get up to full speed. (Both 
are probably equally likely. lol)

Thank you for clearing that up though, I've been quite perplexed by it 
reporting only B/s instead of KB/s for the average.

--
John

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Damian Johnson
Sent: Monday, January 8, 2018 3:10 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Nyx reported speed

Sorry about the confusion! Nyx should be showing an average metric as well 
which is based on the samplings it sees. *That* should be more helpful.

Cheers! -Damian


Penn Cambria School District

This e-mail and any files transmitted with it are confidential and intended 
only for the person or entity to which it is addressed. If you have received 
this email in error, please notify the sender immediately via email and delete 
this email along with any attachments from your system. Any unauthorized or 
improper disclosure, copying, distribution, or use of the contents of this 
e-mail and attached documents is strictly prohibited. The views and opinions of 
this email or attachments are reflections of the author and are not necessarily 
the views and opinions of Penn Cambria School District. We do not accept 
responsibility or liability for any loss or damage from the receipt of this 
email, its use, or for any errors or omissions.

www.pcam.org

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

Re: [tor-relays] Nyx reported speed

[Damian Johnson]

Hi John, thanks for pointing this out! Just took a quick peek at the
source and the 'measured: x' comes from your relay's consensus entry.
On reflection though that's stupid of me since that's the bandwidth
authority weight which is a unit-less heuristic (baka!).

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2234

I should probably simply drop that from the interface. Filed a ticket
to remind me to do so...

https://trac.torproject.org/projects/tor/ticket/24832

Sorry about the confusion! Nyx should be showing an average metric as
well which is based on the samplings it sees. *That* should be more
helpful.

Cheers! -Damian



On Mon, Jan 8, 2018 at 10:56 AM, John D. McDonnell  wrote:
> I'm not sure if reporting is off or something isn't configured right or 
> whatever it could be, but when running nyx, it is telling me that the 
> measured rate is 229.0 B/s which to me, sounds ridiculously slow. Where is it 
> getting the measured rate from? Is it a calculation on how much data is 
> passing in a given time or some sort of speed test from another relay or 
> where? While I've used Tor off and on for several years, I never ran a relay 
> until now and I'm still not certain on several aspects, though I keep digging 
> to make sure I can supply the best exit relays I can. (I currently host 2 
> exit relays and hope to bring up 3 more in the near future if I can find 
> hardware to run them on. Though I may make one a bridge.)
>
> I have some spare internet connections that are provided to us that are 25/5 
> connections. I configured torrc with a 500KB/s limit with 600KB/s bursting as 
> this should work nicely to use ~4Mbps of the 5Mbps that the connection 
> supports and allows me some bandwidth to be able to connect to the machines 
> for monitoring and troubleshooting as well as more than enough bandwidth for 
> downloading updates and such.
>
> The line in nyx that I'm referring to is:
> Bandwidth (limit: 500 KB/s, burst: 600 KB/s, measured: 229.0 B/s):
> Where is it getting that 229.0 B/s rate and is there anything I can do to get 
> it closer to the 500KB/s I am trying to share.
>
> Granted, I am using a Linksys e1200 and Belkin something-or-other that I 
> can't remember off the top of my head running DD-WRT as routers in front of 
> the servers. (I've pondered removing the router and just connecting the 
> server directly to the internet and relying on pf for my firewalling, but I 
> can't do that at the one location as I also have a couple other things 
> connected to it. Both routers are higher end consumer routers with 32MB of 
> RAM and has 32768 for maximum ports. (Currently just under 3000 active IP 
> connections as I'm typing this e-mail.) I might just try this on my one exit 
> to see if this is the bottleneck I'm hitting or if there's something else 
> affecting it.
>
> When I had first put this in place, I was using an older Netgear ProVPN 
> router of some sort, but I swapped it out due to it flagging NTP traffic as 
> unknown even though my server was initiating the NTP requests. But I was 
> maintaining 200KB/s+ connections fairly consistently. It now ranges all over 
> the place and I'm not sure if that's an issue on my end or just part of the 
> lifecycle of a relay.
>
> I just recently rebooted the machine this happened to pop up in the nyx log 
> window as I was looking at this:
> 12:33:09 [NOTICE] Heartbeat: Tor's uptime is 4 days 23:59 hours, with 1928 
> circuits open. I've sent 37.89 GB and received 37.00 GB.
> To me, that seems a too low, but I've not sat down to do the math and maybe 
> that's a good statistic for 5 days at 4Mbps.
>
> I'd appreciate any tips and pointers you can send my way. And if the consumer 
> routers are the issue, I can move my one exit relay to one of the other 
> connections I have and not use it at the location (or just run one that's 
> slower) where I do use this backup internet connection. (It's handy to have a 
> network that's not part of our internal network for testing.)
>
> Thanks for sticking with me through this whole e-mail and I apologize for 
> rambling and jumping around a bit. I'm sure I left out some stuff and didn't 
> clarify something else or something wasn't clear, so if you need more 
> information, just ask.
>
> Thank you,
> John
>
>
> Penn Cambria School District
>
> This e-mail and any files transmitted with it are confidential and intended 
> only for the person or entity to which it is addressed. If you have received 
> this email in error, please notify the sender immediately via email and 
> delete this email along with any attachments from your system. Any 
> unauthorized or improper disclosure, copying, distribution, or use of the 
> contents of this e-mail and attached documents is strictly prohibited. The 
> views and opinions of this email or attachments are reflections of the author 
> and are not necessarily the views and opinions of Penn Cambria School 
> District. We do not 

Re: [tor-relays] Combined relay and hidden service, good idea or not?

[Dave Warren]

On 2018-01-08 03:21, Florentin Rochet wrote:

Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat anyone trying to correlate traffic coming to the HS with
traffic emanating from any one client.


Yes, if the HS operator does not want to mask the HS location, then it 
is all good. For that purpose, I agree that the warning message should 
be changed.


Indeed. I run some public resources (e.g. torproject.org mirror) on a 
public URL with a .onion site as well. Nothing is intended to be hidden, 
I simply want the content of anything I mirror to be available to Tor 
users without relying on an exit.


After an "abuse" report warning me that my hidden site is "leaking" its 
location, my root robots.txt and a separate README file now both display 
the public and .onion addresses with a note that nothing is intended to 
be hidden. (I also appreciate the individual who sent the warning!)


On the flip side, to a new/naive hidden service operator the warning 
could be useful as it may not be immediately obvious to someone just 
dipping their toes in Tor as to why and how this configuration might 
reveal their hidden service's real physical location.


I avidly dislike warnings appearing in my logs that I intend to ignore, 
I would prefer to see this be controlled by a preference in torrc, 
either by an option to disable the warning, or better, require an 
explicit switch to be set before tor will act as both a relay and a 
hidden service. By making a "allow both HS and relay function" switch 
that is disabled by default, we could place appropriate comments in the 
default torrc file which explain the risks.


Whether any of this really matters in the real world, I don't know, but 
getting the attention of an inexperienced operator before they make a 
privacy-reducing mistake seems like A Good Thing.

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

[tor-relays] Nyx reported speed

[John D. McDonnell]

I'm not sure if reporting is off or something isn't configured right or 
whatever it could be, but when running nyx, it is telling me that the measured 
rate is 229.0 B/s which to me, sounds ridiculously slow. Where is it getting 
the measured rate from? Is it a calculation on how much data is passing in a 
given time or some sort of speed test from another relay or where? While I've 
used Tor off and on for several years, I never ran a relay until now and I'm 
still not certain on several aspects, though I keep digging to make sure I can 
supply the best exit relays I can. (I currently host 2 exit relays and hope to 
bring up 3 more in the near future if I can find hardware to run them on. 
Though I may make one a bridge.)

I have some spare internet connections that are provided to us that are 25/5 
connections. I configured torrc with a 500KB/s limit with 600KB/s bursting as 
this should work nicely to use ~4Mbps of the 5Mbps that the connection supports 
and allows me some bandwidth to be able to connect to the machines for 
monitoring and troubleshooting as well as more than enough bandwidth for 
downloading updates and such.

The line in nyx that I'm referring to is:
Bandwidth (limit: 500 KB/s, burst: 600 KB/s, measured: 229.0 B/s):
Where is it getting that 229.0 B/s rate and is there anything I can do to get 
it closer to the 500KB/s I am trying to share.

Granted, I am using a Linksys e1200 and Belkin something-or-other that I can't 
remember off the top of my head running DD-WRT as routers in front of the 
servers. (I've pondered removing the router and just connecting the server 
directly to the internet and relying on pf for my firewalling, but I can't do 
that at the one location as I also have a couple other things connected to it. 
Both routers are higher end consumer routers with 32MB of RAM and has 32768 for 
maximum ports. (Currently just under 3000 active IP connections as I'm typing 
this e-mail.) I might just try this on my one exit to see if this is the 
bottleneck I'm hitting or if there's something else affecting it.

When I had first put this in place, I was using an older Netgear ProVPN router 
of some sort, but I swapped it out due to it flagging NTP traffic as unknown 
even though my server was initiating the NTP requests. But I was maintaining 
200KB/s+ connections fairly consistently. It now ranges all over the place and 
I'm not sure if that's an issue on my end or just part of the lifecycle of a 
relay.

I just recently rebooted the machine this happened to pop up in the nyx log 
window as I was looking at this:
12:33:09 [NOTICE] Heartbeat: Tor's uptime is 4 days 23:59 hours, with 1928 
circuits open. I've sent 37.89 GB and received 37.00 GB.
To me, that seems a too low, but I've not sat down to do the math and maybe 
that's a good statistic for 5 days at 4Mbps.

I'd appreciate any tips and pointers you can send my way. And if the consumer 
routers are the issue, I can move my one exit relay to one of the other 
connections I have and not use it at the location (or just run one that's 
slower) where I do use this backup internet connection. (It's handy to have a 
network that's not part of our internal network for testing.)

Thanks for sticking with me through this whole e-mail and I apologize for 
rambling and jumping around a bit. I'm sure I left out some stuff and didn't 
clarify something else or something wasn't clear, so if you need more 
information, just ask.

Thank you,
John


Penn Cambria School District

This e-mail and any files transmitted with it are confidential and intended 
only for the person or entity to which it is addressed. If you have received 
this email in error, please notify the sender immediately via email and delete 
this email along with any attachments from your system. Any unauthorized or 
improper disclosure, copying, distribution, or use of the contents of this 
e-mail and attached documents is strictly prohibited. The views and opinions of 
this email or attachments are reflections of the author and are not necessarily 
the views and opinions of Penn Cambria School District. We do not accept 
responsibility or liability for any loss or damage from the receipt of this 
email, its use, or for any errors or omissions.

www.pcam.org

___
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

[Otheontelth]

Fingerprint:
A2A6616723B511D8E068BB71705191763191F6B2
Address:
87.118.122.120:443

>  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] Become a Fallback Directory Mirror

[Anders Burmeister]

Hi
Added two new members to my family

92412EA1B9AA887D462B51D816777002F4D58907
360CBA08D1E24F513162047BDB54A1015E531534

They are few days old and about to be confirmed.

Best regards
Anders

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

>  Original Message 
> Subject: Re: [tor-relays] Become a Fallback Directory Mirror
> Local Time: 4 January 2018 1:39 PM
> UTC Time: 4 January 2018 12:39
> From: r.c.la...@gmail.com
> To: tor-relays@lists.torproject.org
>
> Hi,
>
> I have
>
> 4E8CE6F5651E7342C1E7E5ED031E82078134FB0D
>
> running both on IPv4 and IPv6. There seems (seemed?) to be a bit of a 
> disagreement between authority servers when voting for the stable flag 
> regarding IPv6, but manual checks always were fine.
>
> René
>
> 2017-12-21 0:50 GMT+01:00 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
>> 
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> --
> https://rene-ladan.nl/___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] *BSD bridge operators

[Vinícius Zavam]

2018-01-08 1:15 GMT+00:00 George :
>
> For anyone running *BSD bridges that wasn't aware, there are obfs4proxy
> packages/ports available for each of the BSDs:
>
> FreeBSD as security/obfs4proxy-tor
>
> NetBSD as net/obfs4proxy
>
> OpenBSD as net/obfs4proxy
>
> DragonFlyBSD as security/obfs4proxy-tor
>
> For assisting aggressively censored users, bridges really should
> consider configuring obf4sproxy.
>
> g
>
> --
>
>
> 34A6 0A1F F8EF B465 866F F0C5 5D92 1FD1 ECF6 1682

I would also like to bring more info from the torbsd's mailing list;
+ http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000619.html


--
Vinícius Zavam
keybase.io/egypcio/key.asc
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Combined relay and hidden service, good idea or not?

[Florentin Rochet]

Hey Tortilla,

Sorry for the late reply:

On 2018-01-05 21:13, Tortilla wrote:

The issue is fixed by adding the above warning message: if you care
about your hidden service's "hidden" property, do not run a relay on the
same process.

Would you mind elaborating?  As I read the tracker link, the issue was an
informational leak in bandwidth reporting that has now been solved and
closed.  As such, the startup warning is misleading unless there are other
concerns (such as Igor's below) and in which case, the warning should be
re-worded.  Why do you say it is *fixed* by adding a warning?


https://trac.torproject.org/8742 issue is already a stronger concern 
than Igor's point, and there are more. The informational leak in 
bandwidth is still there today, since these measurements are public. The 
issue is marked as fixed because, if you do relay+HS, you got a warning 
"not secure" that links to a possible attack (#8742) to recover your 
HS's location.


To be honest, I don't really get why you feel that the startup warning 
is misleading. Is it because it links a fixed and closed trac issue?






The part "cannot easily run an analysis targeted at a hidden service"
looks just wrong to me. If you want an example of an active attacker
able to easily uncover such a hidden service (when mixed with a relay),
you can give a look at our paper "Dropping on the Edge: Flexibility and
Traffic Confirmation in Onion Routing Protocols" [1] (to appear in
PoPETs18). The techniques presented are not applied on that particular
setup, but this is somewhat trivial to do.

I believe the logic was that if a machine is identified in some way as one
to watch, and if it is seen participating in the Tor network but is not
listed as a public relay, it's easier to conclude that it may be hosting a
hidden service, after which other correlation attacks can be targeted at
the machine.  Thus, the recommendation that running a public relay helps
mask HS traffic.

Perhaps in the case that the HS operator is not trying to mask the HS
location, the act of mixing public relay traffic can be nothing but a
*help* to defeat anyone trying to correlate traffic coming to the HS with
traffic emanating from any one client.


Yes, if the HS operator does not want to mask the HS location, then it 
is all good. For that purpose, I agree that the warning message should 
be changed.




Forgive me for only skimming your paper, but I didn't see any explanation
that the attack outlined was either facilitated or enhanced by the HS also
running a relay.  Would you mind commenting?


Ok, so suppose a public relay and a hidden service running on the same 
process, and the attacker knows the onion address. The hidden service's 
location can be uncovered using public bandwidth leaks of the relay. 
Just do the following trick: send a few GB of trash data to the hidden 
service using the kind of method described in the paper. Then, wait that 
the public measurements are updated and look for the relay having a few 
more GB of read data than write data. You should obtain only one IP. 
Congrats, it's the IP of the hidden service.


So, if you care about your HS's hidden location, do not run a relay on 
the same process :-)


Best,
Florentin


___
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