Anti-DDoS protection for e-commerce and SaaS
In an online store and in SaaS, downtime converts directly into money, and the timing of an attack is rarely accidental. Black Friday, a collection launch, the last day of a billing cycle: that is when an hour of unavailability costs many times what it would on an ordinary Tuesday. A filter that is already running removes the window between detecting an attack and responding to it.
A shopper who lands on a broken page does not wait. They go to a competitor and usually never come back, while the cost of acquiring them was already paid earlier, in a campaign now driving traffic to a dead address. In SaaS the arithmetic is similar: an interruption in a tool the customer works in comes up later in the renewal conversation.
What goes wrong
- The attack hits the selling window, because that is when extortion has the most leverage
- The ad campaign keeps driving traffic to an address that does not answer
- Protection engaged after detection loses the most valuable first minutes
- A blackhole on the store's address is, from the customer's point of view, the same as a successful attack
- A foreign scrubbing centre means a third party gets to look at your customers' traffic
What we do about it
- In always-on mode the filter sits in the traffic path, so mitigation has no spin-up stage
- The store's address stays reachable, because we do not use blackholing
- Scrubbing happens in our infrastructure in Poland, without handing traffic to outsiders
- L7 filtering drops queries that imitate a user but make no sense for your application
- The profile is set around your normal peak, so a campaign does not look like an attack
How it works for you
A sales peak is not an attack
The worst thing DDoS protection can do in e-commerce is treat a successful campaign as an attack and cut customers off at the best possible moment. We build the filtering profile from your real traffic, with headroom for planned peaks, and before a big push we can review it together.
Layers 3 and 4 removed before the application
The vast majority of the volume in an attack consists of packets belonging to no established session. We drop them at the network edge, so your application servers and database never have to deal with them and can keep serving real customers.
Where our part ends
To be straight about it: attacks carried over properly established HTTPS sessions, aimed at expensive database queries, also need work on the application side. Caching, limits and a WAF stay with you. We will say plainly where what we can filter in the network ends.
The full picture
The mechanics are the same for every segment: SkyGuard, our own stateful engine, filters every packet at the AS202520 edge, always-on or on-demand, with no RTBH and no blackholing. The main Anti-DDoS page covers the engine, the modes, reflected traffic, carpet bombing and how we compare against blackholing and outsourced scrubbing.
Frequently asked questions
Will the protection handle bots scanning the store?
Those are two different problems. Bots scraping prices or trying logins carry proper sessions, so stateful filtering will not stop them. L7 filtering helps in part, but ultimately these are solved on the application side: with limits, verification and WAF rules. Our protection takes the volume off you, it does not replace application security.
I received a ransom demand threatening an attack. What now?
Do not pay, and prepare technically, because paying usually means they come back for another instalment. Write to us ahead of time: turning protection up before the announced deadline is far calmer than connecting in the middle of an ongoing attack. It is also worth reporting the matter to law enforcement.