- tor-relays - lists.torproject.org

a characteristic of recent attacks?
by Scott Bennett 01 Sep '22

01 Sep '22

The vast majority of recent surges of unusual activity on my humble relay, which I take as likely being attacks, result in large changes in the hour-to-hour statistic shown below in these lines extracted from the hourly heartbeat message groups. Aug 31 19:02:28.549 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 20:02:28.546 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 21:02:28.549 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1706742 INTRODUCE2 rejected. Aug 31 22:02:28.544 [notice] Heartbeat: DoS mitigation since startup: 15 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 1770970 INTRODUCE2 rejected. Aug 31 23:02:28.556 [notice] Heartbeat: DoS mitigation since startup: 16 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 14 same address concurrent connections rejected, 0 connections rejected, 5 single hop clients refused, 2013266 INTRODUCE2 rejected. The most recent such surge appears to have ended less than an hour ago. Note that there was no change in the count of "INTRODUCE2 rejected" for many hours leading up to the onset of unusual activity, though I've only shown three prior hours' worth. Then there is an increase of 63227 in this count during the first hour and another 41296 during the second hour. Often during these periods the input appears to be maxed out, and sometimes the output rate is still higher by several hundred KB/s. My question is, do other relay operators whose relays are being attacked see the same phenomenon? In addition, if someone knows of an effective way to turn such things aside at less cost than be simply leaving them to tor to deal with, I'd love to know about it, too, though I suspect there may be no such method. Thanks in advance for any relevant information! 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 * **********************************************************************

2 2

One of my relays does not get a "consensus weight" value and is not in the list.
by failing.flyaway443＠mailer.me 30 Aug '22

30 Aug '22

Hello everyone, I have a question about another relay I deployed a few days ago. This time I set up two relays on a server with only one IP address, almost simultaneously. They are "Infinity1" and "Infinity2". I kept looking at the Relay Search to see how everything was going, and Infinity1 already has a consensus weight of 36000, but Infinity2's value is still at 1. So I looked at the big consensus list, and sure enough, it only has Infinity1 in it. Could it be that the Directory Authorities do not accept Infinity2 for some reason, or should I just be patient a bit longer? I also noticed that Infinity1 is already moving an average of 15Mb/s of traffic, while Infinity2 is still hanging around in the Kb range. Of course I did everything correctly, MyFamily and ContactInfo are set. Does anyone here know what this could be? The fingerprint of Infinity2 is 9F459D4756AA61D7ED05D000EA4C757FA19AC401. Thank you everyone for taking the time to think about this for a moment and have a great day to you all! Best

1 1

OOM Bytes Cell
by Nyasaki Server 29 Aug '22

29 Aug '22

Hi, my node is running for a while now, today I noticed that the cell oom bytes has risen, which never happened before. Is this concerning? What does the cell value mean? Im thankful for every input! BR Nyasaki

1 0

Closing relay
by Ole Rydahl 29 Aug '22

29 Aug '22

Since 2014 I have run a non-exit relay at my premises. However ultimo July the system load increased abruptly. Idle-cpu -typically 60-70% - dropped to 30%, _and_ with frequent drops to 0! I reduced the max bandwidth to 1.2 Mbytes. That reduces the load somewhat but still with frequent spikes where the idle-cpu hits 0 and I get the "relay too slow" indication. Any suggestions? /Ole Rydahl https://metrics.torproject.org/rs.html#details/CE1FD7659F2DFE92B883083C0C6C9 74616D17F3D

2 1

Overload
by sysmanager7 27 Aug '22

27 Aug '22

Another New one: 19:01:09 [NOTICE] General overload -> Ntor dropped (176948) fraction 25.2668% is above threshold of 0.5000% â 17:19:32 [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth â config option or choosing a more restricted exit policy. Any Ideas?? What is the syntax for MaxAdvertisedBandwidth? Currently is: MaxAdvertisedBandwidth 3Mb Sysmanager Sent with [Proton Mail](https://proton.me/) secure email.

1 0

missing IPv6 close events
by Toralf Förster 27 Aug '22

27 Aug '22

Playing with Python and Stem I wrote a script to monitor the ORStatus.CLOSED event reasons [1]. A helper script [2] gives statistics from those data. From the last 2 days I got: $> orstatus-stats.sh /tmp/orstatus.29051 CONNECTRESET 6197 CONNECTRESET 13214 DONE 18769 IOERROR 58 NOROUTE 1661 TIMEOUT 2562 TLS_ERROR 42461 I was wondering if it is expected that DONE is just a 1/4 of all reasons. And I do wonder why all events are IPv4 only. [1] https://github.com/toralf/torutils/blob/main/orstatus.py [2] https://github.com/toralf/torutils/blob/main/orstatus-stats.sh -- Toralf

1 0

Warn:
by sysmanager7 24 Aug '22

24 Aug '22

I got the below message on my relay #2. It's been in operation for a year and a half. First time I've ever got one of these. 0re7:26:40 [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [505 similar message(s) suppssed in last 57840 seconds] OK > Both relays operate on Digital Ocean Droplets Bandwidth on both 2 MBs Burst 3MBs both relays have the same settings NEITHER is an exit: ExitPolicy reject I see relay #2 has been restarted. Last eve it had been up four days. As of this writing just over 2 hours. Or is this another way to muck up a relay? Sysmanager Sent with [Proton Mail](https://proton.me/) secure email.

1 0

We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
by elise.toradin＠web.de 24 Aug '22

24 Aug '22

4 3

Strange entries in notices.log
by toritdown 23 Aug '22

23 Aug '22

I am suddenly finding numerous entries in my /var/log/tor/notices log that look like this: Aug 22 01:21:46.000 [warn] Unable to store router descriptor Aug 22 01:21:46.000 [warn] Error writing to "/var/lib/tor/cached-descriptors.new": No space left on device What does this mean? What do I need to do about? Sent with [Proton Mail](https://proton.me/) secure email.

4 3

Relays spamming my OR port
by Logforme 19 Aug '22

19 Aug '22

I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 I have tried to mitigate the current DoS by implemented connection limits in my iptables using Toralf's template: More than 25 connection during 10 mins and you end up on my naughty list. Lots of connection attempts from the naughty list dropped but still my relay gets "overloaded" However, I have noticed that a few relays also end up on the naughty list, and I wonder how that can happen. My understanding is that a relay will only open 1 connection to another relay so should therefore never end up on the list. Correct? D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent naughty boy. Maybe these relays disconnect and reconnect to my relay frequently due to network issues (effect from the DoS?) or from not having enough connections available on the router? I guess my real question is if these connections are legit and I'm hurting the Tor network by using connection limits?

4 10