Re: [tor-relays] Action relays on 188.214.30.0/24 subnet

[teor]

> On 6 Dec 2017, at 15:14, x9p  wrote:
> 
> 
> Shouldn't an action be taken against such relays?
> 
> https://atlas.torproject.org/#search/188.214.30
> 
> They are clearly being run by the same entity/person, probably in an
> automated fashion, don't have family set, and are using the same
> datacenter.

Clients don't choose relays in the same /16 in the same circuit.
So I don't think this is a danger to users.

We would like to write a polite email saying:
"thanks for helping Tor, please add a family to your config".

But since they haven't provided contact details, we can't do that.

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

[tor-relays] Action relays on 188.214.30.0/24 subnet

[x9p]

Shouldn't an action be taken against such relays?

https://atlas.torproject.org/#search/188.214.30

They are clearly being run by the same entity/person, probably in an
automated fashion, don't have family set, and are using the same
datacenter.

cheers.

x9p

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

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

>> On 5 Dec 2017, at 22:50, x9p  wrote:
>>
>>
>> my second and third positions are similar:
>>
>>  ...
>
> Please don't publicly share exact connection numbers and netblocks.
> They can be used in combination with other information to de-anonymise
> users.
>
> (For example, if an adversary knows that a guard has 5 connections from
> a netblock that they can't otherwise observe, they can go and hunt down
> those users.)
>

true, didnt thought about it. but didnt told which relay was talking
about, either.

cheers.

x9p

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

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

> @ x9p:
>
>> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
>> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c |
>> sort
>> | egrep -v '  1 |  2 |  3 '
>>
>> with this information in hand, double the max of it (mine was 10
>> connections from 188.214.30.0/24):
>>
>>  10 188.214.30
>>
>> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
>> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>
> Thank you! This was extremely helpful.
>
> In our case we found a handful of IPs that had *thousands* of
> concurrent connections on several of our relays. The offending IPs
> were not in the consensus. After restarting the Tor service, these
> suspect connections come back rapidly, again across several of our
> relays. Since our relays are all in the same declared family, it is
> very difficult to see how this traffic is legitimate. If it's valid
> Tor clients, they are behaving very strangely, and in either case we
> need to limit their impact. As such we've implemented connlimits by
> /24 as suggested (with a much higher limit to err on the side of not
> rejecting valid traffic). We can already see that this has improved
> our situation.

nice to hear :)

cheers.

x9p


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

Re: [tor-relays] companies and organizations running relays

[Tyler Durden]

Simply have a look at https://torservers.net/partners.html


Greetings

Christian Pietsch:
> Please add:
> 
> Digital human rights activist/advocacy NGO Digitalcourage e.V., Germany / 
> https://digitalcourage.de / 
> https://atlas.torproject.org/#search/family:9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D
> 
> On Tue, Dec 05, 2017 at 07:03:00PM +, Alison Macrina wrote:
>> I'm wondering if folks on this list can help me by confirming the
>> organizations that they know of running relays.
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-- 
Frënn vun der Ënn A.S.B.L. (NGO)
e. vi...@enn.lu (GPG: 0xce8c12f32a2cf11b)
t. +352-27-40-20-30-4
w. https://enn.lu/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] companies and organizations running relays

[Christian Pietsch]

Please add:

Digital human rights activist/advocacy NGO Digitalcourage e.V., Germany / 
https://digitalcourage.de / 
https://atlas.torproject.org/#search/family:9EAD5B2D3DBD96DBC80DCE423B0C345E920A758D

On Tue, Dec 05, 2017 at 07:03:00PM +, Alison Macrina wrote:
> I'm wondering if folks on this list can help me by confirming the
> organizations that they know of running relays.

-- 
  Christian Pietsch | library IT by day, otherwise volunteering for
  Digitalcourage e.V., Marktstr. 18, D-33602 Bielefeld, Germany
  https://digitalcourage.de | https://bigbrotherawards.de
  How to avoid Google: https://pad.okfn.org/p/google_alternatives


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

Re: [tor-relays] DoS attacks on multiple relays

[teor]

> On 5 Dec 2017, at 22:50, x9p  wrote:
> 
> 
> my second and third positions are similar:
> 
>  ...

Please don't publicly share exact connection numbers and netblocks.
They can be used in combination with other information to de-anonymise users.

(For example, if an adversary knows that a guard has 5 connections from
a netblock that they can't otherwise observe, they can go and hunt down
those users.)

