Skip to main content

DDoS Protection

Pro Feature

DDoS protection is available with the Pro license. Get your Pro license to access this feature.

Sentinel counts the requests made by each IP address and slows down, then blocks, addresses that go far beyond normal browsing.

The protection is set on the DDoS tab of Sentinel > Configuration; the Sentinel > DDoS Protection page shows the settings in effect, the bans, the coverage and the traffic. The addresses that are never limited are those of the Trusted IPs card of the General tab: a single list, shared with the brute-force protection and with threat detection, that you can change on every plan, free included. A proxy or a CDN in front of your store is declared in the Behind a proxy or a CDN? card of the same tab.

How it works​

  1. Counting: every request is counted per IP address over a sliding window.
  2. Throttling: past the throttle threshold, requests receive an HTTP 429 Too Many Requests response with a Retry-After header. The address is not banned.
  3. Banning: past the ban threshold, the address is banned for the configured duration and appears in the ban list.
  4. Automatic release: bans expire on their own. Repeat offenders get progressively longer bans, capped at 24 hours. Bans decided by the Auto Prepend protection, before PrestaShop starts, keep the base duration, even for repeat offenders. A ban you lift, from the DDoS Protection screen or the command line, does not count: the next ban of that address lasts the base duration again.

429 is used rather than 403 because it means "temporary": search engines retry later instead of dropping your pages from their index.

Lifting a ban​

The Rate-limited IP addresses list on this page shows rate-limit bans only. Unban lifts the rate-limit ban of the address and resets its request counters, so the address is no longer banned from its next request. It can still be slowed down while its network is under attack, since the per-network limit is shared with its neighbours. It leaves any brute-force ban or manual blacklist entry of the same address in place: those are lifted from the Brute-force Protection page.

Settings​

The settings are set on the DDoS tab of Sentinel > Configuration. Its Settings card holds the two controls that cover the common case:

  • Protection — Off, Monitor or On.
  • Sensitivity — Relaxed, Balanced (default), Strict or Custom. This is the only knob most shops need: it sets the request thresholds and the ban duration for you. Relaxed tolerates more traffic before acting; Strict reacts sooner.

Everything else lives in the Advanced card and never needs to be touched for a normal setup: the exact per-window thresholds, ban duration, safety threshold, verified-crawler and repeat-offender switches, the per-network / per-path / spike options and the Redis DSN field described below.

Choosing a sensitivity fills in the time window, the two thresholds and the ban duration, so you see what it does; typing one of them by hand switches Sensitivity to Custom. In Custom, a Throttle threshold (requests per window) above the Ban threshold (requests per window) is refused before the form is sent, with The throttle threshold cannot exceed the ban threshold.

The Excluded URLs card takes one path per line. Click Save settings, below the three cards, to save the whole tab.

When the plan of the shop does not include the DDoS protection, the tab shows the Pro invitation described under DDoS instead of the settings; during an outage of the Sentinel service, see When the Sentinel service does not answer.

Only an employee who can configure the Sentinel module changes these settings; the others see the tab read-only. See Who can change the settings.

Settings in effect​

The Sentinel > DDoS Protection page shows the settings without changing them: its Settings in effect card gives the saved values of Protection, Sensitivity, Time window (seconds), Throttle threshold (requests per window), Ban threshold (requests per window) and Ban duration (seconds). Its Adjust settings button opens the DDoS tab; it is only shown to an employee who can configure the Sentinel module.

Monitor mode​

In Monitor mode Sentinel counts and reports without blocking anything. The statistics show what would have been blocked. Use it for a few days if you want to confirm the thresholds against your own traffic before switching Protection to On.

What is never limited​

  • Trusted IPs: the addresses of the Trusted IPs card, shared with brute-force protection and threat detection, and the PrestaShop maintenance IPs when that card trusts them.
  • Logged-in employees: back-office work generates bursts that front-office thresholds are not sized for.
  • Verified search engine crawlers: Googlebot, Bingbot and others are confirmed by forward-confirmed reverse DNS, so a spoofed user-agent does not get the exemption.
  • Excluded URLs, pre-filled with the usual payment callback paths. Keep your payment notification URLs here: a rejected notification never becomes an order. They are not exempted from threat detection: see URLs never blocked.
  • Static assets served directly by PHP, and command-line execution. A URL that merely looks static is not exempt: PrestaShop rewrites any path that does not match an existing file to index.php, so a request for a non-existent .css boots the shop in full and is counted like any other.

The safety threshold​

If more than the configured share of your traffic gets blocked over an hour, Sentinel suspends enforcement by itself, shows a warning in the back-office, and keeps counting.

This exists for one scenario in particular: a reverse proxy that has not been declared in the Behind a proxy or a CDN? card. Every visitor is then seen under the same address, that single address exceeds every threshold, and the whole storefront would ban itself. Rather than let that happen, Sentinel stops enforcing and tells you.

While enforcement is suspended, the Sentinel > DDoS Protection page shows a banner with the share of traffic that was being blocked and the safety threshold, and two buttons: Adjust settings, which opens the DDoS tab and is only shown to an employee who can configure the Sentinel module, and Resume enforcement.

Once the configuration is fixed, click Resume enforcement (or run sentinel:rate-limit resume). Enforcement also resumes on its own after one hour.

Behind a reverse proxy or a CDN

