There’s been some huge DDoS (distributed denial of service) attacks over the years, but we’ve been…lucky?…enough to witness the latest raising of the stakes in the last couple of days.
GitHub, an incredibly important code resource for major organisations around the world, fell victim to a colossal DDoS attack on Wednesday—the largest ever on record—helped along by something called Memcrashing (more on this later). 1.35 terabits per second of traffic hit GitHub all at once, causing intermittent outages. However, GitHub was prepared, and the attackers backed off quickly when they realized they had met their match.
GitHub? What’s that?
Launched in 2008, GitHub is a launchpad for all things code—from a library of files with revisions to forks (branching off to make code alterations while leaving the originals untouched) to groups being able to alter code collaboratively. It’s a crucial resource for programmers.
Anything able to interfere with the otherwise smooth operation of GitHub could quickly cause chaos. If one of your company’s key pieces of DNA is rapid updates and alterations to code, then a GitHub crash could take you out of action until everything is up and working again. Of course, you should always have local copies of files in the event of an outage, but it’s not quite the same as being able to do everything, with everyone, at all hours of the day.
Many have speculated what would happen if GitHub were to have a total out-for-the-count moment, but thankfully we’re not quite at the level of Ancient Libraries of Alexandria panic.
What’s Memcrashing?
For that, you need to know what Memcached is. Memcached is an open-source distributed caching system. Lots of sites and services make use of it to alleviate database load by caching things in RAM, and only rolling them out to places that need it, when they need it. Unfortunately, sysadmins are leaving Memcached exposed over the Internet (you’re not supposed to do this), and then people with mischief in mind are using those exposed nodes to “amplify” already powerful DDoS attacks into the digital stratosphere. The technical name for this is a “UDP-based reflection attack vector,” which is just a fancy way of saying, “We’re going to bury your server under a thousand miles of data-driven concrete.”
Despite the sheer size of the attack, Github had taken proactive steps to ensure any DDoS would have to jump through quite a few hoops to take the site offline. As it turns out, they had just ten minutes of intermittent downtime before anti-DDoS technology played the role of the calvary, and just eight minutes later, the attack started to drain away to nothing (by comparison).
Previously, on the “GitHub attacked by DDoS channel”…
You’d probably have to go back to 2015 and China’s so-called “Great Cannon” to see a similarly massive attack. The cannon was used to launch a five-day assault on, you guessed it, GitHub, and the suspicion was that the attacks were political in nature. This most recent attack is still a developing story, and it’ll be interesting to see where the blame potentially lies, though of course the main priority right now is that GitHub ensures they’re doing everything they can to ward off any follow-up attacks.
If you’re running Memcached and need to shore things up, there’s a couple of things you can try. You really owe it to your fellow netizens to patch any exposed soft spots; few have the resources available to GitHub, and even the mightiest may struggle with an attack clocking in at 51,000 times their original strength. If you’re just a regular organisation, with a regular website, and a standard off-the-shelf-hosting deal, you might have a bit more trouble. We’re back to that whole server, thousand miles, data-driven concrete thing again—and unlike GitHub, you probably won’t be able to claw your way back out until the attackers get bored and move on.
DDoS attacks have been around for a long time, and I remember when a 600MB+/second attack was the biggest thing around. Time and tech wait for no one, and the ability of scammers is now leagues beyond what was once available. The arms race between offence and defence where DDoS is concerned is never-ending, and it’s up to all of us to do our bit and help to keep the possibility of attacks down to a minimum.
Avoiding dubious files will help keep you out of a botnet attack. Hiding services from the web that don’t need to be there will prevent bad people from using them for nefarious purposes. Whether you’re in charge of a multinational corporation or you’re running your website and services from your home, there’s no excuse not to get patching and avoid a fresh wave of DDoS.
