Re: [tor-relays] AS awareness

[Tobias Sachs]

Hey folks!

How about trying it with /8 and if that fails falling back to /16. 

Is it possible to set the limit to /14 /12 or maybe /10?

And Conrad, the main concern is mostly like in my case to get kicked out while 
you still have production systems running or the worst case a police raid. 

Best Regards
Tobias

> Am 02.08.2018 um 08:05 schrieb  
> :
> 
> I did want to note one thing about these big ASes... sure, they may be big 
> ASes, but they are still lacking in one major area - Exits.
> 
> OVH has almost 4.5 Gbit/s of relay bandwidth available within the AS. 
> However, if you search for exits, that rapidly drops to just under 750 mbit/s.
> 
> I'm more than positive all of the other big ASes are the same way.
> 
> A little off topic, but it just amazes me how much exit capacity these sites 
> actually have, but people aren't willing to sign up for services whose TOS 
> permits running an exit (or can't afford it), so they run a relay at an 
> overly saturated site.
> 
> Thanks,
> 
> Conrad
> 
> --
> Conrad Rockenhaus
> Fingerprint: 8049 CDBA C385 C451 3348 776D 0F72 F2B5 26DA E93F
> Public Key: 
> https://pgp.key-server.io/pks/lookup?op=get&search=0x0F72F2B526DAE93F
> https://www.rockenhaus.com
> --
> Get started with GreyPony Anonymization Today!
> https://www.greyponyit.com
> 
> -Original Message-
> From: tor-relays  On Behalf Of nusenu
> Sent: Sunday, July 29, 2018 4:43 PM
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] AS awareness
> 
> 
> 
> Mirimir:
>> On 07/29/2018 02:26 PM, nusenu wrote:
> If I know the relays IP I could give you the probabilities of your 
> relay relaying traffic to others in the same AS (since a relay will 
> usually not be used with others in the same /16 netblock)
 
 It'd be better for relays to avoid connecting within an AS, right?
>>> 
>>> better according to what metric?
>> 
>> Risk of coordinated compromise.
> 
> that is a very generic and short description
> 
> 
> 
> --
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
> 
> 
> ___
> 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] Strange Traffic behaviour

[Tobias Sachs]

Hi!



> Am 29.07.2018 um 00:51 schrieb Roger Dingledine :
> 
> On Sat, Jul 28, 2018 at 07:59:08PM +0200, Tobias Sachs wrote:
>> Hibernation is set to 19 TB???s of outgoing Traffic. Hetzner Cloud shows 
>> ~16TB outgoing traffic and the relays log itself 38TB.
> 
> Can you give us your actual torrc lines?
> 
Log notice file /var/log/tor/notices.log
RunAsDaemon 1

ORPort 443
ORPort [2a01:4f8:1c1c:af5::1]:443

Nickname GermanCraft3

RelayBandwidthRate 100 MBits
RelayBandwidthBurst 200 MBits

AccountingMax 19TB
AccountingStart month 1 00:00
AccountingRule out

ContactInfo 4096R/0x4cf76925833e2e24 Knight  - 
1MTXtuSCCTf6J3TiUnk1ePwgaHt9h6uQaU

DirPort 80

ExitPolicy reject *:*
ExitPolicy reject6 *:*

> Also, how about the log lines, particularly the ones that talk about

> when it woke up, when it went into hibernation, when it plans to wake
> up again, etc?

Jul 29 06:25:01.000 [notice] Configured hibernation.  This interval began at 
2018-07-01 00:00:00; the scheduled wake-up time was 2018-07-01 07:27:40; we 
expect to exhaust our quota for this interval around 2018-07-31 23:32:40; the 
next interval begins at 2018-08-01 00:00:00 (all times local)