Declare your infrastructure in the Behind a proxy or a CDN? card of the General tab of Sentinel > Configuration: Sentinel detects Cloudflare or a reverse proxy in front of your store and offers to trust it in one click. Without that, Sentinel deliberately ignores forwarded headers and sees your proxy's address instead of your visitors'.

Statistics​

The Traffic analysed (last 24 hours) card shows Requests analysed, Throttled, Banned IPs (24h) and Share of traffic blocked. Figures are aggregated hourly rather than logged per request, so the protection does not become a load problem of its own.

The Sentinel dashboard also surfaces the protection: a KPI with the requests blocked over the last 24 hours, and a dedicated card showing active bans, IPs banned over the last 24 hours, blocked requests, and the most recent bans. When the plan of the shop does not include the DDoS protection, an upgrade prompt is displayed instead; during an outage of the Sentinel service, see When the Sentinel service does not answer.

Coverage​

A banner shows which coverage is active:

  • Extended — Auto Prepend Protection is enabled, so requests are filtered before PrestaShop starts.
  • Limited — only requests routed by PrestaShop are filtered. The protection works, but each blocked request still costs a full PrestaShop startup.

Extended coverage is worth enabling wherever your hosting allows it, for two reasons:

  • Cost. Reaching a decision before PrestaShop starts takes around 0.2 ms, against roughly 130 ms to boot PrestaShop and open its database connections. Under a flood, that is the difference between shedding traffic and being flattened by it.
  • Reach. PHP files that are not part of PrestaShop — a script dropped in an upload directory, a forgotten installer — never reach the router, so no PrestaShop hook can see them. Only this stage does.

Settings are read from a small file Sentinel exports whenever you save them, so this stage needs neither the database nor PrestaShop itself. If that file is missing or unreadable, requests simply pass: the protection can stop working, but it cannot take the shop down.

Advanced settings​

These options sit in the Advanced card of the DDoS tab and are all off, or empty, by default.

Per-network limit​

Counts requests per network — a /24 for IPv4, a /64 for IPv6 — in addition to per address. It catches an attacker spread across a range, where every individual address stays under its own ceiling.

A network is only ever throttled, never banned: a /24 may be a whole ISP pool or an office, and banning it would take out every legitimate visitor behind it.

Per-path limits​

One rule per line, a path then its own limit:

/connexion 20
/recherche 40
/module/*/pay 5

Matching is by prefix, or with * wildcards, and the first matching rule wins. Each path gets its own budget, so browsing the catalogue never consumes the login allowance — and a strict login limit does not penalise normal browsing.

This is what a single global threshold cannot express: set it low enough to protect the login form and ordinary browsing breaks.

Unbanning an address, from the DDoS Protection screen or the command line, also clears its count on every path rule: its next visit to the page it was banned on starts from zero instead of being banned again. The count of its network is kept, since the neighbours share it.

Automatic tightening during a spike​

When total traffic over one window exceeds the spike threshold, every limit is divided by four for ten minutes, then re-evaluated.

This addresses what per-address limits structurally cannot: a flood spread thinly over thousands of addresses, each staying under its own ceiling. Nothing individually looks abnormal, yet the shop is being saturated.

The back-office and sentinel:rate-limit status both show when the regime is engaged, and Resume enforcement releases it early.

Redis​

Counters live in files, local to each server. If several servers run the same shop, an attacker gets a full budget on each of them.

The Redis DSN field is saved, but it has no effect at this time: even when it is filled in, counters stay in local files, and the servers of a shop do not share them.

The Auto Prepend protection counts and bans in the same local files, before PrestaShop starts. Unbanning an address, from the DDoS Protection screen or the command line, also lifts that ban, but only on the server where you unban it: on a shop run by several servers, the others keep refusing the address until its ban runs out.

Command line​

# Current mode, thresholds, backend and traffic figures
php bin/console sentinel:rate-limit status
php bin/console sentinel:rate-limit status --json

# What the limiter currently thinks of an address (counts nothing)
php bin/console sentinel:rate-limit test 203.0.113.10

# Clear an address: counters plus any rate-limit ban, like Unban on the
# DDoS Protection page (brute-force bans and the blacklist are kept)
php bin/console sentinel:rate-limit reset 203.0.113.10

# Resume enforcement after the safety threshold suspended it
php bin/console sentinel:rate-limit resume

# Write the current counters to the statistics table, and the bans decided
# by the Auto Prepend protection to the ban list
php bin/console sentinel:rate-limit flush

# Remove old statistics and expired counters
php bin/console sentinel:rate-limit purge

reset is the recovery path if a legitimate visitor is caught.

With Auto Prepend Protection enabled, a flooding address is banned before PrestaShop starts. The ban reaches the ban list at the next back-office page (after a flood from more than 200 addresses, the rest follows over the next pages), or all at once when flush runs: scheduling flush keeps the list, the dashboard and sentinel:brute-force list up to date without anyone opening the back office.

Requirements​

None. The protection runs on stock PHP: no extension to install, no package to add, no server configuration to change.

Counters are stored in files, which works on every host. Redis is never required: the Redis DSN field has no effect at this time (see Redis).

Notes and limits​

  • Shared addresses: counting is per IP, so visitors behind a corporate NAT, mobile CGNAT or a school network share one counter. This is why the default thresholds are generous.
  • Counter storage: counters are kept in files, local to each server. They may reset when the server restarts; bans are stored in the database and are not affected.
  • Scope: this protects against application-level floods, aggressive scraping and bot traffic. A volumetric network-level attack saturates the server before any PHP code runs, and no PHP module can address that.