Re: [tor-relays] Experimental DoS mitigation is in tor master - log entry

[Felix]

Hi everbody

Am 31-Jan-18 um 10:16 schrieb Roger Dingledine:
> now is a great time to try it and let us know of 
> problems and/or successes.

Currently just success. NTor is still pretty high, circuits and TAP
'normal'. cpu is difficult to say, still pumping lots of circuits
anyway. Settings are consensus related.

Two guards running since 6 hours and both show like:
DoS mitigation since startup:
19085 circuits rejected, 14 marked addresses.
0 connections closed. 12 single hop clients refused.

A middle (is long term guard and will get flag back soon)
running since 10 hours shows:
DoS mitigation since startup:
67877 circuits rejected, 6 marked addresses.
0 connections closed. 263 single hop clients refused.

All are Freebsd and behind firewall, still: 20 connects per /32 ip, rate
limited to 3 per sec. Immediate connection flushing, multi relay shared
blocking table. Blocking duration 1 day per ip.

Going to reduce fw after 24 hours step-by-step.

Thanks for the nice peace of software!

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

Re: [tor-relays] #25110: warn on missing MyFamily

[teor]

> On 1 Feb 2018, at 11:36, nusenu  wrote:
> 
>>> If you are the relay operator, please set a working contactInfo and proper 
>>> MyFamily configuration
>>> and drop an email to bad-rel...@lists.torproject.org.
>> 
>> We added this advice to the man page in 0.3.2.9.
> 
> #24526 did not make it into 0.3.2.9 but it will be in the next 0.3.2.x 
> release.
> 
> 
>> Should we also add a warning during Tor's config processing?
>> (Many people don't read warnings either, but it might help some.)
>> 
>> https://trac.torproject.org/projects/tor/ticket/25110
> 
> Thank you for suggesting this config warning.
> If it is a single instance operator it will always be a
> false-positive warning.

Single instance operators do not set MyFamily.

I suggest the following logic:

If the operator sets MyFamily, and does not set ContactInfo:
  log a warning asking them to set ContactInfo

It should be 2 lines of C code.

> Or do you actually intent to
> implement a logic that compares the ContactInfo
> of itself with other relays and warns if there is more than
> one relay with that contactinfo?
> (less false-positives)

No, this is unnecessary.

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] What's the priority right now?

[nusenu]

Conrad Rockenhaus:
> I’m ready to get node #3 up right now…so what’s the priority for high speed 
> nodes right now, exits or relays? Just wanted to know before I brought it 
> online.
> 
> This one is based in the great land of Canada :D.

If you can, run exit relays, there are less exits than non-exits.

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] What's the priority right now?

[John Ricketts]

I'd say exit :-)

> On Jan 31, 2018, at 18:59, Conrad Rockenhaus  wrote:
> 
> I’m ready to get node #3 up right now…so what’s the priority for high speed 
> nodes right now, exits or relays? Just wanted to know before I brought it 
> online.
> 
> This one is based in the great land of Canada :D.
> 
> Thanks,
> 
> Conrad
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] What's the priority right now?

[Conrad Rockenhaus]

I’m ready to get node #3 up right now…so what’s the priority for high speed 
nodes right now, exits or relays? Just wanted to know before I brought it 
online.

This one is based in the great land of Canada :D.

Thanks,

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

Re: [tor-relays] #25110: warn on missing MyFamily

[nusenu]

>> If you are the relay operator, please set a working contactInfo and proper 
>> MyFamily configuration 
>> and drop an email to bad-rel...@lists.torproject.org.
> 
> We added this advice to the man page in 0.3.2.9.

#24526 did not make it into 0.3.2.9 but it will be in the next 0.3.2.x release.


> Should we also add a warning during Tor's config processing?
> (Many people don't read warnings either, but it might help some.)
> 
> https://trac.torproject.org/projects/tor/ticket/25110

Thank you for suggesting this config warning.
If it is a single instance operator it will always be a
false-positive warning. Or do you actually intent to
implement a logic that compares the ContactInfo 
of itself with other relays and warns if there is more than 
one relay with that contactinfo?
(less false-positives)


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] 75 Exit Relays (48 currently running) - AS 197226 SPRINT SA (PL) - No Contact/MyFamily

[teor]

> On 1 Feb 2018, at 05:31, nusenu  wrote:
> 
> If you are the relay operator, please set a working contactInfo and proper 
> MyFamily configuration 
> and drop an email to bad-rel...@lists.torproject.org.

