Hello
I've noticed a reduction in tor traffic about 50% since Sunday. The cpu load stayed almost same. The amount of TCP Sessions increased from ~34k to ~65k. Also the abuse rated about network scans got increased since Sunday.
Does anyone knows what's there going on?
My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate.
Personally I've no problem with some network scans, but this is a bit annoying and I asked myself if this is still a scan or more a DOS.
https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4E...
Kind regards Tim
Same here +1
On 15. Aug 2019, at 16:43, Tim Niemeyer tim@tn-x.org wrote:
Signed PGP part Hello
I've noticed a reduction in tor traffic about 50% since Sunday. The cpu load stayed almost same. The amount of TCP Sessions increased from ~34k to ~65k. Also the abuse rated about network scans got increased since Sunday.
Does anyone knows what's there going on?
My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate.
Personally I've no problem with some network scans, but this is a bit annoying and I asked myself if this is still a scan or more a DOS.
https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4E...
Kind regards Tim
reduction++;
On Aug 19, 2019, at 21:45, niftybunny abuse-contact@to-surf-and-protect.net wrote:
Same here +1
On 15. Aug 2019, at 16:43, Tim Niemeyer tim@tn-x.org wrote:
Signed PGP part Hello
I've noticed a reduction in tor traffic about 50% since Sunday. The cpu load stayed almost same. The amount of TCP Sessions increased from ~34k to ~65k. Also the abuse rated about network scans got increased since Sunday.
Does anyone knows what's there going on?
My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate.
Personally I've no problem with some network scans, but this is a bit annoying and I asked myself if this is still a scan or more a DOS.
https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4E...
Kind regards Tim
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi,
On 15. Aug 2019, at 16:43, Tim Niemeyer tim@tn-x.org wrote:
Signed PGP part Hello
I've noticed a reduction in tor traffic about 50% since Sunday. The cpu load stayed almost same. The amount of TCP Sessions increased from ~34k to ~65k. Also the abuse rated about network scans got increased since Sunday.
Does anyone knows what's there going on?
My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate.
Personally I've no problem with some network scans, but this is a bit annoying and I asked myself if this is still a scan or more a DOS.
https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4E...
On Aug 19, 2019, at 21:45, niftybunny abuse-contact@to-surf-and-protect.net wrote:
Same here +1
On 20 Aug 2019, at 14:35, Larry Brandt lbrandt@cni.net wrote:
This may be similar to my situation with my Finland exit relay [1]. I was finally forced to deal with kern overload that shut my cpu down. I had several thousand IP's without hashed fingerprints opting to get into Tor. A combination of hardening, banning and increasing kern processing to 100,000 helped. Since then I have a Consensus Weight of 600 rather than the 8000 before the intrusion. Strange thing: ufw banning and reboot does not seem to stop a few of the Iranian IP addresses--they're still there.
We think this is a result of Iranian censorship, I think the anti-censorship team are working on the issue. I've cc'd Philipp for more info.
On 20 Aug 2019, at 12:56, John Ricketts john@quintex.com wrote:
reduction++;
This could be a result of load balancing changes due to Rob's bandwidth experiment.
CPU overloads could also be a result of load balancing changes. The tests only used a few large bandwidth circuits, but the CPU usage of lots of small circuits is much higher.
I've cc'd Rob to get his opinion.
T
Hi
Just short: i noticed the high rate of ssh abuse mails. So I started to test to reject (via tor config) the ssh port. Traffic and load now looks a lot better. So it seems to be a brute force attack which slows down the exit due to too much too small packets.
Tim PS: @teor: did you forgot the cc's?
Am 20. August 2019 08:05:36 MESZ schrieb teor teor@riseup.net:
Hi,
On 15. Aug 2019, at 16:43, Tim Niemeyer tim@tn-x.org wrote:
Signed PGP part Hello
I've noticed a reduction in tor traffic about 50% since Sunday. The
cpu
load stayed almost same. The amount of TCP Sessions increased from
~34k
to ~65k. Also the abuse rated about network scans got increased
since
Sunday.
Does anyone knows what's there going on?
My guess is that since Sunday anyone uses Tor for extended network scans, which results in a very high packet rate.
Personally I've no problem with some network scans, but this is a
bit
annoying and I asked myself if this is still a scan or more a DOS.
https://metrics.torproject.org/rs.html#search/family:719FD0FA327F3CCBCDA0D4E...
On Aug 19, 2019, at 21:45, niftybunny
abuse-contact@to-surf-and-protect.net wrote:
Same here +1
On 20 Aug 2019, at 14:35, Larry Brandt lbrandt@cni.net wrote:
This may be similar to my situation with my Finland exit relay [1].
I was finally forced to deal with kern overload that shut my cpu down. I had several thousand IP's without hashed fingerprints opting to get into Tor. A combination of hardening, banning and increasing kern processing to 100,000 helped. Since then I have a Consensus Weight of 600 rather than the 8000 before the intrusion. Strange thing: ufw banning and reboot does not seem to stop a few of the Iranian IP addresses--they're still there.
We think this is a result of Iranian censorship, I think the anti-censorship team are working on the issue. I've cc'd Philipp for more info.
On 20 Aug 2019, at 12:56, John Ricketts john@quintex.com wrote:
reduction++;
This could be a result of load balancing changes due to Rob's bandwidth experiment.
CPU overloads could also be a result of load balancing changes. The tests only used a few large bandwidth circuits, but the CPU usage of lots of small circuits is much higher.
I've cc'd Rob to get his opinion.
T
On Aug 20, 2019, at 2:05 AM, teor teor@riseup.net wrote:
On 20 Aug 2019, at 12:56, John Ricketts john@quintex.com wrote:
reduction++;
This could be a result of load balancing changes due to Rob's bandwidth experiment.
CPU overloads could also be a result of load balancing changes. The tests only used a few large bandwidth circuits, but the CPU usage of lots of small circuits is much higher.
I've cc'd Rob to get his opinion.
I scanned each relay once for less than 30 seconds. I don't plan on repeating the experiment. It looks like the advertised BWs have reverted, at least on a global level (it's possible that individual relays may still notice an adjustment though).
https://metrics.torproject.org/bandwidth.html?start=2019-08-01&end=2019-...
Sorry I don't have anything more informative to say at the moment.
Peace, love, and positivity, Rob
On Tue, Aug 20, 2019 at 04:05:36PM +1000, teor wrote:
On 20 Aug 2019, at 14:35, Larry Brandt lbrandt@cni.net wrote:
This may be similar to my situation with my Finland exit relay [1]. I was finally forced to deal with kern overload that shut my cpu down. I had several thousand IP's without hashed fingerprints opting to get into Tor. A combination of hardening, banning and increasing kern processing to 100,000 helped. Since then I have a Consensus Weight of 600 rather than the 8000 before the intrusion. Strange thing: ufw banning and reboot does not seem to stop a few of the Iranian IP addresses--they're still there.
We think this is a result of Iranian censorship, I think the anti-censorship team are working on the issue. I've cc'd Philipp for more info.
This is the first time I heard about this issue. I'll bring this up during Thursday's anti-censorship meeting.
Cheers, Philipp
tor-relays@lists.torproject.org
-
John Ricketts -
Larry Brandt -
niftybunny -
Philipp Winter -
Rob Jansen -
teor -
Tim Niemeyer