> On 6 Dec 2017, at 07:42, null  wrote:
> 
> ...
> @ Scott Bennett:
> 
>> What you are seeing is most likely the same phenomenon brought up on
>> this list repeatedly over at least the last decade or so.  That phenomenon
>> is providing HSDir service, or perhaps a rendez-vous point, for a popular
>> hidden service.
> 
>> If you don't like it, you can set
>> 
>> HidServDirectoryV2  0
> 
> Thanks for your reply. The data suggests this was not the case (this
> time). Some of these relays have been up almost a year with the same
> configuration, often with the HSDir flag. The recent issues just
> started occurring, and happened across several relays during the same
> timeframe.
> 
> Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule
> it out. However it appears that option is deprecated (on 0.3.1.9).
> Enabling it causes this in the log:
> 
>  [WARN] Skipping obsolete configuration option 'HidServDirectoryV2'
> 
> It's also no longer listed in the Tor manual
> (https://www.torproject.org/docs/tor-manual.html.en). It looks like we
> might be able to achieve the same effect with something like this
> instead:
> 
>  MinUptimeHidServDirectoryV2 52 weeks
> 
> Anyone have any info on why HidServDirectoryV2 is consider obsolete?
> Is using MinUptimeHidServDirectoryV2 instead going to achieve the same
> effect?

No, this option only applies to directory authorities, and determines their
votes for the HSDir flag.

From the tor man page:

   MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks
   Minimum uptime of a v2 hidden service directory to be accepted as
   such by authoritative directories. (Default: 25 hours)

>>> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks
>>> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
>>> 
>>>  elif [ "$system_max" -gt "4" ] ; then
>>>MAX_FILEDESCRIPTORS=16384
>>> 
>>> Surely that is high enough for normal service?
>> 
>> If by normal you mean "low traffic", then yes, it's probably enough.
>> However, that's really not very high in a general sense.
> 
> 
> Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap
> MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise.
> Obviously we could comment out these lines, but it seems odd the
> default config tries to cap it at 16384 if that's too low for a high
> traffic relay.

Perhaps it's the maximum allowed on some kernels or low-memory systems?
Or perhaps it's historical?

I suggest that you submit a ticket or patch to the debian bug tracker.

T

--
Tim Wilson-Brown (teor)

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






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

Re: [tor-relays] companies and organizations running relays

[Zack Weinberg]

I’ve been operating an exit node in an academic setting for about four
years and I would be happy to kibitz your guide.

On Tue, Dec 5, 2017 at 2:03 PM Alison Macrina  wrote:

> Hi all,
>
> Phoul and I are working on a blog post/guide to encourage more relay
> operators. The post will include technical and legal information for
> relay operators, but also things that are in more of a "social"
> category, like information for starting a relay operators group on a
> college campus. In that section, we want to highlight a few of the
> companies or non-profit organizations that run relays, but we're
> realizing that we don't actually have an up to date list.
>
> I'm wondering if folks on this list can help me by confirming the
> organizations that they know of running relays.
>
> Thanks! And if you're interested in contributing to the relay operators
> draft we have so far, please ping me off list. Something this
> comprehensive can always use an extra pair of eyes.
>
> Thanks,
>
> Alison
>
> --
> Alison Macrina
> Community Team Lead
> The Tor Project
> ___
> 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] companies and organizations running relays

[Rejo Zenger]

Hey,

In the Netherlands there is Hart voor Internetvrijheid that runs a couple of 
relays. In addition to that, there's a yearly informal meeting open to 
potential relay operators with a lot of room for interactive discussions on 
operating relays.

I myself work for the leading Dutch digital civil rights organisation Bits of 
Freedom and we provide generic information in Dutch on running relays. See for 
example these two blog posts, highlighting legal and technical points to 
consider when running a relay.

https://www.bof.nl/2014/12/17/juridische-risicos-van-het-draaien-van-een-tor-node/
https://www.bof.nl/2014/08/15/het-tor-netwerk-helpen-zonder-iemand-dwars-te-zitten/

Ciao, Rejo




++ 05/12/17 19:03 + - Alison Macrina:
>Hi all,
>
>Phoul and I are working on a blog post/guide to encourage more relay
>operators. The post will include technical and legal information for
>relay operators, but also things that are in more of a "social"
>category, like information for starting a relay operators group on a
>college campus. In that section, we want to highlight a few of the
>companies or non-profit organizations that run relays, but we're
>realizing that we don't actually have an up to date list.
>
>I'm wondering if folks on this list can help me by confirming the
>organizations that they know of running relays.
>
>Thanks! And if you're interested in contributing to the relay operators
>draft we have so far, please ping me off list. Something this
>comprehensive can always use an extra pair of eyes.
>
>Thanks,
>
>Alison
>
>-- 
>Alison Macrina
>Community Team Lead
>The Tor Project
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