We added this advice to the man page in 0.3.2.9.
But many people don't read man pages.

Should we also add a warning during Tor's config processing?
(Many people don't read warnings either, but it might help some.)

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

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

Re: [tor-relays] 0.3.2.9 not reporting bandwidth in atlas

[Valter Jansons]

> Is it me or is there some issue.
> Since I've upgraded to version 0.3.2.9 there has been no update to the
bandwidth graphs.

It is not only you. The metrics for bandwidth are not being reported as
often anymore for privacy reasons - in particular for protecting identities
of onion guards.

Trac ticket for Onionoo enhancement:
https://trac.torproject.org/projects/tor/ticket/24155
Ref:
https://lists.torproject.org/pipermail/tor-relays/2018-January/014254.html

-- 4096R/A83CE748 Valters Jansons
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 0.3.2.9 not reporting bandwidth in atlas

[nusenu]

Paul Templeton:
> Is it me or is there some issue.
> Since I've upgraded to version 0.3.2.9 there has been no update to the 
> bandwidth graphs.

see:
https://lists.torproject.org/pipermail/tor-relays/2018-January/014254.html

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] 0.3.2.9 not reporting bandwidth in atlas

[Paul Templeton]

Is it me or is there some issue.
Since I've upgraded to version 0.3.2.9 there has been no update to the 
bandwidth graphs.

family:867B95CACD64653FEEC4D2CEFC5C49B4620307A7

Paul

609662E824251C283164243846C035C803940378

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

Re: [tor-relays] MyFamily and ContactInfo fields are required for operators running multiple tor instances

[grarpamp]

On Wed, Jan 31, 2018 at 3:08 PM, Vinícius Zavam  wrote:
> what about those using *only*
> PGP key fingerprints as ContactInfo? valid keys, publicly available (with
> working email address, and personal info from the admin).
>
> will these relays be removed from the network, or tagged as "bad" ones?

Seems to me that any readily discernible format of listing any
reasonably frictionless contact method should be viewed as ok...

PGP, ricochet, IPFS, postal mail, email, CJDNS, telephone,
twitter, ICQ, blockchain message, whatever.

Ambiguous addresses of such systems can be made
discernible / differentiable by prefixing them with tags...
pgp:, tel:, onioncat:, irc network, etc

If someone obfuscates an email address by converting it
to binary blob or digits, without explaining it in the contact
field as such, that's probably not 'readily discernible'.

Nor would closed source or paid services likely be
a 'reasonably frictionless' means of communication
for many in this space.

The more complex or esoteric the system, or unbuffered realtime
presence it requires to use it, the more likely no one will bother,
leading to potential problems when trying to...

"Hey, what's up with your relay?".
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Experimental DoS mitigation is in tor master

[Toralf Förster]

On 01/31/2018 10:16 AM, Roger Dingledine wrote:
> the sort who enjoys running code from git, now is a great time to try it
> and let us know of problems and/or successes.
> 

tor-0.3.3.1-alpha-58-ga846fd267 is bad here, the inbound connections stays at 
5-10

tor-0.3.3.1-alpha-42-g2294e330b works fine so far (testd with fadditinoal 
firewall, now started w/o firewall rules)

-- 
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] MyFamily and ContactInfo fields are required for operators running multiple tor instances

[nusenu]

Vinícius Zavam:
> considering that MyFamily is perfectly fine, what about those using *only*
> PGP key fingerprints as ContactInfo? valid keys, publicly available (with
> working email address, and personal info from the admin).
> 
> will these relays be removed from the network, or tagged as "bad" ones?

I don't think so.

(please fix the quoting or remove the text from the original email
if you are not quoting - it is hard to find your lines among the others)

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] Experimental DoS mitigation is in tor master

[Toralf Förster]

On 01/31/2018 08:57 PM, Tyler Johnson wrote:
> with or without additional firewall
*with* additional firewall rules currently.

-- 
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] MyFamily and ContactInfo fields are required for operators running multiple tor instances

[Vinícius Zavam]

On Jan 11, 2018 19:09, "nusenu"  wrote:

Hi,


hi,

I'd like to highlight that today the following
two sentences requiring ContactInfo and MyFamily for operators running
multiple relays
got added to the tor manual page [1]:

> ContactInfo **must** be set to a working address if you run more than
one
> relay or bridge.  (Really, everybody running a relay or bridge should
set
> it.)
>
>
> MyFamily **must** be set correctly if you run more than one relay or
> bridge. (That is, every relay should list all the others as described
> above.)


sorry for getting back to it a little late!

well ...

considering that MyFamily is perfectly fine, what about those using *only*
PGP key fingerprints as ContactInfo? valid keys, publicly available (with
working email address, and personal info from the admin).

will these relays be removed from the network, or tagged as "bad" ones?

The main motivation for this change have been suspicious tor relays that
bad-relays@ ML
decided to remove but had no way direct way to contact and so was forced
to make hard decisions.

With these clear statements bad-relays@ ML group can handle problematic
cases
better.

regards,
nusenu



[1] https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1717


--
https://mastodon.social/@nusenu
twitter: @nusenu_


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

Re: [tor-relays] Experimental DoS mitigation is in tor master

[Tyler Johnson]

at a first glance master (tor-0.3.3.1-alpha-42-g2294e330b) works like a
charm here at a hardened stable Gentoo with vanilla kernel 4.14.16 at both
Tor exit relays


Is that with or without additional firewall rules to combat the abundant
connection issues?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Experimental DoS mitigation is in tor master

[Toralf Förster]

On 01/31/2018 10:16 AM, Roger Dingledine wrote:
> but if you're
> the sort who enjoys running code from git, now is a great time to try it
> and let us know of problems and/or successes.
at a first glance master (tor-0.3.3.1-alpha-42-g2294e330b) works like a charm 
here at a hardened stable Gentoo with vanilla kernel 4.14.16 at both Tor exit 
relays


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

[tor-relays] 75 Exit Relays (48 currently running) - AS 197226 SPRINT SA (PL) - No Contact/MyFamily

[nusenu]

Dear anonymous relay operator,

thank you for adding so many exit relays this month in AS 197226 SPRINT SA (PL)
(netblocks 185.234.218.x and 77.87.79.x)
we would really like to keep these relays on the network, but they do not have 
any
contact information and MyFamily configuration set - which is required for such 
big relay groups.

If you are the relay operator, please set a working contactInfo and proper 
MyFamily configuration 
and drop an email to bad-rel...@lists.torproject.org.

If they do not hear from you, tor directory authorities might decide remove 
these relays.

It would be a shame to loose so much bandwidth.

thanks for your understanding,
nusenu