> 
>> vnstat reports exactly 20.38 TiB tx so in conclusion Hetzner can not count 
>> there Bits and Bytes or the same as protection is not correct.
> 
> Maybe some of these transmitted bytes went to other Hetzner servers,
> which they don't count as "really" sending bytes to the Internet.
> 
>> Because if Hetzner???s stats are correct i would have send 3 TB???s of 
>> Traffic to other Tor servers and clients internally. Because internal 
>> traffic is not counted.
> 
> Ah, yes, this is what you suggested. Maybe? That's a lot (a large
> fraction) given that Hetzner doesn't have that large a fraction of the
> Tor network these days.
> 
>> I guess that a Juniper routers net flow tool is correct so how can i look at 
>> this? Because my second relay in Helsinki does have this too with a 
>> difference of 2 TB???s.
>> 
>> "Heartbeat: Tor's uptime is 27 days 1:39 hours, with 0 circuits open. I've 
>> sent 38486.76 GB and received 38489.42 GB. We are currently hibernating.???
>> 
>> When i divide that by two this gives me 19 TB???s of outgoing Traffic. So i 
>> guess that this is a bug?
> 
> Tor said you sent 38TB, so that's 38TB of outgoing traffic.
> 
> Maybe your 27 days contained two hibernation periods? That would be
> one possible explanation for 19+19=38.
> 
> —Roger

> Hetzner hosts > 7% of the tor network capacity (#3 on the biggest ASes on the 
> tor network).
> 
> If I know the relays IP I could give you the probabilities of your relay
> relaying traffic to others in the same AS (since a relay will usually not
> be used with others in the same /16 netblock)

So that means the same-as protection is a check that it is not the same /16 
Block? That would make sense.

https://bgp.he.net/AS24940#_prefixes <https://bgp.he.net/AS24940#_prefixes>

Hetzner is holding 17 /16 and smaller netblocks. So it is possible that the 
complete route is within one AS? o.O

The IP is: 159.69.2.239

Thanks for your help!

Tobias




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

[tor-relays] Strange Traffic behaviour

[Tobias Sachs]

Hey folks!

My relay which is currently hibernating shows something strange.

Hibernation is set to 19 TB’s of outgoing Traffic. Hetzner Cloud shows ~16TB 
outgoing traffic and the relays log itself 38TB.
vnstat reports exactly 20.38 TiB tx so in conclusion Hetzner can not count 
there Bits and Bytes or the same as protection is not correct.
Because if Hetzner’s stats are correct i would have send 3 TB’s of Traffic to 
other Tor servers and clients internally. Because internal traffic is not 
counted.
I guess that a Juniper routers net flow tool is correct so how can i look at 
this? Because my second relay in Helsinki does have this too with a difference 
of 2 TB’s.

"Heartbeat: Tor's uptime is 27 days 1:39 hours, with 0 circuits open. I've sent 
38486.76 GB and received 38489.42 GB. We are currently hibernating.“

When i divide that by two this gives me 19 TB’s of outgoing Traffic. So i guess 
that this is a bug?

Thanks!
Tobias


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] Alternative hoster (Re: DigitalOcean bandwidth billing changes)

[Tobias Sachs]

The interesting thing about Hetzer is that only outgoing traffic is counted 
towards the billing.
So we can set up 38 TB of Traffic just to be on the safe side here.

And the price is unbeatable at this time.

My current mod: https://twitter.com/Knight1/status/988868691868749825 


Tobias

> Am 25.04.2018 um 15:49 schrieb Ralph Seichter :
> 
> On 25.04.18 15:38, Nagaev Boris wrote:
> 
>>> Also, 20 GB monthly traffic allowance are Nice™.
>> 
>> * 20 TB
> 
> Argh! Of course I once again meant TB. :-)
> 
> A word of caution for Tor exits, though: Hetzner allows exit nodes, but
> they are very strict when it comes to potential abuse. If one does not
> react quickly enough, network access is automatically suspended.
> 
> For example, reaction time gets shorter with each repeated report of
> network scans originating from Hetzner IP addresses, down to only a
> few hours. If you happen to be asleep at the time: tough. ;-)
> 
> -Ralph
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



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] seized relays reported for blacklisting?

[Tobias Sachs]

Hey,

any idea how to avoid the guard flag at this time?
My only idea is to trottle down the speed but this is a bad solution imho.

I don't want to shut it down but maybe they were smart enough to think
about what they did? :D

Thanks!
Tobias