-- 
Rejo Zenger
E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl
T @rejozenger | J r...@zenger.nl

OpenPGP   1FBF 7B37 6537 68B1 2532  A4CB 0994 0946 21DB EFD4
XMPP OTR  271A 9186 AFBC 8124 18CF  4BE2 E000 E708 F811 5ACF


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

Re: [tor-relays] So long and thanks for all the abuse complaints

[teor]

> On 6 Dec 2017, at 01:35, t...@t-3.net wrote:
> 
> Abuse complaints are how this thing goes. With your limited exit policy, you 
> would hardly see any complaints (relatively speaking), and what you do see 
> would be mostly like SQL hack complaints and such. It's usually not going to 
> be cases where someone got all the way into someone's machine, it's going to 
> be mainly complaints about attempts.

Our provider became concerned about the volume of abuse complaints
we were receiving, so we added a "reject IP:Port" to our exit policy for
each one. (Or a /24 for noisy netblocks.)

The volume dried up pretty quickly when we went back through historical
emails and added about 30 entries. It seems that there are only a few
really big complainers.

So that's another alternative that preserves access to 99% of the Internet
from your exit.

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

Re: [tor-relays] DoS attacks on multiple relays

[null]

@ x9p:

> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
> | egrep -v '  1 |  2 |  3 '
>
> with this information in hand, double the max of it (mine was 10
> connections from 188.214.30.0/24):
>
>  10 188.214.30
>
> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
> --connlimit-mask 24 -j REJECT --reject-with tcp-reset

Thank you! This was extremely helpful.

In our case we found a handful of IPs that had *thousands* of
concurrent connections on several of our relays. The offending IPs
were not in the consensus. After restarting the Tor service, these
suspect connections come back rapidly, again across several of our
relays. Since our relays are all in the same declared family, it is
very difficult to see how this traffic is legitimate. If it's valid
Tor clients, they are behaving very strangely, and in either case we
need to limit their impact. As such we've implemented connlimits by
/24 as suggested (with a much higher limit to err on the side of not
rejecting valid traffic). We can already see that this has improved
our situation.


@ Scott Bennett:

>  What you are seeing is most likely the same phenomenon brought up on
> this list repeatedly over at least the last decade or so.  That phenomenon
> is providing HSDir service, or perhaps a rendez-vous point, for a popular
> hidden service.

> If you don't like it, you can set
>
> HidServDirectoryV2  0

Thanks for your reply. The data suggests this was not the case (this
time). Some of these relays have been up almost a year with the same
configuration, often with the HSDir flag. The recent issues just
started occurring, and happened across several relays during the same
timeframe.

Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule
it out. However it appears that option is deprecated (on 0.3.1.9).
Enabling it causes this in the log:

  [WARN] Skipping obsolete configuration option 'HidServDirectoryV2'

It's also no longer listed in the Tor manual
(https://www.torproject.org/docs/tor-manual.html.en). It looks like we
might be able to achieve the same effect with something like this
instead:

  MinUptimeHidServDirectoryV2 52 weeks

Anyone have any info on why HidServDirectoryV2 is consider obsolete?
Is using MinUptimeHidServDirectoryV2 instead going to achieve the same
effect?


>> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks
>> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
>>
>>   elif [ "$system_max" -gt "4" ] ; then
>> MAX_FILEDESCRIPTORS=16384
>>
>> Surely that is high enough for normal service?
>
>  If by normal you mean "low traffic", then yes, it's probably enough.
> However, that's really not very high in a general sense.


Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap
MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise.
Obviously we could comment out these lines, but it seems odd the
default config tries to cap it at 16384 if that's too low for a high
traffic relay.

Thanks everyone for your replies!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Ralph Seichter]

On 05.12.17 20:21, r1610091651 wrote:

> how can the hoster determine whether a packet is part of a port scan
> or valid connection request?

One common example of automatically detectable port scans for /24 IPv4
subnets are consecutive connections, in a small amount of time, to

  aaa.bbb.ccc.1:80
  aaa.bbb.ccc.2:80
  aaa.bbb.ccc.3:80
  [etc.]

Looking at the logs I received, this traversal of subnets to find open
ports is the most common type of scan for which my exit is being abused.