+-+-+-++-+-+--+
| first_seen  | IP  | tor_version | nickname   | or_port | 
contact | fingerprint  |
+-+-+-++-+-+--+
| 2018-01-17 22:00:00 | 185.234.218.37  | 0.3.2.9 | Ceto   |   23774 | 
NULL| 171F6B9BBEC4EBF903CF312CB71CE554F46D8689 |
| 2018-01-17 22:00:00 | 185.234.218.34  | 0.3.2.9 | Hera   |   25565 | 
NULL| 75712D28F4744FBECAD2E67250644C7258FA71F6 |
| 2018-01-17 22:00:00 | 185.234.218.36  | 0.3.2.9 | Brizo  |   25595 | 
NULL| A44A3AF8B117665AEB200D0D60674177629EBD18 |
| 2018-01-17 22:00:00 | 185.234.218.39  | 0.3.2.9 | Helios |   27365 | 
NULL| 625DC27C540CAE9EF37A8E8851808556AE3E4621 |
| 2018-01-17 22:00:00 | 185.234.218.46  | 0.3.2.9 | Rhea   |   32736 | 
NULL| 52E2BC36E8B333561C3F36689C1DF9A384B281AC |
| 2018-01-17 22:00:00 | 185.234.218.40  | 0.3.2.9 | Hestia |   28736 | 
NULL| 983221B0D3E68EF8A1D0D6A1EF2DDCF0BA73F710 |
| 2018-01-17 22:00:00 | 185.234.218.31  | 0.3.2.9 | Aphrodite  |   25535 | 
NULL| 7D8EFB8923173FB89EFE457BA2A6B04D7A9C3395 |
| 2018-01-17 22:00:00 | 185.234.218.35  | 0.3.2.9 | Zeus   |   25575 | 
NULL| F8ED98209AB9E73420530AA18BABE8AABC4E7619 |
| 2018-01-17 22:00:00 | 185.234.218.33  | 0.3.2.9 | Hades  |   2 | 
NULL| 0875C580CC0F0F7E57727AC3C2233F5E6A58AE28 |
| 2018-01-17 22:00:00 | 185.234.218.42  | 0.3.2.9 | Pallas |   30263 | 
NULL| D3E518F3749F9FC398261EC60B00B3B1D7535E42 |
| 2018-01-17 22:00:00 | 185.234.218.38  | 0.3.2.9 | Chaos  |   26536 | 
NULL| 1C49F07147A9113583190D38E58BA40DBECFB9F7 |
| 2018-01-17 22:00:00 | 185.234.218.43  | 0.3.2.9 | Styx   |   28736 | 
NULL| D6FC8F1E0FB2FC3AC4634FC26E4E1E4D7E1FB558 |
| 2018-01-17 22:00:00 | 185.234.218.41  | 0.3.2.9 | Nyx|   29096 | 
NULL| 8B200C067525B70930C4D6CB5DE4C7320B0418AC |
| 2018-01-17 22:00:00 | 185.234.218.44  | 0.3.2.9 | Tyche  |   29736 | 
NULL| F76368EC7009FB98F81544473B2F709859FB5327 |
| 2018-01-17 22:00:00 | 185.234.218.32  | 0.3.2.9 | Apollo |   25545 | 
NULL| 830227075292332360349D7A5842B1125004DC6D |
| 2018-01-17 22:00:00 | 185.234.218.45  | 0.3.2.9 | Uranus |   31837 | 
NULL| 01F6F2FA7921681EF6CF9DD327D8E1531B249B78 |
| 2018-01-17 23:00:00 | 77.87.79.46 | 0.3.2.9 | Artemis|   29384 | 
NULL| 65B2D3A0E002704B32B751C4238983D83297E5FB |
| 2018-01-17 23:00:00 | 185.234.218.49  | 0.3.2.9 | Maia   |   32736 | 
NULL| ECC5026169EDC6012244B06C2C8C9E90A4574077 |
| 2018-01-17 23:00:00 | 77.87.79.49 | 0.3.2.9 | Astra  |   29374 | 
NULL| B4FEC3BD7FF7D269490A5DDCD5B96799BC46489A |
| 2018-01-17 23:00:00 | 185.234.218.50  | 0.3.2.9 | Heracles   |   31945 | 
NULL| 94D951D305DEFBBF2552BBDD9C919B09633DDA24 |
| 2018-01-17 23:00:00 | 77.87.79.47 | 0.3.2.9 | Hypnos |   25363 | 
NULL| 537DD2E2D2F026FA9CD210E4B854584762DD9DB6 |
| 2018-01-17 23:00:00 | 185.234.218.48  | 0.3.2.9 | Proteus|   28373 | 
NULL| 7F6DF29D2E0A82834E45AC210990B855802752B6 |
| 2018-01-17 23:00:00 | 185.234.218.47  | 0.3.2.9 | Peitha |   28342 | 
NULL| 6716D11B3D43EA12EC883AA45A600EA277946A39 |
| 2018-01-18 00:00:00 | 77.87.79.59 | 0.3.2.9 | Charon |   32734 | 
NULL| 7868248CD8FEE709AEAC0D13F1E30F79EC02D4C4 |
| 2018-01-18 00:00:00 | 77.87.79.60 | 0.3.2.9 | Nemesis|   27364 | 
NULL| 54DC9A823CDFAB833590B4E4AE7EC386F38E2EB2 |
| 2018-01-18 00:00:00 | 77.87.79.56 | 0.3.2.9 | Sirens |   35736 | 
NULL| AA545B49FE9AE5FC4B2295330E77EAD7BA228AEC |
| 2018-01-18 00:00:00 | 77.87.79.52 | 0.3.2.9 | Erotes |   28374 | 
NULL| 36876E90176DBE3395A3EE8A2584FE7C3513C3C6 |
| 2018-01-18 00:00:00 | 77.87.79.57 | 0.3.2.9 | Eleus  |   28374 | 
NULL| F47044B9A265994F17EE02FBDA2046DB1A48E6F6 |
| 2018-01-18 00:00:00 | 77.87.79.55 | 0.3.2.9 | Doris  |   33625 | 
NULL| 9D30457253C5F43AAF38D6356C2B1E8CE4D4672D |
| 2018-01-18 00:00:00 | 77.87.79.53 | 0.3.2.9 | Astra  |   

Re: [tor-relays] High number of simultaneous connections from a single host

