Security Revolution: setup and help

Upload and install the Security Revolution ZIP in Modules > Module Manager. Click Configure. The menu is Security Revolution, with Dashboard, Fleet, Monitoring, Protection, Backup and Settings.

Select the intended shop. Open Settings > Configuration, review the defaults below and save. Add your trusted administrative IP to Whitelisted IPs before deliberate blocking tests. Use a different, non-whitelisted browser/IP for those tests. Keep server access available before changing login protection.

Security protections have separate scopes. Form/action checks, the capacity guard, security headers, administrative authentication and an operator-applied origin policy are not controlled by one universal enable switch.

In Settings > Configuration, use the General, Spam Filter, Contact & Comments and Bot Fight tabs.

The initial domain list is:

qq.com
163.com
126.com
sina.com
sina.cn
sohu.com
21cn.com
tom.com
139.com
yeah.net

Registration checks include bans, rate limits, domain checks, scripts, name patterns and the honeypot. Contact checks include bans, the posted honeypot, limits, phrases, names and links. Comment checks include bans, limits, names, spam content and more than two links. A third-party form/comment module must invoke the relevant PrestaShop integration path.

The registration honeypot name is generated from the module name. Do not add a visible CAPTCHA or hard-code an old honeypot name into your theme as part of normal setup.

Open Block Behavior.

Under IP Management, Whitelisted IPs starts empty. Enter trusted IPs one per line, for example:

203.0.113.10
198.51.100.25

Global whitelisting bypasses module request/action checks and the in-PHP capacity admission. It does not remove security headers or rewrite an external origin policy.

Action-specific whitelist exceptions are also available for cart, registration, contact and comment. They bypass the corresponding rate limits rather than granting the same broad exemption as the global list. Manage IP actions from the session/IP tools where available; these are not four separate fields in the current Configuration form.

Bans can be global or action-scoped, including cart, login, registration, contact and comment. Check the scope before removing a ban or adding a global exception.

Use Configuration > Action Rate Limits. Enable Rate Limiting defaults on.

Raise an action limit only after checking the relevant blocked attempts and whether several real users share an address.

Under Global Limits, Enable Global Rate Limiting defaults on, Requests Per Minute to 60 and Requests Per Hour to 1200.

Trusted reverse-proxy CIDRs starts empty. Add a proxy or load-balancer range only when PHP sees that proxy as REMOTE_ADDR. Cloudflare ranges and loopback are already trusted. Forwarded client-IP headers are accepted only from trusted peers. Wrong proxy configuration can make many customers appear to have the same address.

The internal firewall_runtime_mode defaults to monitor. The module logs proposed firewall, ban, global-rate and Bot Fight interventions in monitor mode; enforce applies them and off disables that runtime layer. This key is not exposed as the old visible Configuration switch. Use support/operator configuration for a deliberate runtime-mode change. Action-specific submission checks remain active in monitor mode and can reject form submissions.

Open Configuration > Capacity.

Pages served from page cache do not consume a render slot. When a lane is full, the in-PHP guard returns HTTP 503 with Retry-After, X-MPR-Capacity: busy and a retry ticket. Normal page requests receive a small retry page. Form submissions ask the visitor to submit again; the body is not automatically replayed.

Open Monitoring > Crawlers to inspect named traffic. User-agent crawler names are report labels. The module does not let you allow or block a crawler family merely by that name.

Search and AI crawler identity is verified by address using operator-published ranges or proven reverse DNS. Verified addresses are exempt from per-address throttling and challenges. A claimed Googlebot user agent is not sufficient. Verified crawlers still contribute server load handled by capacity controls.

The module does not offer the old configurable per-crawler crawl budget or Redis weighted facet token bucket. There is no current setup for Bucket Capacity, Single Filter Cost or the old X-MPR-Facet-Limiter response. Use the actual capacity controls and supported listing integration instead.

Open Monitoring > Sessions and its settings panel. Activity and Traffic provide related request and action reports.

Use the Scoring Points settings only after inspecting actual score breakdowns.

Other internal defaults: page counters on, detailed page history off, 10 points for a visitor not yet recognized as human, analysis after 5 page views and request logs kept for 24 hours. General debug and registration debug are both off by default. Not all of these have their own field on the current form; ask support for temporary logging changes.

Open Protection > Headers. Review the current analysis before applying a preset, because presets change several values.

Edit the CSP policy and source controls for the domains your shop actually loads. The baseline includes self and common PrestaShop, Google and media sources, but your payment, analytics or embedded services may need more. Test checkout, fonts, media and widgets, then review violations before enforcing.

Permissions-Policy and cross-origin policy values are empty by default. These values are not all available as labeled controls under Headers.

Security-header handling is enabled by default. Managed CSP can also be reconciled into .htaccess. Turning Module Active off does not by itself remove that separately managed CSP. Disabling or uninstalling the module removes its managed .htaccess CSP block and can fail if cleanup cannot be completed.

Open Protection > Email and its configuration area.

Save, then inspect recorded status, type and recipient data. Order confirmations, order status, invoices, credit slips and account-creation messages are excluded from the email rate limiter. That exemption does not mean every unrelated delivery failure is prevented.