The logs sometimes show variations like scanning odd-numbered addresses
in one pass and even-numbered in the next, or scans for several subnets
mixed together, but the hoster's monitoring software is quite good at
automatically identifying patterns.

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

Re: [tor-relays] So long and thanks for all the abuse complaints

[r1610091651]

I think it is relevant.

There are two sides to creating a connection and traffic can be filtered on
both ends.
On the initiator: any invalid outgoing packets can be filtered
On the receiver: any not expected / invalid packets can be filtered

Just a question: how can the hoster determine whether a packet is part of a
port scan or valid connection request?
Unless the packet is mangled/invalid (ex: out of sequence like fin / syn
scan) it can't as it is unaware what services are running at the other end.
Effectively what the hoster is also doing, is imposing a rate limit on rate
and number of connections.

On Tue, 5 Dec 2017 at 19:51 Ralph Seichter  wrote:

> On 05.12.17 19:24, r1610091651 wrote:
>
> > Having servers on-line and complaining about such things is just
> > unreasonable and laziness on the operator side: don't want scans,
> > then setup proper firewall rules. Done.
>
> Your comment is not applicable in this particular case; please read my
> other messages in this thread to see why.
>
> -Ralph
> ___
> 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] companies and organizations running relays

[Gareth Llewellyn]

 Original Message 
On 5 Dec 2017, 19:03, Alison Macrina wrote:
I'm wondering if folks on this list can help me by confirming the organizations 
that they know of running relays.

Checking in on behalf of AS28715 / BrassHornCommunications.uk / 
https://atlas.torproject.org/#search/family:518FF8708698E1DA09C823C36D35DF89A2CAD956___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] companies and organizations running relays

[Alison Macrina]

Hi all,

Phoul and I are working on a blog post/guide to encourage more relay
operators. The post will include technical and legal information for
relay operators, but also things that are in more of a "social"
category, like information for starting a relay operators group on a
college campus. In that section, we want to highlight a few of the
companies or non-profit organizations that run relays, but we're
realizing that we don't actually have an up to date list.

I'm wondering if folks on this list can help me by confirming the
organizations that they know of running relays.

Thanks! And if you're interested in contributing to the relay operators
draft we have so far, please ping me off list. Something this
comprehensive can always use an extra pair of eyes.

Thanks,

Alison

-- 
Alison Macrina
Community Team Lead
The Tor Project
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[Ralph Seichter]

On 05.12.17 19:24, r1610091651 wrote:

> Having servers on-line and complaining about such things is just
> unreasonable and laziness on the operator side: don't want scans,
> then setup proper firewall rules. Done.

Your comment is not applicable in this particular case; please read my
other messages in this thread to see why.

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

Re: [tor-relays] So long and thanks for all the abuse complaints

[r1610091651]

Port scans are part of internet life in my opinion. One cannot have
internet access and no (occasional) port scan, spam mails, worms, ...
Having servers on-line and complaining about such things is just
unreasonable and laziness on the operator side: don't want scans, then
setup proper firewall rules. Done.

Just a "food for thought": how does one distinguishes between slow port
scan (as is possible with for example nmap) and actual connection attempts?

Regards


On Tue, 5 Dec 2017 at 17:38 Ralph Seichter  wrote:

> Quoting myself:
>
> > I've had an ongoing debate with a hosting service over a fresh exit
> > node being abused for network scans (ports 80 and 443) almost hourly
> > for the last few days.
>
> I had the former exit node unlocked an ran it in relay mode for a day.
> Today I switched back to exit mode, and a few hours after the exit flag
> was reassigned, I already received the next complaint about an outgoing
> network scan. The logs sent to me clearly confirm scans taking place,
> this is not about the hoster being obstinate.
>
> Looks like I will have to shut down this particular exit for good if
> I cannot find a way to prevent it from being abused as network scan
> central. :-(
>
> -Ralph
> ___
> 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] DoS attacks on multiple relays

[Felix]

Hi everybody

> Looks scary. Interesting to see they all have high guard probabilities. :-?

The reported numbers are nothing to scare about. 100 connects and more
to a relay/subnet can be fine. As well to other servers like onion
services. Lots of connections come with a good (temporary) position.

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

Re: [tor-relays] So long and thanks for all the abuse complaints

[Ralph Seichter]

Quoting myself:

> I've had an ongoing debate with a hosting service over a fresh exit
> node being abused for network scans (ports 80 and 443) almost hourly
> for the last few days.