[Tyler Johnson]

>
>
>
> However I'm still interested in how to block this kind of abuse outside of
> tor
> itself. I'm looking to implement some iptables limiting and I'm wondering
> how
> the limits should be so that I don't deny normal tor traffic.
>
> Would a 10 connections per IP limit be OK? Should be higher than that?
>
>
https://lists.torproject.org/pipermail/tor-relays/2018-January/014100.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] High number of simultaneous connections from a single host

[zless]

În ziua de miercuri, 31 ianuarie 2018, la 17:32:15 EET, Roger Dingledine a 
scris:
> On Wed, Jan 31, 2018 at 05:21:38PM +0200, zless wrote:
> > I was inspecting my node and just saw that it has a very high number of
> > connections.
> > 
> > It jumped from the normal 6000-7000 to more than 17000 simultaneous
> > connections.
> > 
> > Looking at the connections with `ss` I see some hosts with over 1000
> > connections while the majority is usually bellow 10.
> 
> In the future, you should avoid including IP addresses like this. Some of
> these are normal Tor users who probably don't like having their addresses
> listed. After all, the goal of your relay is to provide privacy, right?

Sorry about that. I somehow thought that those are only relays like myself and 
these are public already.

Even so, on closer inspection they seem to fall more on the "bots" side. Most 
of the IPs in my list are servers from Leaseweb and Hetzner.

> 
> > Is it normal for a single host to produce so many connections?
> > 
> > How do you people handle such situations?
> 
> It is not normal. I recommend either trying out the new mitigation
> feature in git master, or waiting until it gets into a release:
> 
> https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html
> https://lists.torproject.org/pipermail/tor-relays/2018-January/014175.html
> https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html

Thanks for the links, they are quite informative.

However I'm still interested in how to block this kind of abuse outside of tor 
itself. I'm looking to implement some iptables limiting and I'm wondering how 
the limits should be so that I don't deny normal tor traffic.

Would a 10 connections per IP limit be OK? Should be higher than that?

Thanks for any ideas.

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

Re: [tor-relays] High number of simultaneous connections from a single host

[nusenu]

> I was inspecting my node and just saw that it has a very high number of 
> connections.
> 
> It jumped from the normal 6000-7000 to more than 17000 simultaneous 
> connections.
> 
> Looking at the connections with `ss` I see some hosts with over 1000 
> connections while the majority is usually bellow 10.
> 
> Here are some stats with the IP and the associated number of simultaneous 
> connections:
 
Please do not publish IP addresses of potential tor clients/onion services!


> Is it normal for a single host to produce so many connections?

This is a known and ongoing issue, the tor developer worked on
a fix to mitigate the impact of such aggressive clients.

https://twitter.com/nusenu_/status/958486010563874817
https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] High number of simultaneous connections from a single host

[Roger Dingledine]

On Wed, Jan 31, 2018 at 05:21:38PM +0200, zless wrote:
> I was inspecting my node and just saw that it has a very high number of 
> connections.
> 
> It jumped from the normal 6000-7000 to more than 17000 simultaneous 
> connections.
> 
> Looking at the connections with `ss` I see some hosts with over 1000 
> connections while the majority is usually bellow 10.

In the future, you should avoid including IP addresses like this. Some of
these are normal Tor users who probably don't like having their addresses
listed. After all, the goal of your relay is to provide privacy, right?

> Is it normal for a single host to produce so many connections?
> 
> How do you people handle such situations?

It is not normal. I recommend either trying out the new mitigation
feature in git master, or waiting until it gets into a release:

https://lists.torproject.org/pipermail/tor-relays/2018-January/014357.html
https://lists.torproject.org/pipermail/tor-relays/2018-January/014175.html
https://lists.torproject.org/pipermail/tor-relays/2017-December/014002.html

--Roger

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

[tor-relays] High number of simultaneous connections from a single host

[zless]

Hello everyone,

I was inspecting my node and just saw that it has a very high number of 
connections.

It jumped from the normal 6000-7000 to more than 17000 simultaneous 
connections.

Looking at the connections with `ss` I see some hosts with over 1000 
connections while the majority is usually bellow 10.

Here are some stats with the IP and the associated number of simultaneous 
connections:

212.32.226.237 : 1531
207.244.110.200 : 1520
162.210.192.70 : 1471
207.244.70.120 : 1455
198.7.59.194 : 1454
212.32.239.28 : 1450
5.79.103.239 : 1414
5.79.103.238 : 1401
51.15.162.120 : 1379
37.48.104.231 : 56
5.79.72.66 : 26
37.48.105.240 : 25
212.83.3.154 : 25
78.46.99.242 : 23
178.63.47.145 : 18
46.4.84.142 : 17
213.133.100.55 : 17
46.4.106.87 : 15
144.76.18.214 : 14

Is it normal for a single host to produce so many connections?

How do you people handle such situations?

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

Re: [tor-relays] Tor uses up all available memory and eventually quits

[George W. Maschke]

Thank you to all who responded to my question!

The memory issue seems to be fixed now, and I would like to share what worked 
(and what didn’t).

I first tried setting MaxMemInQueues to 512, then 384, while still running Tor 
0.2.5.16. This didn’t help.

Adding the option DisableOOSCheck 0 caused an error that prevented Tor from 
starting.

I then upgraded Tor to 0.3.2.9. With this version, setting MaxMemInQeues to 384 
seems to have fixed the problem, with no other changes to /etc/tor/torrc.

Tor has been running for 29 hours with memory usage hovering around 85%, while 
average throughput is close to 10 megabytes per second.

For any who are interested, additional details about the relay in question are 
available here:

https://atlas.torproject.org/#details/0964EEEF3AEF8442F510F8A61370657BC6E0E098

George W. Maschke
https://georgemaschke.net


> On Jan 31, 2018, at 4:02 AM, teor  wrote:
> 
> 
> 
> On 31 Jan 2018, at 10:45, r1610091651  > wrote:
> 
>> On Sun, 28 Jan 2018 at 11:06 teor > > wrote:
>> 
>> 
>> Try to make sure MaxMemInQueues allows 10-20s of traffic.
>> 
>> 
>> Hi teor
>> 
>> That advice is quite sensible in my opinion and should be incorporated into 
>> tor mainline. With the recent load spikes, I've always wanders why is there 
>> a need for that may MB or even GB of queue memory. If it can't be 
>> retransmitted in few seconds, it will be retransmitted by source and will 
>> increase the queues further...
> 
> Tor doesn't work like TCP.
> Clients do give up and retry after about 10-20s.
> 
> But if a circuit is broken by discarding cells, then the entire circuit needs
> to be rebuilt, and the request sent again. And the client will probably
> choose another path, that isn't as congested.
> 
> A large MaxMemInQueues keeps circuits from breaking during traffic
> spikes.
> 
> But you're right, if the whole network is overloaded, it leads to a lot of 
> large
> buffers that don't do much.
> 
>> The current setting for maxmeminqueue is 256MB and will correct itself if 
>> lowered. I would suggest to make that value rate dependent, either 
>> configured or measured.
>> 
>>  To your knowledge, was there any thought put into such a dynamic config, 
>> instead of fixed percentage of free memory, independent of the actual 
>> throughput?
> 
> There's a ticket to make it lower:
> https://trac.torproject.org/projects/tor/ticket/24782 
> 
> 
> One problem with dynamic limits is that they don't handle traffic spikes well.
> So we don't want to make it too low, because if your relay has the RAM,
> it should use it.
> 
> 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] unreplied conntrack sessions

[Quintin]

>
> It is probably still the best solution to change provider - if you are
> still considering it.
>

Yep, changing provider is 98% complete. I have a new instance running at
online.net since last night:
https://atlas.torproject.org/#details/45A9735BE83ECE864B23621B8D266E6A1AEA96F6

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

Re: [tor-relays] Experimental DoS mitigation is in tor master

[nusenu]

teor:
> 
> 
>> On 31 Jan 2018, at 20:37, nusenu  wrote:
>>
>>> We've merged https://bugs.torproject.org/24902 into tor git master.
>>> ...
> 
> If you compile using clang, there are some warnings that appear to be
> harmless:
> https://trac.torproject.org/projects/tor/ticket/25094
> 
> The overall design is solid and the defences seem to work.
> But we are still doing minor fixes before the release and backport.
> (That's why it's master :-)
> 
>> And packages for Debian-based OSes are probably in the next nightly master 
>> builds
>> available at https://deb.torproject.org/torproject.org/dists/
> 
> We merged about 30 minutes before the final debs were written to
> deb.torproject.org. So I'm not sure if they will all have these changes.
> 
> Your best bet is to wait 12 hours from now, and they'll be there.