Am 20.05.2017 um 01:00 schrieb nusenu:
> if your relay is on this list and has no comment in the last column,
> please let us know.
>
> the goal would be to have a seized/not seized comment in each row.
>
> https://gist.github.com/nusenu/3d7bbeb7c97af591d65003b4bfe70021
>
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



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] Call for Tor Fallback Directories

[Tobias Sachs]

Hey teor,

my relay 5665A3904C89E22E971305EE8C1997BCA4123C69 is according to your log [4] 
black and whitelisted. But it is only in the whitelist from you [1]
My second relay B567E8E39641F61091C1F2CAAAF73D3D1BF9CFE1 is according to [4] 
blacklisted but also not in [2].

I hope you can clarify this out.

Best Regards
Tobias



Am 04.12.2016 um 11:44 schrieb teor:
> Dear Tor Relay Operator,
>
> Your relay(s) can help tor clients find the tor network by becoming a
> fallback directory mirror.[0]
>
> These mirrors are hard-coded into tor's source code, like the directory
> authorities. We have 80 fallbacks, but we want 200 for the next release.
>
> Fallbacks need to have:
> - the same IP address(es) and ports for the next 2 years,
> - the same relay identity key for the next 2 years,
> - good uptime (at least 95%), and
> - good bandwidth and network connectivity
>   (we estimate an extra 25GB per month).
>
> Please email me to add your relays that fit these criteria to the list.
> If you are BCC'd on this email, it looks like you have at least one
> relay that could become a fallback.
> You can also email me if you know your relay will be changing address
> or key, and I'll make sure we don't choose it.
>
> We are keeping the fallback lists from the last release[1][2].
>
> So if you have emailed me before about becoming a fallback, there is no
> need to email again. But please let me know if your relay details have
> changed.  (I did not BCC relay operators who are already on the fallback
> lists, unless their relay details changed.)
>
> In a week or two, I will run a script to select the hard-coded list for
> the release.
>
> If you're interested, here's some background to this request:
>
> The latest list[3] and log[4] of candidates was generated using the
> instructions in [5] from scripts/maint/updateFallbackDirs.py on my
> GitHub branch[6]. (This branch has some bug fixes compared to what's in
> master.) We're tracking this work in [7].
>
> [0]:
> https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
> [1]:
> https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/fallback.whitelist
> [2]:
> https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/fallback.blacklist
> [3]:
> https://trac.torproject.org/projects/tor/attachment/ticket/18828/potential_extra_fallbacks_2016-12-04
> [4]:
> https://trac.torproject.org/projects/tor/attachment/ticket/18828/potential_extra_fallbacks_2016-12-04.log
> [5]:
> https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
> [6]:
> https://github.com/teor2345/tor/blob/fallbacks-029-v2/scripts/maint/updateFallbackDirs.py
> [7]: https://trac.torproject.org/projects/tor/ticket/18828
>
> T
>
> > ___ > tor-relays mailing
list > tor-relays@lists.torproject.org >
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


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

Re: [tor-relays] Tor relay balks with "router_pick_published_address(): Success: chose address x.x.x.x"

[Tobias Sachs]

>> On 9 Nov. 2016, at 09:00, Tobias Sachs  wrote:
>>
>> Hey,
>>
>> my Tor relay
>> https://atlas.torproject.org/#details/B567E8E39641F61091C1F2CAAAF73D3D1BF9CFE1
>> balks with the following message which is repeated in the log with the
>> "info" logging level up to 23251 times at the exact same millisecond.
> I assume you are talking about the router_pick_published_address
> message.
>
>> The relay responds at :9030/tor/server/authority with a 503 error.
> This is a temporary error when your relay is overloaded.
>
> I just tried
> http://167.114.245.102:9030/tor/server/authority
> and it delivered the descriptor fine, with no error.
Yes but this is a rare case during the day
Event,Date-Time,Reason,Duration,"Duration (in mins.)"
Up,"2016-11-07 22:29:47","Keyword Found","25 hrs, 13 mins",1514
Down,"2016-11-07 22:28:30","Keyword Not Found","0 hrs, 1 mins",1
Up,"2016-11-07 22:23:29","Keyword Found","0 hrs, 5 mins",5
Down,"2016-11-07 22:22:05","Keyword Not Found","0 hrs, 1 mins",1
Up,"2016-11-06 13:56:42","Keyword Found","32 hrs, 25 mins",1945
Down,"2016-11-06 13:55:44","Keyword Not Found","0 hrs, 0 mins",1
Up,"2016-11-06 13:22:19","Keyword Found","0 hrs, 33 mins",33
Down,"2016-11-06 13:21:21","Keyword Not Found","0 hrs, 0 mins",1
Up,"2016-11-06 13:17:31","Keyword Found","0 hrs, 3 mins",4
Down,"2016-11-06 13:16:33","Keyword Not Found","0 hrs, 0 mins",1