I had the former exit node unlocked an ran it in relay mode for a day.
Today I switched back to exit mode, and a few hours after the exit flag
was reassigned, I already received the next complaint about an outgoing
network scan. The logs sent to me clearly confirm scans taking place,
this is not about the hoster being obstinate.

Looks like I will have to shut down this particular exit for good if
I cannot find a way to prevent it from being abused as network scan
central. :-(

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

Re: [tor-relays] UbuntuCore stats update

[Torix]

Dear Chad,
The last I read from nusenu a few months ago was that you have tor is running 
as root, which sort of wiped it off my radar.  Is that still true?  I do like 
your idea of democratizing tor relays so normal people can run them.

TIA,

--torix

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

>  Original Message 
> Subject: [tor-relays] UbuntuCore stats update
> Local Time: December 4, 2017 10:18 PM
> UTC Time: December 5, 2017 3:18 AM
> From: c...@cornsilk.net
> To: tor-relays@lists.torproject.org
>
> Hi all. I generate* the packages that make up those UbuntuCore relays and 
> bridges you hear about some time in here.
> I intended it to be a low-friction way normal joes can help Tor. There have 
> been a good number of volunteers.
>
> The automatic-update system of Snap means the security update of a few days 
> ago gives some population info through download stats.
>
> About 2200+ machines updated to last week's release. Almost all are amd64, 
> though a few percent are i386 or armhf. I don't know of any arm64 yet. 
> They're mostly desktops and servers. I see several new downloads every day.
>
> Judging from the new Atlas, about 800 are have checked in to try to join the 
> consensus, and a little more than 100 are active at any time.
>
> Some working details: The package has a kill-switch so that it no longer 
> starts after a few months of staleness (if I'm ever hit by a bus). At first 
> launch, Tor creates a key and the last two bits of the key determines the 
> role of the instance, with a 1/4 chance of becoming a obfs4 bridge. The 
> default bandwidth limit is a modest 4 megabits per second. Also by default, 
> it tries to punch holes in NAT to make itself available for incoming 
> connections, but I don't have a lot of confidence that is often successful.
>
> I remain on this list and am always happy to answer questions or suggestions.
>
> * http://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/files
>
> --
> Chad Millerchad.orggpg:a806deac30420066___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DoS attacks on multiple relays

[Torix]

Me, too: 4 on 178.16.208.0/24 and 10 on  217.12.223.0/24

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

>  Original Message 
> Subject: Re: [tor-relays] DoS attacks on multiple relays
> Local Time: December 5, 2017 7:00 AM
> UTC Time: December 5, 2017 12:00 PM
> From: valter.jans...@gmail.com
> To: tor-relays@lists.torproject.org
>
> A little relay node of a consensus around 220 checking in here. I am seeing 
> pretty much the same as others are reporting - 11 on 188.214.30.0/24 and 10 
> on 217.12.223.0/24.
> The AS is called THC Projects SRL. They seem to provide VPS hosting among 
> other things and [ipinfo.io/AS51177](https://ipinfo.io/AS51177#domains) 
> reports that they host a lot of domains over there as well.
> Not sure how seriously one should take this, but it's interesting for sure 
> regardless.
>
> -- 4096R/A83CE748 Valters Jansons
>
> On Tue, Dec 5, 2017 at 1:50 PM x9p  wrote:
>
>> my second and third positions are similar:
>>
>>   9 217.12.223.0/24 (family and contact info set)
>>   8 178.16.208.0/24 (family and contact info set, too)
>>
>>> Interesting to see. I have similar stats. 10 connections from
>>> 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks!
>>>
>>> On Tue, Dec 5, 2017 at 4:27 PM, x9p  wrote:
>>>

 first measure on a good day how many connection per /24 your exit/relay
 have, excluding these with 1 2 or just 3 connections:

 # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
 -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c |
 sort
 | egrep -v '  1 |  2 |  3 '

 with this information in hand, double the max of it (mine was 10
 connections from 188.214.30.0/24):

  10 188.214.30

 iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
 --connlimit-mask 24 -j REJECT --reject-with tcp-reset

 cheers.

 x9p

 >> connlimit per /24. it does more good than evil.
 >
 > Any guidance on the specifics? Like how many concurrent connections to
 > allow per /24? Not sure what's expected from legitimate user traffic
 > through the relay... don't want to make things worse.
 > ___
 > 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

>>>
>>>
>>>
>>> --
>>> Regardless, I hope you're well and happy -
>>> Aneesh
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>
>> ___
>> 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] So long and thanks for all the abuse complaints

[tor]

Abuse complaints are how this thing goes. With your limited exit 
policy, you would hardly see any complaints (relatively speaking), and 
what you do see would be mostly like SQL hack complaints and such. 
It's usually not going to be cases where someone got all the way into 
someone's machine, it's going to be mainly complaints about attempts.


I feel like a short notification should be all you need and you're 
done with responses to stuff like that, such as:


Hi ,

That is the Tor exit router we host. https://www.torproject.org . 
Unfortunately, bad actors sometimes misuse Tor for things like this.


If your attacker proves to be a serious problem, you may wish to block 
the entire Tor network from your device. A list of Tor exits can be 
seen here (and there is also an RBL somewhere): 
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1 . 
Blocking one Tor exit such as mine won't really stop the person. Also, 
if I configure my node not to exit to you, the attacker won't 
necessarily even notice, as Tor will automatically route him through a 
different exit node.


Regards,

- < your sig >


While it's true that the suggestion about blocking all of Tor isn't 
ideal for the internet at large, in particular as a response to stupid 
scans or web hack attempts that don't actually get in, there are cases 
where it may make sense for a server operator to do that on a single 
system, if only temporarily.


The main points in this response are the explanations of what Tor is 
(via the provided link) and why it never makes sense from the attacked 
server's perspective for a single exit to stop exiting to it 
specifically. The affected server operator has the choice of ignoring 
the attempts, or fixing whatever vulnerability is there if one is 
being exploited, or blocking all of Tor. You as a single exit operator 
are not a part of that.


There was only one time that I got a bullshit response back from 
someone as a result of what I'd sent, and he could be safely ignored, 
as he was just an idiot who thought that Tor was a bad thing. There 
was another guy who was ignoring my responses and emailing our abuse 
box repeatedly - he comes from a relatively rare mindspring.com 
address. If that is the one complaining about your exit, he's 
worthless. I  configured our mail server to reject his abuse 
complaints outright (we own our own IP space, so, this is simpler for 
us than it would be for you). That mindspring.com guy also had the 
bright idea of emailing the networks he saw along his traceroute, 
thinking that we are a customer of those networks (we're not).





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

Re: [tor-relays] DoS attacks on multiple relays

[Valter Jansons]

A little relay node of a consensus around 220 checking in here. I am seeing
pretty much the same as others are reporting - 11 on 188.214.30.0/24 and 10
on 217.12.223.0/24.
The AS is called THC Projects SRL. They seem to provide VPS hosting among
other things and ipinfo.io/AS51177 
reports that they host a lot of domains over there as well.
Not sure how seriously one should take this, but it's interesting for sure
regardless.

-- 4096R/A83CE748 Valters Jansons

On Tue, Dec 5, 2017 at 1:50 PM x9p  wrote:

>
> my second and third positions are similar:
>
>   9 217.12.223.0/24 (family and contact info set)
>   8 178.16.208.0/24 (family and contact info set, too)
>
>
> > Interesting to see. I have similar stats. 10 connections from
> > 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks!
> >
> > On Tue, Dec 5, 2017 at 4:27 PM, x9p  wrote:
> >
> >>
> >> first measure on a good day how many connection per /24 your exit/relay
> >> have, excluding these with 1 2 or just 3 connections:
> >>
> >> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
> >> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c |
> >> sort
> >> | egrep -v '  1 |  2 |  3 '
> >>
> >> with this information in hand, double the max of it (mine was 10
> >> connections from 188.214.30.0/24):
> >>
> >>  10 188.214.30
> >>
> >> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
> >> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
> >>
> >> cheers.
> >>
> >> x9p
> >>
> >> >> connlimit per /24. it does more good than evil.
> >> >
> >> > Any guidance on the specifics? Like how many concurrent connections to
> >> > allow per /24? Not sure what's expected from legitimate user traffic
> >> > through the relay... don't want to make things worse.
> >> > ___
> >> > 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
> >>
> >
> >
> >
> > --
> > Regardless, I hope you're well and happy -
> > Aneesh
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
>
>
> ___
> 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] DoS attacks on multiple relays

[x9p]

my second and third positions are similar:

  9 217.12.223.0/24 (family and contact info set)
  8 178.16.208.0/24 (family and contact info set, too)


> Interesting to see. I have similar stats. 10 connections from
> 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks!
>
> On Tue, Dec 5, 2017 at 4:27 PM, x9p  wrote:
>
>>
>> first measure on a good day how many connection per /24 your exit/relay
>> have, excluding these with 1 2 or just 3 connections:
>>
>> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
>> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c |
>> sort
>> | egrep -v '  1 |  2 |  3 '
>>
>> with this information in hand, double the max of it (mine was 10
>> connections from 188.214.30.0/24):
>>
>>  10 188.214.30
>>
>> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
>> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>>
>> cheers.
>>
>> x9p
>>
>> >> connlimit per /24. it does more good than evil.
>> >
>> > Any guidance on the specifics? Like how many concurrent connections to
>> > allow per /24? Not sure what's expected from legitimate user traffic
>> > through the relay... don't want to make things worse.
>> > ___
>> > 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
>>
>
>
>
> --
> Regardless, I hope you're well and happy -
> Aneesh
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>


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

Re: [tor-relays] DoS attacks on multiple relays

[Aneesh Dogra]

On Tue, Dec 5, 2017 at 5:04 PM, x9p  wrote:

>
> Actually this also caught my attention on this 10 nodes from 188.214.30/24:
>
> https://atlas.torproject.org/#search/188.214.30
>
> All from Romania, relays, ports 443/9030, good bandwidth 17-26MiB, uptime
> almost identical, and no family member set. One is even named CIA :)
>
> Contact is set to none also.
>
> welcome!
>
>
Looks scary. Interesting to see they all have high guard probabilities. :-?

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

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

Actually this also caught my attention on this 10 nodes from 188.214.30/24:

https://atlas.torproject.org/#search/188.214.30

All from Romania, relays, ports 443/9030, good bandwidth 17-26MiB, uptime
almost identical, and no family member set. One is even named CIA :)

