From: J@M   
      
   (using Tor Browser 14.0.1)   
   https://blog.torproject.org/defending-tor-mitigating-IP-spoofing/   
   >Defending the Tor network: Mitigating IP spoofing against Tor   
   >by gus | November 8, 2024   
   >At the end of October, Tor directory authorities, relay operators, and even   
   the   
   >Tor Project sysadmin team received multiple abuse complaints from their   
   >providers about port scanning. These complaints were traced back to a   
   >coordinated IP spoofing attack, where an attacker spoofed non-exit relays and   
   >other Tor-related IPs to trigger abuse reports aimed at disrupting the Tor   
   >Project and the Tor network.   
   >Thanks to a joint effort from the Tor community, InterSecLab, and the support   
   of   
   >Andrew Morris and the team at GreyNoise, the origin of these spoofed packets   
   was   
   >identified and shut down on November 7th, 2024.   
   >We want to reassure everyone that this incident had no effect on Tor users.   
   >While the attack had a limited impact on the Tor network - taking a few relays   
   >offline temporarily - it caused unnecessary stress and inconvenience for many   
   >relay operators who had to address these complaints. Although this attack   
   >targeted our community, IP spoofing attacks can happen with any online   
   service.   
   >There's still work ahead: we need to support relay operators in getting their   
   >accounts reinstated and assist providers in unblocking IPs for Tor directory   
   >authorities.   
   >Hosting providers and abuse complaints   
   >If you are a relay operator whose hosting provider is still blocking or has   
   >suspended your relay due to these complaints, here are steps you can take to   
   >resolve the issue:   
   >1. Check Tor directory authorities reachability from your relay: If you   
   suspect   
   >your provider has blocked Tor access -- i.e., because your relay dropped from   
   >the Tor consensus --, use OONI Probe and "Circumvention" test to check the   
   >reachability of Tor directory authorities. If the test shows that most   
   directory   
   >authorities are reachable, your relay will successfully (re-)connect to the   
   Tor   
   >network. If Tor directory authorities are still blocked, please contact your   
   >hosting provider support and share this blog post.   
   >2. Reply to your hosting company: If you got contacted by your provider due to   
   >the abuse complaints, share this blog post to help them understand the   
   incident   
   >and clarify that your Tor relay was targeted by a spoofing attack, and is NOT   
   >originating any suspicious traffic. You can adapt and use this template about   
   >abuse complaints.   
   >Community strength and collaboration   
   >This incident has demonstrated the resilience and collaborative spirit of the   
   >Tor relay operator community. Over the past days, we've seen many instances of   
   >good collaboration to defend the Tor network: analysis, investigation, and   
   >knowledge sharing. Relay operators worked together to troubleshoot issues,   
   >support each other over email and chat, and keep relays online.   
   >We encourage relay operators to stay connected and informed through our   
   official   
   >community channels and participate in our monthly relay operator meetups.   
   >Thank you to every relay operator for your ongoing efforts to run relays,   
   >protect online privacy, and support the Tor Project! <3   
   >Background: What happened?   
   >On October 20, Tor directory authorities began receiving abuse complaints   
   >claiming that their servers were engaged in unauthorized port scans. In the   
   Tor   
   >network, directory authorities play a critical role in maintaining the list of   
   >available relays.   
   >This attack focused on non-exit relays, using spoofed SYN packets to make it   
   >appear that Tor relay IP addresses were the sources of these scans. This led   
   to   
   >automated abuse complaints directed at data centers such as OVH, Hetzner, and   
   >other providers. The attacker's intent seems to have been to disrupt the Tor   
   >network and the Tor Project by getting these IPs on blocklists with these   
   >unfounded complaints.   
   >Pierre Bourdon, a relay operator, shared insights into the attack in his post,   
   >"One weird trick to get the whole planet to send abuse complaints to your best   
   >friend(s)", which sheds light on how the attacker used spoofed IP packets to   
   >trigger automated abuse complaints across the network. A huge thank you to   
   >Pierre for his detailed analysis and for sharing his findings with the   
   >community!   
   >While we received support from many individuals and organizations during this   
   >incident, we also experienced instances of unprofessional conduct, where a the   
   >refusal to investigate and lack of diligence inadvertently amplified the   
   impact   
   >of this attack. Much of the reporting on this fake abuse attack comes from   
   >watchdogcyberdefense[.]com and we endorse the calls within the cybersecurity   
   >community to treat these reports with caution.   
   >For a more detailed discussion, please refer to our public ticket on the issue   
   >and our mailing list.   
   >While spoofing activity is not specific to Tor, it's concerning that someone   
   >would choose to deliberately disrupt a service that is essential for people   
   >experiencing digital surveillance and internet censorship. Tor plays a   
   critical   
   >role in supporting freedom of access and expression globally, and targeting it   
   >undermines these fundamental rights. We are grateful for the resilience and   
   >dedication of our relay operator community, whose collective efforts ensure   
   the   
   >strength of Tor's decentralized network.   
   [end quoted plain text]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)