that is why I said _next_ nightly builds ;)


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] Experimental DoS mitigation is in tor master

[teor]

> On 31 Jan 2018, at 20:37, nusenu  wrote:
> 
>> We've merged https://bugs.torproject.org/24902 into tor git master.
>> ...

If you compile using clang, there are some warnings that appear to be
harmless:
https://trac.torproject.org/projects/tor/ticket/25094

The overall design is solid and the defences seem to work.
But we are still doing minor fixes before the release and backport.
(That's why it's master :-)

> And packages for Debian-based OSes are probably in the next nightly master 
> builds
> available at https://deb.torproject.org/torproject.org/dists/

We merged about 30 minutes before the final debs were written to
deb.torproject.org. So I'm not sure if they will all have these changes.

Your best bet is to wait 12 hours from now, and they'll be there.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
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] Experimental DoS mitigation is in tor master

[nusenu]

nusenu:
> And packages for Debian-based OSes are probably in the next nightly master 
> builds
> available at https://deb.torproject.org/torproject.org/dists/

I just added support for tor nightly build repos to ansible-relayor 
(Debian/Ubuntu only),
to make it very easy to test bleeding edge #Tor features such as the new denial 
of service
mitigations.
https://github.com/nusenu/ansible-relayor

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[nusenu]

Roger Dingledine:
> On Wed, Jan 31, 2018 at 11:41:00AM +, nusenu wrote:
>>> Comment (by arma):
>>>
>>>  I continue to think that teaching exit relays to avoid allowing exit
>>>  connections to known relays (IP:ORPort) is a good and useful step.
>>>
>>>  We keep running across messy situations where letting somebody connect to
>>>  a relay from an exit relay's IP address turns into a security surprise.
>>
>> Does that mean that exits will no longer be able to run tor clients (ie. to 
>> run apt updates via tor)?
> 
> No, they are unrelated. 

Great, thanks for the fast reply.

> (Also, if you want to reply to a trac ticket comment, the strategy of
> responding on the tor-relays list is a very odd approach. :)

If the answer was yes - that would be relevant to this list.

I'm looking forward to the day where you can reply to tickets via email :)

-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[Roger Dingledine]

On Wed, Jan 31, 2018 at 11:41:00AM +, nusenu wrote:
> > Comment (by arma):
> > 
> >  I continue to think that teaching exit relays to avoid allowing exit
> >  connections to known relays (IP:ORPort) is a good and useful step.
> > 
> >  We keep running across messy situations where letting somebody connect to
> >  a relay from an exit relay's IP address turns into a security surprise.
> 
> Does that mean that exits will no longer be able to run tor clients (ie. to 
> run apt updates via tor)?

No, they are unrelated. The things you describe would be connections
made by the Tor client, and the things I describe would be connections
made by building a circuit to the exit and sending a begin cell.

(Also, if you want to reply to a trac ticket comment, the strategy of
responding on the tor-relays list is a very odd approach. :)

--Roger

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

[tor-relays] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[nusenu]

> Comment (by arma):
> 
>  I continue to think that teaching exit relays to avoid allowing exit
>  connections to known relays (IP:ORPort) is a good and useful step.
> 
>  We keep running across messy situations where letting somebody connect to
>  a relay from an exit relay's IP address turns into a security surprise.

Does that mean that exits will no longer be able to run tor clients (ie. to 
run apt updates via tor)?


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] Experimental DoS mitigation is in tor master

[John Ricketts]

Woo, for sure!

> On Jan 31, 2018, at 03:16, Roger Dingledine  wrote:
> 
> Hi folks,
> 
> Thanks for your patience with the relay overload issues.
> 
> We've merged https://bugs.torproject.org/24902 into tor git master. We'll
> be putting out an 0.3.3.2-alpha release in not too long for wider testing,
> and eventually backporting it all the way back to 0.2.9, but if you're
> the sort who enjoys running code from git, now is a great time to try it
> and let us know of problems and/or successes.
> 
> Here's the changelog stanza:
> 
>  o Major features:
>- Give relays some defenses against the recent network overload. We
>  start with three defenses (default parameters in parentheses).
>  First: if a single client address makes too many connections
>  (>100), hang up on further connections. Second: if a single client
>  address makes circuits too quickly (more than 3 per second, with
>  an allowed burst of 90) while also having too many connections open
>  (3), refuse new create cells for the next while (1-2 hours). Third:
>  if a client asks to establish a rendezvous point to you directly,
>  ignore the request. These defenses can be manually controlled
>  by new torrc options, but relays will also take guidance from
>  consensus parameters, so there's no need to configure anything
>  manually. Implements ticket 24902.
> 
> To repeat that last part: there are a bunch of torrc options you can
> use to tweak stuff, but you can leave it all at the defaults and it will
> read its instructions out of the consensus parameters:
> https://consensus-health.torproject.org/#consensusparams
> 
> Woo,
> --Roger
> 
> ___
> 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] unreplied conntrack sessions