Contact is set to none also.

welcome!

> Interesting to see. I have similar stats. 10 connections from
> 188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks!
>
> On Tue, Dec 5, 2017 at 4:27 PM, x9p  wrote:
>
>>
>> first measure on a good day how many connection per /24 your exit/relay
>> have, excluding these with 1 2 or just 3 connections:
>>
>> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
>> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c |
>> sort
>> | egrep -v '  1 |  2 |  3 '
>>
>> with this information in hand, double the max of it (mine was 10
>> connections from 188.214.30.0/24):
>>
>>  10 188.214.30
>>
>> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
>> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>>
>> cheers.
>>
>> x9p
>>
>> >> connlimit per /24. it does more good than evil.
>> >
>> > Any guidance on the specifics? Like how many concurrent connections to
>> > allow per /24? Not sure what's expected from legitimate user traffic
>> > through the relay... don't want to make things worse.
>> > ___
>> > 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
>>
>
>
>
> --
> Regardless, I hope you're well and happy -
> Aneesh
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>


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

Re: [tor-relays] DoS attacks on multiple relays

[Aneesh Dogra]

Interesting to see. I have similar stats. 10 connections from
188.214.30.0/24, second up 8 connections from 178.16.208.0/24. Thanks!

On Tue, Dec 5, 2017 at 4:27 PM, x9p  wrote:

>
> first measure on a good day how many connection per /24 your exit/relay
> have, excluding these with 1 2 or just 3 connections:
>
> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
> | egrep -v '  1 |  2 |  3 '
>
> with this information in hand, double the max of it (mine was 10
> connections from 188.214.30.0/24):
>
>  10 188.214.30
>
> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>
> cheers.
>
> x9p
>
> >> connlimit per /24. it does more good than evil.
> >
> > Any guidance on the specifics? Like how many concurrent connections to
> > allow per /24? Not sure what's expected from legitimate user traffic
> > through the relay... don't want to make things worse.
> > ___
> > 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
>



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

Re: [tor-relays] DoS attacks on multiple relays

[Scott Bennett]

null  wrote:

> We're experiencing what looks like a DoS attack on multiple relays in our
> family:
>
> https://atlas.torproject.org/#search/family:CBEAE10CBBB86C51059246B2EF92EB2CB4E111BC
>
> The relays are currently running Tor 0.3.1.9 on Linux kernel 4.4.0
> (although when the problem started the relays were running Tor 0.3.1.8).
>
> The attack knocked 3 of 6 relays offline overnight. By the time we looked
> at logs, the Tor service had stopped and this was the last line in the log:
>
> "Tor[xyz]: Failing because we have 16351 connections already. Please read
> doc/TUNING for guidance."
>
> The attack is still ongoing. When it's happening, the number of connections
> rises very rapidly, until the attack succeeds in stopping the service.
>
> $ ss -s
> Total: 15855 (kernel 0)
> TCP:   24520 (estab 23969, closed 305, orphaned 31, synrecv 0, timewait
> 261/0), ports 0
>
> Transport Total IPIPv6
> *   0 - -
> RAW   0 0 0
> UDP   8 4 4
> TCP   24215 24213 2
> INET   24223 24217 6
> FRAG   0 0 0
>
> ... and only a few seconds later:
>
> $ ss -s
> Total: 12120 (kernel 0)
> TCP:   27389 (estab 20026, closed 1906, orphaned 45, synrecv 0, timewait
> 1587/0), ports 0
>
> Transport Total IPIPv6
> *   0 - -
> RAW   0 0 0
> UDP   8 4 4
> TCP   25483 25481 2
> INET   25491 25485 6
> FRAG   0 0 0
>
> That's obviously much larger than the normal number of connections, more
> than we've ever seen, and seems like more connections than would be needed
> for a relay.
>
 What you are seeing is most likely the same phenomenon brought up on
