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


This is a companion discussion topic for the original entry at https://blog.torproject.org/defending-tor-mitigating-ip-spoofing
8 Likes

We like to contribute to this effort. We have compiled a list of 12,407 potentially spoofed IPs during the attack campaign. Who do we send it to?

Please contact security@torproject.org.

Email sent containing link to the Google sheet.

Interesting stuff.

> the origin of these spoofed packets was identified and shut down on November 7th, 2024.

Could you guys share some more info about the attacker? Nation-state, malware group, something else?

3 Likes

Additional questions:

  1. Were there any consequences for attacker? Can he easily relaunch attack from different “origin”?
  2. What steps were necessary for “identification” and “shutting down”? Such “guide” can be useful in case of other attacks. Previous attacks on Tor stopped because attackers got bored as far as I know. This is not how such large project as Tor should protect itself.

Honestly, I was disappointed by this blog post. So many words, but so little usable information.

1 Like

Agreed. At the very least, we should be informed who the perpetrator was. This is required information if for nothing else than to allow a judgement to be made by operators on whether to block the IP range in case of further issues.

The perpetrator was not shy about their activities. I would like to know who it was, or a reason why it’s being withheld.

3 Likes

The spoofig is still a real thing.
One of my relays was just blocked. This time is from another ISP (not the one from last time) that directly closed the relay :frowning: (the other one was more professional and asked me stuff first)

1 Like

Yes. From two different relays:

tcp sport 22 tcp flags == 0x12 counter packets 431 bytes 25156

and

tcp sport 22 tcp flags == 0x12 counter packets 66 bytes 3936

Second relay shown above started as tor relay AFTER the annoucement that the source of the spoofing had been found and shut down.

From all the other machines I own, manage, or control that have never run relays:

tcp sport 22 tcp flags == 0x12 counter packets 0 bytes 0

Analysis: Spoofing is still occuring, still actively targetting new relays which are coming online, and seems to only be targeting relays. Which is why we need to know who the known perpetrator was.

In better news, I am monitoring about a hundred other ports for evidence of spoofing and see so far see none. That said, port 22 is sort of special, though, as one of the only ports that is both very commonly used across the wider internet and yet not a port that welcomes anonymous/public connections.

UPDATE: From nature and timing of port 22 SYN-ACKS received on my machines, I now suspect they are as a result of connections to a current relay operator. I believe adversary is using incoming tor relay connections to trigger outgoing port 22 spoofs, with the mechanism perhaps as simple as a TEE + DNAT.