July 2026 DDoS Retrospective

On Sunday, July 19th 2026 at noon Pacific the Tornado VPS network went offline due to a Distributed Denial of Service (DDoS) attack. Over the next 32 hours, the network would be completely offline for 24 of those hours and degraded for another 5.5 hours. All virtual machines stayed powered on, but most were not available over the network.

This is more downtime than the company has experienced in a decade or more. The basic reason for this is that a DDoS, unlike hardware failure or software bug, is malicious. In our case, we received an email an hour before the attack started which demanded payment or our network would be taken offline. That would start what was likely a profit-motivated attack using a so-called DDoS-for-hire service (also known as a booter or IP stressor service).

During the outage I was reporting on what was happening and what we were doing in the #tornadovps channel on the OFTC IRC network. While some people were able to find this channel others could not or were not aware of it. Due to the nature of the outage we were not able to post to social media and our website was offline.

This fact led to the most consistent feedback we’ve received from this event: Make our network and operational status available over the web as well as IRC.

Event Timeline

Once the DDoS started I reached out to our transit provider, Hurricane Electric (HE). The basic technical challenge with a DDoS is that so much traffic is arriving to the network it overwhelms the capacity of the port coming in to our routers. Such that any remediation on the routers is too late – the traffic needs to be blocked upstream in the transit provider network.

HE does offer an add-on product to detect and filter DDoS attacks. On Sunday their Network Operation Center (NOC) provisioned it for our network. It works by detecting a sufficient volume of packets presumed to form part of an attack (for example, a SYN flood) and filters those packets along the given route across their network.

As the day progressed, it was detecting and blocking traffic but not to a sufficient degree to bring the traffic under the capacity of our port. This continued as we tightened the configuration down to a level that would be disruptive in normal conditions were the network not under active attack.

By Monday, it was overwhelmingly clear that the dynamic filtering was insufficient to stop the attack. Given that the work week had also started I was able to engage the help of a senior network engineer at HE and together we crafted firewall rules he placed within their network.

The malicious traffic was overwhelmingly UDP (98% of packets in the samples we took during the event) but did also include malicious TCP traffic. In addition, it was almost entirely IPv4. ~85% of the packets had a payload size of 650 - 1500 bytes which seemed to be essentially random data.

Given this profile the number of firewall rules necessary to reduce traffic coming in to our port was quite modest, particularly given the traffic volume. The attack continued for hours after this filtering was in place. While this traffic continued to be disruptive the network was up sufficiently that the attacker relented after 5.5 hours. During that time the network was restored to fully operational status.

During the attack, we were pursuing every avenue that might possibly work to restore service. This including reaching out to other transit providers and conferring with network engineers who had reached out offering advice and help.

Part of this effort involved contacting CISA and the FBI to report the attack to the Internet Crime Complaint Center (IC3). They helped me confirm the basic taxonomic nature of the attack.

The total number of malicious IP addresses appears to have been in the low thousands. Few enough that it might have been feasible to enumerate and block them.

Lessons Learned

I had proactively logged in to our monitoring system in anticipation of the attack. I did not try to log in to the bird site until after the DDoS started. The login flow for X now requires e-mail authorization, and with the network offline we didn’t receive that email and could not complete the login.

Not proactively logging in to social media as I had our monitoring system was a significant mistake.

Our network is self-hosted, so when that network is down everything is down. The website isn’t available, email delivery is queued and delivery delayed. Even authoritative DNS becomes unavailable and so host records eventually time out of the cache.

This sort of critical infrastructure should have a leg sitting outside our network. It’s not clear whether that would have mattered in this particular case: the attacker might well have targeted these systems as part of the DDoS. It would at least help for more anodyne network failures, and might have been overlooked even during this attack.

Our monitoring system does extend outside of our network, however, and was working as intended in detecting our network was offline. The information it surfaces however is difficult for a casual reader to interpret due to the detail necessary for an operator to understand and debug when an alert is triggered.

Adding a public-facing, external monitoring system that answers more straightforward and basic questions about network status would help for situations where the network is offline.

Conclusion

The evidence from the attack suggests it was profit-motived and was carried out using a DDoS-for-hire service. While clearly significant as a one-time event, this is broadly speaking a low-level threat actor. Having learned how to mitigate it, any recurrence or copycat will not be able to keep the network offline.