Open Protection > File Monitor. Create a baseline only after a known-clean installation or trusted update. Run a scan and review changed, missing, new or suspicious files. Recreate the baseline only after verifying legitimate changes.

The scanner monitors classes, controllers, src, override, config and modules, for PHP, Smarty, JavaScript and .htaccess files. It excludes cache, logs, uploads, images, downloads, vendor libraries and node_modules. A baseline is not a complete forensic scan of every file.

Open Protection > Vulnerabilities to run the available version and server-setting checks.

Open Backup > Settings before creating an archive.

If MPR_SECURITY_BACKUP_DIR is defined in the shop bootstrap, it overrides the editable directory. Save directory changes before relocating existing archives. The relocation workflow verifies files before removing originals.

Use Backup > Backups for a manual backup and inspect its completed result. Use Storage for local storage configuration. Backups use local storage; FTP, SFTP, S3 and WebDAV destinations are unavailable. Keep an independent off-server copy using your hosting/operations workflow.

Open Backup > Schedules and add a named schedule.

New schedules default to success notifications off and failure notifications on. Check the available notification controls in your installed schedule form. A saved active schedule still needs the runner described next.

Use Settings > Scheduled Tasks for shared jobs and Backup > Cron System for backup runner setup/status. Copy the real token from the module.

* * * * * php /var/www/html/modules/mprsecurityrevolution/cron.php --token=YOUR_TOKEN --max-tasks=20 --max-seconds=55 --context=cron

Change the paths for your host. HTTP execution is also supported:

curl 'https://yourshop.example/modules/mprsecurityrevolution/cron.php?token=YOUR_TOKEN'

CLI defaults are 20 tasks, 55 seconds and context cron. Supported contexts are cron, front and admin. The minute runner dispatches active due tasks; individual jobs retain their own schedules. These include scheduled backups, security/rate-limit/request/session cleanup, GeoIP work, visitor classification, buffered reporting and crawler-address maintenance.

Check the runner output and task state. For backups, also check that a finished archive appears in the private directory, since a backup can fail after the scheduler starts it.

Open Settings > Admin Security. Check recovery access before enabling authentication enforcement.

Enroll your own authenticator, verify a challenge and keep backup codes before requiring all employees to enroll. Review Monitoring > Admin Security Logs.

For an operator with server access, the installed recovery utility supports:

php modules/mprsecurityrevolution/bin/admin-security-escape.php --clear-lockouts
php modules/mprsecurityrevolution/bin/admin-security-escape.php --disable-enforcement

--all combines both. Use the installed utility and inspect its result; recovery changes authentication enforcement and must be followed by reconfiguration.

The additional Origin protection form saves a desired server policy. It does not deploy it. It supports one root-URL shop with one shared HTTP/HTTPS host and this module as active firewall owner. Multishop, non-root URLs and multiple active shop URLs are unsupported for this origin policy.

No policy thresholds are enabled automatically. Choose Origin protection mode and Shared pool rate mode as Observe or Enforce. Fill Total workers from 3 to 64, equal to the sum of all pool workers.

Configure all three pools: Public pool, Interactive checkout, account and payment pool, and Administration, downloads and long operations pool. Each has:

An operator must separately apply the policy and any worker/deadline deployment. A matching applied receipt records the last application, not ongoing service health. Export or import the complete desired policy with:

php modules/mprsecurityrevolution/bin/origin-protection.php export
php modules/mprsecurityrevolution/bin/origin-protection.php import < complete-policy.json

Neither command is a server deployment command. Shared pool rate limits cover all addresses and URLs in the pool without cookie or user-agent exemptions.

Test one controlled registration and contact submission first. Inspect Protection > Blocked for type, reason, IP, available email, data and timestamp. Reasons can include rate limits, blocked domains, honeypot, non-Latin names, gibberish, banned IPs, spam keywords and excess links.

Test capacity in Monitor only before tuning limits on a busy shop. Distinguish the in-PHP 503 response from per-IP rate-limit or form errors. Check forwarded-IP configuration if many visitors share one apparent IP. Check verified-address data before treating a crawler label as trusted.

For missing data, review session tracking, internal-IP exclusions, retention and cron results. For blocked real customers, inspect the exact rule and scope before adding exceptions. For header problems, inspect the response headers, CSP violations and managed .htaccess state. For backup failures, check the effective private path, both PHP/CLI permissions, available space and the task error.

Use Settings > Integrity for installation checks. Keep PrestaShop and modules updated and retain tested backups outside the shop; the module's scans and local archives do not replace those operations.

Export logs and copy backups you need before uninstalling. Review any operator-deployed origin policy separately, because saving or removing the module is not the same as changing server topology.

Disable/uninstall through Module Manager only after checking managed CSP cleanup. Uninstall removes module-owned tables and scheduled tasks, with shared session/page-view cleanup handled by the shared package. Do not assume that module logs and configuration survive. Preserve private backup archives independently before removing module files.

Requires PrestaShop 1.6.1 or later and PHP 7.1 or later.