this list repeatedly over at least the last decade or so.  That phenomenon
is providing HSDir service, or perhaps a rendez-vous point, for a popular
hidden service.  As soon as your node is associated with that hidden service
and that association begins to be distributed by the HSDir population to
clients looking for that hidden service, the number of connections to your
node will increase fairly rapidly to a level corresponding to that hidden
service's level of popularity.  If you don't like it, you can set

HidServDirectoryV2  0

which will stop clients from trying to get hidden service descriptors from
your node, which will eliminate most of the bursts of connections you're
seeing, but will not prevent your node from being a rendez-vous point because
every tor relay is expected to provide that function as part of the relay
protocols.

> We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks
> like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
>
>   elif [ "$system_max" -gt "4" ] ; then
> MAX_FILEDESCRIPTORS=16384
>
> Surely that is high enough for normal service?

 If by normal you mean "low traffic", then yes, it's probably enough.
However, that's really not very high in a general sense.  Consider also that
some installed packages place high demands upon the supply of file descriptors.
(E.g., I gather you do not have a graphics port/package called piglit installed
on your system, which recommends at least 5 be available for its runs, so
I have

kern.maxfiles="5"

in /boot/loader.conf on my FreeBSD system.  I don't think I can recall tor
ever handling many more than 5000 (i.e., 10% of that figure) at one time on my
low-traffic node.)  The faster, larger-capacity tor nodes often have
considerably higher settings to keep tor from exhausting the fd limits on
those hosts.
>
> We haven't started looking into where the traffic is coming from or other
> characteristics. We are wondering if: 1) this is a known attack, 2) if
> other operators are experiencing it, 3) if there are any ideas for
> mitigating it, and 4) if any additional information would be helpful.
>
 Other than refusing to be a hidden service directory server, there is
probably nothing to be done about it.  Adjust your settings accordingly, along
with your expectations. :-)


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

ps: this was done @ debian. BSD/Solaris/other Unix flavours may need some
tweak in the script.

>
> first measure on a good day how many connection per /24 your exit/relay
> have, excluding these with 1 2 or just 3 connections:
>
> # netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
> -F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
> | egrep -v '  1 |  2 |  3 '
>
> with this information in hand, double the max of it (mine was 10
> connections from 188.214.30.0/24):
>
>  10 188.214.30
>
> iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
> --connlimit-mask 24 -j REJECT --reject-with tcp-reset
>
> cheers.
>
> x9p
>
>>> connlimit per /24. it does more good than evil.
>>
>> Any guidance on the specifics? Like how many concurrent connections to
>> allow per /24? Not sure what's expected from legitimate user traffic
>> through the relay... don't want to make things worse.
>> ___
>> 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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DoS attacks on multiple relays

[x9p]

first measure on a good day how many connection per /24 your exit/relay
have, excluding these with 1 2 or just 3 connections:

# netstat -tupan | grep ESTABLISHED | grep /tor | awk '{print $5}' | awk
-F: '{print $1}' | awk -F. '{print $1"."$2"."$3}' | sort | uniq -c | sort
| egrep -v '  1 |  2 |  3 '

with this information in hand, double the max of it (mine was 10
connections from 188.214.30.0/24):

 10 188.214.30

iptables -A INPUT -i eth0 -p tcp -m connlimit --connlimit-above 20
--connlimit-mask 24 -j REJECT --reject-with tcp-reset

cheers.

x9p

>> connlimit per /24. it does more good than evil.
>
> Any guidance on the specifics? Like how many concurrent connections to
> allow per /24? Not sure what's expected from legitimate user traffic
> through the relay... don't want to make things worse.
> ___
> 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