DDoS Spooktacular: Tales from the (s)crypt

You bolt awake in dead of night. Something is crying out in the darkness. You cast about for the source. What is that infernal racket!? The screaming of a banshee? You hear it again: a blood-curdling sound. It’s right beside you! Is it the cackling of a witch? The sneering laugh of a goblin? Worse. An alert is firing on your phone.

Bleary-eyed, you silence the alert and pop open your laptop. Something on the internet is attacking your infrastructure. Thousands of machines, as if possessed, are hammering on your edge systems, saturating your ethernet connections with terabits of data.

What, in the name of all that is haunted, is going on? What are the critters of the web up to this evening?

The internet is full of all kinds of sinister creatures and cunning tricksters and pranksters. And, given the right tools and incantations, they can give you quite a fright. Squarespace maintains tooling and software to ward off attacks and offers them to our customers as a core part of our product. In the spirit of Halloween, let’s talk about some of the more sinister and mischievous servers that go ACK in the night.

SYN Floods

SYN floods are a protocol-level attack. They directly exploit the trusting nature of TCP. When a listening TCP port receives a SYN packet, the TCP stack will do some bookkeeping and immediately allocate state for the new connection. This server will then respond with a SYN-ACK and eagerly await the start of a new connection. But what if the client doesn’t really want to talk to you? Or what if they’re not who they say they are? An apparition out in the recesses of cyberspace.

In the general case, the client has something it wants to talk to your server about. It’s stoked to receive the SYN-ACK packet so that it can establish a connection and make a request. When the client is being malicious, however, it doesn’t want to talk to your server at all. It wants to waste your resources. In a SYN flood attack, malicious clients send SYN packets repeatedly to a listening server and respond to none of the server’s SYN-ACKS, tying up kernel resources and potentially leaving the server unable to respond to the clients who actually do want to connect.

It’s as if, on Halloween, you are waiting by the door for the arrival of trick-or-treaters and hear a rapping on your front door. You expectantly throw it wide open, but are greeted by darkness there and nothing more. Another knock, from your side door now, and once again no one is there. The knock has started again at the front door, but there’s a knock at the back door as well, and someone is knocking on the window, too. Feverishly, you rush to respond to each knock, only to find darkness. The knocks are coming and going so frequently now that you’re worried you’ve missed the real trick-or-treaters.

This is the basic mechanism of a SYN flood attack: add so many bogus connections to the stream of connections as to exhaust the server. Squarespace combats attacks like these in many ways. We enable SYN cookies for our edge stack: a kernel feature that allows the server to respond without allocating any state. Squarespace’s automatic mitigation systems also analyze incoming packets and dynamically block connections based on this data. Careful tuning of our mitigation systems is critically important: failing to block malicious connections will overload our edge and prevent us from responding to real user requests.

The Pizza Delivery Prank of the Internet

Another common attack is a volumetric attack. A cunning and clever attacker may launch more than a terabit per second of data at your servers. Attackers cannot usually generate this much data using just the servers they control. Attackers instead rely on ‘reflection,’ which is a process for amplifying the amount of network traffic an attacker can send to their target. Reflection, like SYN flooding, relies on how trusting the protocols of the internet are. DNS reflection is an extremely common flavor of reflective attack, so we’ll use it to walk through the mechanics of how these types of attacks work.

DNS, or the Domain Name System, is a critical piece of internet infrastructure. DNS stores information like which server hosts “squarespace.com” and where to send email for “@yahoo.com” email addresses. It’s a relatively old system, by internet standards, and accepts requests over UDP. UDP does not require a connection to be established and is at the heart of what makes DNS reflection attacks possible—and why this attack is like the pizza delivery prank of the internet.

It’s late on Halloween, and a few local pranksters want to have one last bit of fun. They decide to pull a classic pizza delivery prank, which has roughly the following flow:

1. A prankster calls up a local pizza shop and claims to be at an address different from their own: the address of their target.
2. The prankster proceeds to place a huge order; say, 50 large pizzas with extra cheese.
3. The pizza shop cooks up the tasty pies and dutifully delivers them to the fake address the prankster listed.
4. The target, receiving the pizzas, has to spend energy, time, and maybe even money, to deal with the huge delivery that just arrived at their door.

DNS reflection works in much the same way:

1. An attacker begins by crafting malicious requests to a DNS server, setting the source address of the UDP packets to be different from their own: the address of their target.
2. The attacker finishes crafting their DNS requests, specifying that they want a record with a massive amount of data.
3. The DNS server retrieves the requested records and dutifully delivers them to the spoofed address that the attacker listed.
4. The target, receiving the large DNS record, has to spend computing resources to deal with the huge amount of data that just arrived at their servers.

A pizza delivery prank, like a DNS reflection attack, relies on exploiting the trust of a third party to waste a target’s resources. Squarespace mitigates a lot of these attacks by limiting incoming connections at different layers and by relying on outside providers to drop clearly malicious traffic on the way to our servers.

Conclusion

We touched on some of the more common ways that attackers try to give us a spook. Squarespace relies on automated tooling and tuning of our edge nodes to ensure we serve real user traffic while preventing malicious clients from tying up our resources. Preventing these types of attacks is a core part of Squarespace’s products. It requires diligence at different layers of the request-serving stack and our architecture design processes exist to account for this. We leverage common practices and monitor our traffic patterns to make sure the ghosts that haunt the web stay away.