[nusenu]

>> On 31 Jan 2018, at 05:54, Quintin  wrote:
>>
>> nusenu wrote: 
>>> If your hoster suspends your server if you exceed 10k concurrent connections
>>> I'm afraid it is probably not suitable for an exit relay
>>
>> The response from the hoster was:
>>> Your server should not have over 20,000 unreplied connections. This is a 
>>> sign of abuse. 

with "unreplied connections" they might actually mean connection _attempts_ and
not actual connections (I assume they talk about outbound and not inbound 
traffic).
And they might take it as a sign for "you are probably running a portscanner" 
(which usually
results in lots of connection attempts - TCP SYN packets without replies).

It is probably still the best solution to change provider - if you are still 
considering it.


>> What about the exit node causes such abormally high conntrack sessions?
> 
> It is normal for exits to have over 10,000 connections:
> * 7000 to relays, and

we are about to fall bellow 6k concurrently running relays
https://metrics.torproject.org/networksize.html



-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] Experimental DoS mitigation is in tor master

[nusenu]

> Thanks for your patience with the relay overload issues.
> 
> We've merged https://bugs.torproject.org/24902 into tor git master. We'll
> be putting out an 0.3.3.2-alpha release in not too long for wider testing,
> and eventually backporting it all the way back to 0.2.9, but if you're
> the sort who enjoys running code from git, now is a great time to try it
> and let us know of problems and/or successes.
> 
> Here's the changelog stanza:
> 
>   o Major features:
> - Give relays some defenses against the recent network overload. We
>   start with three defenses (default parameters in parentheses).
>   First: if a single client address makes too many connections
>   (>100), hang up on further connections. Second: if a single client
>   address makes circuits too quickly (more than 3 per second, with
>   an allowed burst of 90) while also having too many connections open
>   (3), refuse new create cells for the next while (1-2 hours). Third:
>   if a client asks to establish a rendezvous point to you directly,
>   ignore the request. These defenses can be manually controlled
>   by new torrc options, but relays will also take guidance from
>   consensus parameters, so there's no need to configure anything
>   manually. Implements ticket 24902.
> 
> To repeat that last part: there are a bunch of torrc options you can
> use to tweak stuff, but you can leave it all at the defaults and it will
> read its instructions out of the consensus parameters:
> https://consensus-health.torproject.org/#consensusparams

And packages for Debian-based OSes are probably in the next nightly master 
builds
available at https://deb.torproject.org/torproject.org/dists/


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_



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] Experimental DoS mitigation is in tor master

[Roger Dingledine]

Hi folks,

Thanks for your patience with the relay overload issues.

We've merged https://bugs.torproject.org/24902 into tor git master. We'll
be putting out an 0.3.3.2-alpha release in not too long for wider testing,
and eventually backporting it all the way back to 0.2.9, but if you're
the sort who enjoys running code from git, now is a great time to try it
and let us know of problems and/or successes.

Here's the changelog stanza:

  o Major features:
- Give relays some defenses against the recent network overload. We
  start with three defenses (default parameters in parentheses).
  First: if a single client address makes too many connections
  (>100), hang up on further connections. Second: if a single client
  address makes circuits too quickly (more than 3 per second, with
  an allowed burst of 90) while also having too many connections open
  (3), refuse new create cells for the next while (1-2 hours). Third:
  if a client asks to establish a rendezvous point to you directly,
  ignore the request. These defenses can be manually controlled
  by new torrc options, but relays will also take guidance from
  consensus parameters, so there's no need to configure anything
  manually. Implements ticket 24902.

To repeat that last part: there are a bunch of torrc options you can
use to tweak stuff, but you can leave it all at the defaults and it will
read its instructions out of the consensus parameters:
https://consensus-health.torproject.org/#consensusparams

Woo,
--Roger

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