I don't know it but htop was something strange. The cpu was yellow which
is not documented and on 100%. The tor process itself had 0.0% cpu but
still traffic. Maybe this was a bug which was related to some upstream
kernel / package bugs. I rebooted the vm with the latest kernel and the
issue is gone. I let you aware if uptimetobot and statuscake still sees
some 503 errors.

>
> I logged a ticket:
>
> Relays should log a message when they return a 503 error to a client
> https://trac.torproject.org/projects/tor/ticket/20611
>
>> router_pick_published_address(): Success: chose address 'x.x.x.x'
> This message is not an error, it is a success.
>
> But I can see how it would be annoying:
>
> Rate limit router_pick_published_address log message
> https://trac.torproject.org/projects/tor/ticket/20610
>
>> This is a counting from the log with the corresponding timestamp.
>>
>> Nov 01 18:37:13.000 - 23251
>> Nov 01 18:37:22.000 - 59
>> Nov 01 18:38:17.000 - 23195
>> Nov 01 18:38:22.000 - 57
>> Nov 01 19:19:22.000 - 50
>> Nov 01 19:19:23.000 - 312
>> Nov 01 19:19:24.000 - 333
>> Nov 01 19:19:25.000 - 74
>> Nov 01 19:20:22.000 - 52
>> Nov 01 19:38:17.000 - 23207
>> Nov 01 20:38:17.000 - 23232
>>
>> 140 times exactly 49 repeats in around 2 hours.
>>
>> Interesting is that there is no error about this 503 error in the log
>> only my monitoring is aware of the issue.
>>
>> I hope you coul'd help me out with this issue.
> Maybe you should turn your log level down to notice?
> The less you log, the better.

I only used info log level to track down the issue with the 503 errors
because there were no log entry :)
Anyway thank you for opening the two tickets and your explanation.
>
> T
> This doesn't help you solve your problem, but it's relevant.
>
> I run Tor network simulations and see this all the time. I haven't taken
> the time to look into it, and always have assumed it's just a minor
> misconfiguration in the simulator or something that only exists
> _because_ it's a simulation.
>
> And ... it looks like teor swooped in and opened a ticket for the log spam.
>
> Matt

Nice to here that I am not alone and to help each other.

Best Regards
Tobias



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

[tor-relays] Tor relay balks with "router_pick_published_address(): Success: chose address x.x.x.x"

[Tobias Sachs]

Hey,

my Tor relay
https://atlas.torproject.org/#details/B567E8E39641F61091C1F2CAAAF73D3D1BF9CFE1
balks with the following message which is repeated in the log with the
"info" logging level up to 23251 times at the exact same millisecond.
The relay responds at :9030/tor/server/authority with a 503 error.

router_pick_published_address(): Success: chose address 'x.x.x.x'

This is a counting from the log with the corresponding timestamp.

Nov 01 18:37:13.000 - 23251
Nov 01 18:37:22.000 - 59
Nov 01 18:38:17.000 - 23195
Nov 01 18:38:22.000 - 57
Nov 01 19:19:22.000 - 50
Nov 01 19:19:23.000 - 312
Nov 01 19:19:24.000 - 333
Nov 01 19:19:25.000 - 74
Nov 01 19:20:22.000 - 52
Nov 01 19:38:17.000 - 23207
Nov 01 20:38:17.000 - 23232

140 times exactly 49 repeats in around 2 hours.

Interesting is that there is no error about this 503 error in the log
only my monitoring is aware of the issue.

I hope you coul'd help me out with this issue.

Best Regards

Tobias



0x833E2E24.asc
Description: application/pgp-keys


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