This article is more than 1 year old

Summoners of web tsunamis have moved to layer 7, says Cloudflare

DDoS launchers increasingly target application processes instead of flooding networks

Attackers have noticed that the world is getting better at fending off massive distributed denial-of-service attacks, and are trying to overwhelm application processes instead.

So says DDoS-deflector Cloudflare, which reckons it's seen a spike in cyber-assaults trying to exhaust high-level server resources, such as per-process CPU time, disk space, and memory allocations, as opposed to overwhelming lower parts of the networking stack.

As a result, the cloud provider's security product manager Alex Cruz Farmer opined on Monday that OSI layer 7 attacks that usually appear at a rate of around 160 per day are now sprouting at rates of up to 1,000 a day.

Compared to floods of hundreds of gigabytes of junk network traffic per second, that seems trivial, but that's not so if you're the sysadmin on the receiving end: a well-constructed application-level attack that overworks a server process with a relative handful of complex requests per second can cripple its target without huge volumes of packets.

The cloud company already had a rate-limiting product on offer, to handle bot attacks and application DDoS, but Farmer wrote that after a year of experience other capabilities are needed.

Rather than simply blocking a traffic source (the Block and Simulate actions in the Rate Limiting product), users can choose to present challenges either from Cloudflare (a JavaScript challenge) or Google (reCaptcha) as UI and API mitigations.

As an example of usage, he wrote that while it's simple to set a rule like “block after five login attempts in five minutes”, that could punish legitimate users.

“Logging in four times in one minute is hard - I type fast, but couldn’t even do this”, Cruz Farmer wrote, making it easy to identify a potential bot and apply rate limiting and raise a challenge a human will pass, but a bot will not.

More complex series of rate limiting rules can be set up that escalate from raising the Cloudflare JavaScript challenge all the way up to a 24-hour block on an account.

The challenges can be tested in Cloudflare's Simulate tool at no charge prior to deployment.

The other change is extra scalability in Rate Limiting. For business and enterprise customers, the system can now count traffic by origin response headers “by matching attributes which are returned by the Origin to Cloudflare.”

This feature is designed to relieve sysadmins of the burden of maintaining ever-expanding lists of troublesome IP addresses.

The “Rate Limiting Origin Headers” feature lets the administrator trigger rate limits based on a header, as Cruz Farmer explained:

To make this happen, we need to generate a Header at the Origin, which is then added to the response to Cloudflare. As we are matching on a static header, we can set a severity level based on the content of the Header. For example, if it was a repeat offender, you could respond with High as the Header value, which could Block for a longer period.

Third, there's a defence designed to protect databases from enumeration attacks – attacks that try to step through a database record-by-record, at a speed that makes it hard for the process to keep up: “attackers will send a random set of characters to that endpoint in quick succession, causing the database to ground to a halt.”

He wrote that one customer was hit by an enumeration attack that sent more than 100 million requests in six hours.

Since the attacker in this example is sending random character strings, any “misses” are going to generate an HTTP 404 error code, so the rate limit can be applied to that; or the rate limit can be on a combination of HTTP 404 and HTTP 200 (a success code, because the random request got a hit in the database).

Similar rules, Cruz Farmer wrote, can apply to scrapers trying to download image databases (including HTTP 403, “Forbidden”), so a bot trying to scrape images (either to overload the server or for redistribution) will get blocked either by a challenge or a block.

Under Cloudflare's Pro plans, the number of rules allowed is lifted from three rules to ten; and under Business plans, you can now setup 15 rules instead of three. ®

More about


Send us news

Other stories you might like