Starting on February 15th, our primary network AS401720 was hit with a series of L3/L4 DDoS attacks from a Mirai botnet. For those not aware, a DDoS attack is designed to take down services and networks (not breach something). The attacks peaked at over 100 Mpps (million packets per second) and over 10 Gbps in traffic bursts. The primary target was our Matrix homeserver.
We’re confident that we know who is responsible. We believe this was not a state-sponsored attack. We’re not going to name the individual or group publicly at this time, but we are preserving all of the evidence. At this time no one has publicly come forward to claim responsibility.
This post covers what happened, what we did to mitigate it, and what we’re doing to harden our infrastructure going forward.
Background
AS401720 is our core network. It hosts most of our public-facing Secure Infrastructure (SI) services, including the Unredacted Matrix server, XMPP.is, and several internal systems. Our other networks and services were not affected, such as NoiseNet – our experimental anycast network designed for privacy.
Our core network is typically low in traffic volume, and built with reliability in mind. However, our router could not handle the influx of high packet volume & low packet size attacks that we received. These types of attacks are specifically designed to exhaust CPU cycles, and that’s exactly what they achieved.
Timeline
Feb 15, 17:30 UTC – The first series of volumetric attacks were ingested by our router. This caused our router’s CPU to become completely saturated.
Reports of issues started to come in about the instability of our services, and our moderation team started to investigate and scour our metrics for potential issues. They discovered potential problems with our network. Unmitigated attacks sporadically continued until 22:07 UTC.
The amount of packets which passed through our WAN (in million packets per second)The amount of packets which were dropped on our WAN interface (in million packets per second)The CPU usage on our router during the initial wave of attacks
Feb 15, 20:35 UTC – Our core team got online, and started looking through our infra with a fine-grained comb to figure out what was going on. We discovered that our router was the point of congestion.
We scrambled to find ways that we could address the problem and contacted our upstream network. We quickly discovered that they happened to be in the process of reworking their DDoS mitigation systems. As such, no mitigations were being applied.
We decided the best course of action was to migrate our services to an IP prefix being protected by Cloudflare’s Magic Transit which can properly handle volumetric floods.
Feb 15, 21:45 UTC – We started to onboard our services behind our Magic Transit protected IP prefix. To do this, we had to change the IP on every machine and update DNS records.
Feb 16, 00:05 UTC – The first attack came through on our new prefix. Magic Transit mitigated the entire flood, protecting our network completely.
The first flood which Magic Transit mitigated successfully
Feb 16, 00:45 UTC – We finished moving our services behind Magic Transit, and stopped advertising our original prefixes to our upstream provider to protect our network from pivoting attacks.
Feb 16, 06:30 UTC – Another flood came in, and was completely mitigated by Magic Transit.
The second flood which Magic Transit mitigated successfully
Feb 16, 10:29 -> 11:49 UTC – The attacker pivoted in their methods by sending a flood with multiple protocols. Magic Transit mitigated most of the floods, but some leaked through resulting in a very low amount of packet loss on our network.
The third set of floods which Magic Transit mostly mitigated successfully
Attack characteristics
Source: Mirai botnet
Distribution: Worldwide
Protocols: UDP, TCP, GRE
TCP flags: Nearly all
Ports: Various different ports
Packet sizes: Low (less than 300 bytes)
Packet rate: 2-100Mpps+
Bandwidth: 10Gbps+
Impact
The primary target was our Matrix homeserver. However, it affected nearly all of our core services due to the CPU exhaustion it caused on our router.
The timeline above covers the sequence of events, so we won’t repeat it here. The short version is that we migrated all affected services behind Cloudflare’s Magic Transit in about three hours, and withdrew our original prefix announcements to prevent the attacker from pivoting around it. No services went down after the migration.
What didn’t work was relying on our upstream’s DDoS mitigation. We were caught at a bad time with their systems being reworked, but it exposed a dependency we shouldn’t have had. Our router was also never specced for this kind of packet rate, and that’s something we should have planned for.
Attribution
This was a targeted attack against our Matrix homeserver. We’re confident that we know who is responsible. We’re not disclosing that information publicly right now, but this was not the work of a government or state-sponsored actor. No one has publicly come forward to claim responsibility.
The attack used a Mirai botnet, which is widely available and commonly rented. The targeting of our Matrix homeserver specifically, combined with other indicators we’ve observed, makes us confident in who did this.
What we’re doing next
This attack exposed weaknesses in our core network that we’re now addressing.
Magic Transit stays. We’re keeping all of our core services behind Cloudflare’s Magic Transit going forward. It proved itself during this incident, and we’re not going back to relying on upstream mitigations alone (at least until we are very confident they work well).
Router hardening. Our router was the single point of failure. It was never built to handle 100Mpps+ of low-size packet floods, ideally we can fix that. We’re evaluating hardware upgrades that can handle high packet rates without CPU exhaustion. We’re not completely sure that this is something we’ll do due to rising hardware costs. However, we’ll be looking into it.
Reviewing what else belongs behind NoiseNet.NoiseNet was designed in part to distribute load and mitigate DDoS attacks through its anycast edge. Our core services on AS401720 were not behind it. As we stabilize NoiseNet, we’ll evaluate whether some of these services should be routed through it for the additional resilience it provides. However, this will take additional time as we have yet to develop proper automation for NoiseNet.
Final thoughts
Running infrastructure that helps people access the open Internet and communicate privately means accepting that it will be attacked. We’ve dealt with abuse reports, threats, and now sustained DDoS attacks. None of it changes what we do or why we do it.
We spent countless hours building out our infrastructure and network to be resilient, and we’re working on making them even more so. Although we’re just a small non-profit, the reliability of our services like our Matrix server, XMPP.is, FreeSocks, and our Tor relays is crucial to us. We aim to be as transparent as possible when things go wrong.
If you want to help us build more resilient infrastructure, consider making a donation. If you have questions, join one of our community chats.
The Matrix.org Foundation posted yesterday that “public Matrix servers will also have to uphold age verification laws, as misguided as they might be.” This is true for them. They’re based in the UK and subject to the Online Safety Act. But it is not true as a general statement, and it’s not true for us.
Unredacted is a 501(c)(3) non-profit incorporated in Delaware that builds Internet infrastructure and services to help people access the open Internet and protect their right to privacy. We run Tor relays and bridges, operate FreeSocks to provide free VPNs to people in censored countries, run proxies for Signal and Telegram, and host free and open federated chat services, including our Matrix homeserver and XMPP.is. Our infrastructure is in the United States. We are subject to US law. The UK Online Safety Act does not apply to us, and no US law requires us to comply with it.
The SPEECH Act (28 U.S.C. §§ 4101-4105) specifically prohibits US courts from enforcing foreign content-based judgments unless the foreign law provides at least as much free speech protection as the First Amendment. The Online Safety Act doesn’t come close. It mandates removal of constitutionally protected speech, imposes proactive content monitoring, and criminalizes content that is legal here. The SPEECH Act also incorporates Section 230, which shields platforms from liability for user-generated content. Every state has adopted laws that exclude foreign regulatory fines from enforcement. The US-UK Mutual Legal Assistance Treaty covers criminal matters only and explicitly excludes regulatory enforcement. There is no treaty or agreement that requires a US entity to comply with UK administrative regulations.
The US government has taken this position too. FTC Chairman Ferguson warned tech companies in August 2025 that censoring Americans at the request of a foreign power could violate US law, naming the Online Safety Act specifically. 4chan and Kiwi Farms filed a federal lawsuit challenging Ofcom’s enforcement on First Amendment and SPEECH Act grounds.
What about US age verification laws? Also not applicable.
There is no federal age verification law for general Internet services. COPPA, the only relevant federal law, applies to commercial websites and online services. The FTC explicitly states it does not apply to nonprofit entities exempt from Section 5 of the FTC Act. We are a 501(c)(3). COPPA does not apply to us.
At the state level, 25 states have passed age verification laws, but they target commercial pornography sites (where a third or more of the content is pornographic) and large commercial social media platforms (often with revenue thresholds of $100 million+). We are a non-profit running federated chat servers. None of these laws were written for us and none of them apply.
The Supreme Court upheld age verification for adult content sites in Free Speech Coalition v. Paxton last June, but that ruling was narrow and specific to commercial pornographic websites. Courts have continued to block most social media age verification laws on First Amendment grounds.
We prohibit illegal content and material that causes real harm across all of our services, Matrix and XMPP.is alike: no CSAM of any kind, no threats of violence, no content that harms humans or animals. Over the years we’ve put real work into responding to abuse reports and clamping down on misuse of our platforms. We do this because those are our values, not because a foreign regulator demands it and not because we’re legally required to age-gate our chat servers.
We will not be implementing age verification. We will not be collecting government IDs from our users. These things are antithetical to why Unredacted exists. Our entire purpose is to help people communicate freely and privately, whether that’s someone in a censored country connecting to Signal through our proxies or someone joining a Matrix room on our homeserver. Building a surveillance apparatus on top of that would undermine everything we do.
Matrix.org is right about one thing: in Matrix you have the opportunity to run your own servers as you wish. We encourage everyone to take them up on that. If you’re coming from Discord, don’t register on matrix.org. It’s UK-based and subject to the Online Safety Act. Register on a server that isn’t.
Over the many years that we’ve operated our free and public federated chat services, XMPP.is and the Unredacted Matrix server, we’ve quickly and effectively responded to abuse reports and made great strides in clamping down on the blatant abuse of our services. This hasn’t come without a cost, as we’ve spent countless hours banning thousands of accounts and rooms involved in all sorts of nefarious behavior.
Our moderation efforts
While we attempt to moderate effectively, XMPP has been and is notoriously hard to develop moderation solutions for. For example, we have to perform all actions on the command-line and develop scripts that parse through the flat-file storage of our server (it doesn’t use a DB). Generally, XMPP users are much more well-behaved from our observations and lack of abuse reports. We haven’t had a huge problem with abusive users besides the occasional spammer. It’s also hard to keep tabs on statistics for XMPP moderation, so we don’t have many unfortunately.
Matrix is a different story, with a proper database and a robust admin API – we are enabled to do much more. We’re able to look back at our stats, and see what we’ve done so far.
We’ve compiled some information on our efforts below.
We have blocked over 600 rooms from external Matrix servers involved in the distribution of harmful content based on room names, descriptions and other observed patterns.
Locked nearly 500 user accounts which signed up to our Matrix server and engaged in nefarious behavior.
Installed the Draupnir moderation bot, which will enable us to properly moderate our rooms and protect against various spam attacks.
Began the exploration of new moderation solutions which allow us to automate parts of our work.
New rules
Although Unredacted advocates for free speech, objectively harmful or even dubiously harmful content that harms humans or animals is not welcome. It potentially jeopardizes the good natured people using our servers as a haven from the dragnet surveillance from governments and that which is employed by many of the corporate world’s unencrypted and insecure chat services.
We spent a very long time thinking about what is fair, and attempting to not be too rigid at the same time. A part of this process was asking our community for feedback as well. We felt that we’ve come up with the right set of rules, and it’s time to implement them. Our goal here is to create communities that are as safe as possible, and without having to moderate each user and room closely. As such, users and rooms created on our chat services must comply with the following rules.
Chat Service Rules
Illegal or objectively harmful content is not allowed.
No CSAM (including real/fictional/illustrations/AI/3D), threats of violence, or content that harms humans or animals.
Violence, gore, or disturbing imagery is not allowed.
No media, discussions or rooms that glorify violence, gore, abuse, or any extreme content that harms humans or animals.
No promoting, glorifying, encouraging, or normalizing behaviors, ideologies, or practices that are harmful, abusive, or illegal to humans or animals.
Don’t be a jerk in official Unredacted rooms and discussions.
This means no excessive trolling or lack of general civility.
NSFW themes are not allowed in Official Rooms.
No adult content which includes no clearly NSFW media, discussions, or profile pictures in official Unredacted rooms.
NSFW rooms have rules.
NSFW rooms on Unredacted server must comply to these rules. These rooms must:
Be and remain unpublished from the server’s room directory.
Room Owners are required to join the “Unredacted Room Owners” room. (Request an invite from a server admin or mod).
Moderate their rooms and ensure a zero tolerance rule for illegal content.
Report illegal content in the “Unredacted Room Owners” room or contact a server admin directly.
Illegal acts and content will lead to an instant ban. Otherwise, we will issue you a warning if you are breaking any of the rules. If you continue to break the rules you will be banned.
Our thought process
As there will be some that disagree with our new rules and decision to implement them, we want to explain ourselves and our thought process going into this. We don’t intend to force a version of religious morality. We intend to be fair and just in our decisions, and want to promote peace.
Part of our mission is to “operate with transparency, morality and empathy with the purpose of benefiting all living beings.” There is a lot of content on the Internet that is not in line with those values, and frankly; we want to keep it off our services (as we have always done in a legal context). Content which harms humans or animals is simply objectively abhorrent. It doesn’t promote goodness or civility. It actively subverts all of what we stand for.
What’s next?
As of the posting of this blog, the rules will have gone into effect. Over time, we will slowly reach out to users and room owners which violate these new rules (which are not illegal). Depending on the severity of the violations we will generally give existing room owners a grace period before removing their rooms. Any new rooms which violate these rules will be removed at our discretion.
Censorship is on the rise, and has been for a while. Censors are working hard every day to restrict access to crucial information that challenges their authoritarian regimes across the world. It’s important that we continue work to counter their efforts, and develop new and innovative ways to build out anti-censorship infrastructure which helps people evade unjust Internet restrictions.
Since late last year, we’ve been experimenting with various ideas and projects to aid in the advancement of anti-censorship and privacy-focused infrastructure. Experimentation is a big part of what we do, and it’s important to continue with that experimentation. To house all of these experiments, we created the concept of Unredacted Labs. While most of the work was conducted in secret, we’ve dropped hints about our work via our community chats and social media channels in the past.
It’s time that we show the public what is and has been happening inside the Unredacted Labs.
NoiseNet is an experimental anycast network designed by Unredacted that attempts to introduce noise (randomness) and an additional layer of encryption into parts of our network, making it more more difficult for censors to monitor and perform traffic correlation attacks against parts of our infrastructure. NoiseNet also helps us distribute load across our network and mitigate DDoS attacks.
NoiseNet operates on top of AS401401, and has edge routers distributed all over the world which can be seen below.
Understanding the NoiseNet flow
When a packet is destined to an anycasted NoiseNet prefix, it’ll generally reach the closest PoP to where the packet originated. Depending on the specific destination, the NoiseNet edge node will route the packet through an encrypted tunnel to the core router(s) where it should be delivered to. The router(s) will then pass it to the server it’s destined for where the encrypted tunnel terminates. This means that not even the core router(s) in our datacenters can inspect the true nature of inbound packets. Only the network before the edge node (the upstream), the edge node itself, and the server in which the packet is destined for can see what an inbound packet contains. This essentially reduces the amount of intermediary networks that can potentially snoop on our traffic, while also making it generally more difficult to do so at the same time.
Once the server processes an inbound packet, it can generate a response which is sent directly out via our upstream provider(s) in the datacenter where the server lives.
Breakdown of the flow of packets through NoiseNet
Packet gets sent to a NoiseNet prefix.
A NoiseNet PoP receives the packet.
The router forwards the packet to the proper core router via an encrypted tunnel.
A core router forwards the tunnel flows to a server, where the tunnel terminates.
The server generates a response, and sends the packet back out to the core router.
The core router forwards the packet directly via it’s upstream(s) back to the source.
Visual examples of how packets can flow through NoiseNet
User -> NoiseNet PoP -> encrypted tunnel -> core router(s) -> endpoint
This design makes it harder for snoopers to snoop due to the following:
It results in the ingress and egress network paths being asymmetrical, and makes correlating ingress and egress flows more difficult for a censor or would-be snooper.
It encapsulates each packet destined to our core network PoPs, so that it reduces the amount of intermediary networks that can observe and track flows going through NoiseNet.
There’s also several ways that NoiseNet introduces additional noise and resiliency into our network.
Anycasting our prefixes (advertising them from all of our PoPs) creates variance in network paths when packets are en route to our edge network. The more upstreams and Internet Exchange points (IXPs) we’re connected to, the more diversity there is in the ways different networks can reach ours. The more paths to our edge network, the harder it is for snoopers to conduct dragnet surveillance.
No single point of failure. We have a large amount of edge nodes, and additional core network PoPs can be created at will, creating more network path diversity and general resiliency.
Our distributed edge network allows us to more easily mitigate DDoS attacks, because the load is spread out across our entire network rather than a single point of ingress.
Diversity is our strength
The more upstreams we have, and Internet Exchanges Points (IXPs) we’re on, the better. Many of our upstreams are tier 2 or tier 3 networks, and they advertise our prefixes over their own interconnections with other networks. We’re continually working on expanding NoiseNet by deploying new edge nodes around the world and connecting directly to more Internet Exchanges.
Our upstream network providers
Our Internet Exchange points
How we utilize NoiseNet today
Currently, at the time of writing NoiseNet ingests and routes packet for all of our Tor exit relays. As we assess the stability and feasibility of NoiseNet, we’ll begin to host more of our services behind it. Until then, we may periodically disable NoiseNet by unicasting our IP prefixes for research & testing purposes.
While the foundations of NoiseNet are in place, we have a lot of work to do.
Below is a list of things we’re planning to develop over time.
Partner with more companies & organizations that can downstream us. A special thank you to Triplebit, a nonprofit who has partnered with us and become one of our upstream networks.
Consideration to exchange routes over our edge & core allowing for the egress of packets from our core back over tunnels to edge nodes to keep traffic more “local” if packets can be routed over an IXP or kept more local in some way.
The development of noisenet-randomizer, a program that utilizes Traffic Control (TC) and/or eBPF to introduce random delays in packet processing/routing on our edge or core network.
There are some glaring issues that we need to resolve before NoiseNet is considered stable as well.
Some of our upstreams appear to track L4 connections, and drop packets for flows which they have not observed us initiating (an anti-spoofing DDoS protection mechanism). This causes an issue with our current design, and can cause packet loss or blackholed inbound traffic in certain PoPs. We are working on a way to detect this and disable prefix advertisement via upstreams we detect this behavior on.
Network health is not currently determined, nor it is a factor in prefix advertisement status. We need to develop automations that observe automatic speed tests and packet loss metrics from edge <-> core and edge <-> Internet. These automations will be able to decide when to disable prefix advertisement, use path prepending or BGP communities to shift traffic away from edge nodes to improve network performance and reliability.
Interested in helping us, and have an interest in what we’re doing? Reach out! We’re always looking for students or professional volunteers to help us with our ambitious projects.
GreenWare
GreenWare started as a general proof-of-concept to operate Tor relays on top of power efficient hardware that is easy to scale. It’s also an initiative which helps us reduce our overall carbon footprint, and sets us on the right path to powering some of our services entirely by renewable energy in the future.
In addition to reducing our carbon footprint, we attempt to offset the footprint of our services using Stripe Climate by automatically allocating 1% of donation revenue that we receive to it. As of writing, we’ve helped to remove 184 kg of CO₂ in the air from planet Earth, which is roughly equivalent to the carbon output from driving 417 mi in a car. This simply isn’t enough, and we need to work to reduce that potential footprint as well.
Last year, in our “year in review (2024)” blog post we showcased some of our experimentation with this idea using PoE powered Raspberry Pi 5s. Over several months, we validated that this would actually work – and it worked well.
It progressed into something that we’re quite confident can be deployed on a large scale, and could be powered 100% by renewable energy in the future with the proper battery storage.
There were some quirks to be had with the Raspberry Pi 5s, though. We found the PoE HATs to be generally buggy and unreliable. The boards being exposed were easy to bump into and cause a Pi to reboot. The density also wasn’t dense enough for what we truly had in mind.
For quite a long time, we’d been tracking the development of the ComputeBlade – modular CM4/5 blades servers with the potential for very high density. They’re so dense that you can fit 20 blades in a single 1U chassis. We recently got our hands on a kit and began tinkering with them right away.
Deployment time
We ended up deploying all 20 blades in our datacenter and have migrated the majority of our Tor exit relays to them. They’re currently running great, and while having several design flaws with the chassis – we’re confident that power efficient efficient hardware like this can help reduce the carbon footprint of the Tor network and more of our services in the future.
All together, they only use a little over 100W of power.
Purple cables to represent the Tor network
Purple RGB!
PoE!
The future of GreenWare
As time goes on, we’ll be exploring new ways to experiment with power efficient hardware. We’re even thinking about ways that we can operate micro-PoPs in cheaper, less important locations where we can harvest the energy of the sun and use it to power our hardware.
We’re also exploring all-in-one carbon tracking solutions such as the “Compute Energy & Emissions Monitoring Stack” (CEEMS) to track our carbon footprint, and find ways to lower it or offset it across the board.
Have questions or want to deploy your own power efficient hardware like we did? Join any one of our community chats!
Parting thoughts
Now more than ever, it’s time to fight against Internet censorship and dragnet surveillance! Our hope is that the experiments we create inspire others to build more tech in the anti-censorship & privacy space. We can’t do it alone, nor could be do it without our generous donors. In the years to come, we’ll continue building and updating innovative experiments to help create the most impact.
If you like what we do, and want to help us fund our mission – consider making a donation.
If you’re an organization or company, and want to collaborate – contact us.
Our 2024 Non-profit Fundraiser has come to a close, and we’re so thankful for all of the donations we received during the fundraising period. A huge thank you to everyone that donated to our cause and believed in us.
We set out with the goal at the beginning of our fundraiser to form a non-profit, and apply for 501(c)(3) tax-exempt status, and we achieved both of those goals.
Unredacted Inc, a Delaware non-profit corporation is now 501(c)(3) tax-exempt after receiving our determination letter from the IRS!
All donations made to us are now US tax-deductible.
Fundraiser donation totals
$82 USD from PayPal & Credit Card donations $4,817 USD (at the time of writing) from cryptocurrency donations Total: $4899 USD
We exceeded our goal of $1000 by a long shot.
What this means for us
Forming a non-profit corporation, and becoming 501(c)(3) tax-exempt allows us to more easily raise funds, and establish ourselves as an accountable and transparent entity. As defined on Wikipedia;
501(c)(3) organizations are commonly referred to as charitable organizations. Their primary purpose is to serve the public interest by engaging in activities such as religious, educational, scientific, or charitable work. They must operate exclusively for exempt purposes, and any earnings must be used to further their mission.
With more funds, we can directly finance our projects & services. For many years, we’ve been self-funded – and it’s because we really believe in our mission. However, it would be great to receive funding from the public and/or grants to continue & expand the scope of our work. Our services require considerable amounts of money.
In the near and semi-distant future, we have no plans to pay any of our directors or volunteers, so that we can siphon 100% of the donations we receive into the operational costs for our services. Being tax-exempt allows us to use the full amount of those donations for public benefit.
Our new level of transparency
In an effort to become more transparent and accountable, we’re beginning to publish our legal/organizational documents, and a regular transparency report on our new transparency page.
Our transparency report acts as a warrant canary and confirmation that Unredacted has not been compromised in a way that is harmful to users of our services.
In the future, we plan to publish more details about our finances on a regular basis.
What’s next?
With the funding and support we’ve received, we’re excited to continue creating new projects and services, and expand our existing ones. Such projects & services include:
Censorship Evasion (CE) services such as Tor relays/bridges and FreeSocks which help people from all over the world evade censorship and protect their right to privacy.
Secure Infrastructure (SI) including XMPP.is and Unredacted Matrix which allow people to communicate securely and privately on stable and reliable platforms.
Unredacted Guides which help people setup, configure and maintain their own client-side or server-side software to evade censorship, protect their privacy and help others do the same.
If you enjoy what we do, please consider making a donation. All donations are now US tax-deductible due to our 501(c)(3) status.
