Was X (formerly Twitter) DDOS’ed? A Developer’s Analysis
This is not a post weighing politics. It’s one to analyze DDOS attacks, platform load balancing, and more.
Over the past 11 years, we’ve sat at the forefront of defending, analyzing, and thwarting DDOS attacks from foreign actors, internal detractors, and even poor server set ups for hundreds of high traffic websites.
The Tech Specs of Handling Web Traffic
There’s one key principal to developing anything. Can the hosting server set up withstand the traffic it’s getting?
Several key factors contribute to this:
How heavy are the site pages?
On traditional apps and website platforms, typically anytime a page or feature is accessed it calls upon the underlying database to render templates, content, images and more.
If these resources are particularly heavy, traffic spikes are a very large problem that can quickly slow down or even render a site page or pages unusable for a period of time.
Are the servers properly allocated?
Bandwidth and CPU allotments don’t only equal page speed, but reliability.
Under-allocating paired with a traffic spike — or a new influx of activity on pages — can quickly cause the server to red line and lead to things like server restarts, outages, and again, slow page and asset loading.
What’s the policy on bots and malicious actors?
If you’ve ever received a slew of Viagra ads through your contact form, you’re well aware of how prevalent bots are in the webscape.
It’s up to a server’s policy for detecting, and blocking bots. It’s also up to a server’s policy on how to react when an individual or group decides to intentionally try to overload your server with repeat requests to interfere with service.
What happens when the site is attacked?
Most importantly, what happens when your platform is attacked?
Providers like Cloudflare have modes like “under attack” that prevent site access without the famous “I’m not a Robot” test.
Defining a DDOS Attack
DDOS stands for Distributed Denial of Service attack.
It’s not to be confused with a Denial of Service attack.
Here’s the difference.
Denial of Service
This typically occurs from a singular source. Often times one person flooding a site with a volume of requests.
To pull this off, they’ll usually leverage a non-suspicious IP address (as opposed to suspicious overseas addresses or anonymizing VPNs) and pick a vulnerable asset — like a slow-loading page, function, or oversized asset.
Distributed Denial of Service
This is orchestrated by a group of coordinated individuals.
It can also be done by a singular person with control of a bot net. A bot net is often established through malware on people’s computers, which are then leveraged without their knowledge to carry out the attack.
Misconceptions with DDOS Attacks
With the X issue, a lot of people were saying “Well, if it’s a ‘true DDOS attack’ why does the rest of Twitter work?”
A DDOS attack doesn’t always bring down the entire site server, although it certainly can.
With large platforms like X, often times individual services are powered by other servers. I don’t know it for sure in the case, but I’d imagine the power needed for a live stream would warrant a separate server piping into the X platform from an API or subdomain.
Someone can target a singular end-point, URL, or API to disrupt only that service, while the rest of the platform remains usable.
DDOS Attack on X? Maybe. Here’s Why.
X Has a Lot of Bots on It
Since Musk took over, many have claimed the platform has loosened its policy on user accounts, leading to an influx of bots.
Even springing for the “verified” paid status, wouldn’t necessarily prevent this. Fraudsters and hackers always have ways to step around these stop-gates.
Musk conducted a Spaces stream test prior, which fetched about 8 million alleged users.
Of the 556 million users, a lot of people speculate around 75% are bots, so if the number was beyond what was tested — say 9 million bot users — that could do the trick.
Spaces Might Not Be Properly Detecting Bots
If the API or function source for X’s Spaces service wasn’t equipped to handle or detect bots, or outside-platform DDOS attacks, it’s feasible that endpoint could go down from them.
Attackers Had Plenty of Time to Prep
The interview was announced in advance, and was quite publicized.
This would’ve given anyone actually intending to do harm plenty of time to do field research.
For developers, often, where there’s a will, there’s a way.
A Lack of Resource Allocation is More Likely. Here’s Why.
X is in Flux and Not Fully Stablized
Since taking over X, Musk is famous for laying off close to 14,000 staff members, and unplugging well-established server farms.
Historically the platform has already suffered outages due to cancelling tech services and improperly handling its user base.
Based on any rebuilding — or the network of complicated legacy systems undoubtedly powering X — I’d venture an opinion that it’s possible the platform is far from bug free or smoothed out. The facts clearly support that.
Even with a test of 8 million streamers, it’s not hard to come to the conclusion that the platform was simply not ready for the attention the Trump interview would bring.
A DDOS Attack Can Often Be Quickly Discovered and Thwarted
Savvy tech engineers, and platform diagnostics, can pretty quickly detect what an outage is caused by.
Sometimes, DDOS attacks, do simply look identical to just “a lot of users” accessing at once.
- We don’t know how many people were actually looking into the outage since the staff has been reduced to bare bones.
- We also don’t know what sort of diagnostics exist.
Being down for 40 minutes is quite a lot of time for a billion-dollar company to sit and scratch its head.
Looking at a DDOS attack quickly has you evaluating your incoming traffic. Even the most sophisticated attacks can form trends of IP addresses, regions, or specific users that are making more requests than they should be.
Once you do, it’s a matter of adding rules to block those “individuals” until the situation resolves.
Alternatively, you’d imagine a platform as big as X has methods for being under attack.
My Bottom Line: Poor Tech & Dev
I think X is fragmented, lacking resources, and built on a mess of legacy frameworks.
In this case, my guess is it wasn’t able to withstand the interest level of such a mainstream event.
What Can You Take Away for Your Business?
- Develop your platforms well. Don’t rely on rubber bands and toothpicks to power your business.
- Make sure your servers are top-notch, especially for high-value and high traffic websites
- Have a policy for bots and thwarting attacks
- Consider the world of Static to be highly resistant to attacks and high traffic volumes.
About Ben Butler
Ben Butler is the founder and lead developer of Top Hat — a fully integrated branding, website design & dev, and ad agency.
Since the doors have opened, he’s either personally developed or contributed to every single website that has come out of Top Hat.
His approach to coding is built on digital masonry, minimalism, and highly efficient code practices rather than pretending to be smarter than everyone else with two-dollar words and blue light blocking glasses.
Beyond making it look good, his experience on backend integrations, security, and overall capabilities knows few bounds. He’s assisted Acronym Organizations in locating bad actors threatening organizations, fended off malicious site attacks from Russia, Poland, and abroad, and battened down the hatches for Fortune 500 digital ecosystems.
He’s also the developer behind Top Hat’s Headless Hostman — a static site generator and hosting platform for WordPress.