Security Revolution: configurazione e aiuto

Carica e installa lo ZIP di Security Revolution in Moduli > "Module Manager". Fai clic su "Configure". Il menu è Security Revolution, con Pannello di controllo, Gruppo di negozi, Monitoraggio, Protezione, Backup e Impostazioni.

Seleziona il negozio desiderato. Apri Impostazioni > Configurazione, controlla i valori predefiniti sotto e salva. Aggiungi il tuo IP amministrativo fidato a IP in whitelist prima dei test di blocco intenzionali. Per quei test usa un browser/IP diverso, non in whitelist. Mantieni disponibile l'accesso al server prima di modificare la protezione dell'accesso.

Le protezioni di sicurezza hanno ambiti separati. I controlli di moduli/azioni, il controllo di capacità, gli header di sicurezza, l'autenticazione amministrativa e una policy di origine applicata dall'operatore non sono gestiti da un unico interruttore universale.

In Impostazioni > Configurazione, usa le schede Generale, Filtro antispam, Contatti e commenti e Difesa anti-bot.

L'elenco iniziale dei domini è:

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

I controlli di registrazione includono ban, limiti di frequenza, domini, sistemi di scrittura, schemi dei nomi e honeypot. I controlli di contatto includono ban, honeypot inviato, limiti, frasi, nomi e link. I controlli dei commenti includono ban, limiti, nomi, contenuti spam e più di due link. Un modulo di terze parti per form o commenti deve invocare il percorso di integrazione PrestaShop pertinente.

Il nome dell'honeypot di registrazione viene generato dal nome del modulo. Non aggiungere un CAPTCHA visibile e non codificare un vecchio nome di honeypot nel tema durante la normale configurazione.

Apri Comportamento del blocco.

In Gestione IP, IP in whitelist è inizialmente vuoto. Inserisci un IP fidato per riga, per esempio:

203.0.113.10
198.51.100.25

La whitelist globale evita i controlli delle richieste/azioni del modulo e l'ammissione di capacità in PHP. Non rimuove gli header di sicurezza e non riscrive una policy di origine esterna.

Sono disponibili anche eccezioni whitelist specifiche per carrello, registrazione, contatto e commento. Evitano i corrispondenti limiti di frequenza senza concedere l'ampia esenzione dell'elenco globale. Gestisci le azioni IP dagli strumenti di sessione/IP dove disponibili; non sono quattro campi separati nell'attuale modulo Configurazione.

I ban possono essere globali o limitati a un'azione, tra cui carrello, accesso, registrazione, contatto e commento. Controlla l'ambito prima di rimuovere un ban o aggiungere un'eccezione globale.

Usa Configurazione > Limiti di frequenza per azione. Attiva limitazione della frequenza è attivo per impostazione predefinita.

Aumenta un limite di azione solo dopo aver controllato i tentativi bloccati pertinenti e se più utenti reali condividono un indirizzo.

In Limiti globali, "Enable Global Rate Limiting" è attivo per impostazione predefinita, "Requests Per Minute" è 60 e "Requests Per Hour" è 1200.

"Trusted reverse-proxy CIDRs" è inizialmente vuoto. Aggiungi un intervallo di proxy o bilanciatore di carico solo quando PHP vede quel proxy come REMOTE_ADDR. Gli intervalli Cloudflare e il loopback sono già fidati. Gli header IP client inoltrati sono accettati solo da peer fidati. Una configurazione proxy errata può far apparire molti clienti con lo stesso indirizzo.

Il valore interno firewall_runtime_mode è monitor per impostazione predefinita. In modalità monitor, il modulo registra gli interventi proposti di firewall, ban, limiti globali e Bot Fight; enforce li applica e off disattiva quel livello di esecuzione. Questa chiave non è esposta come il vecchio interruttore visibile di Configurazione. Usa la configurazione di supporto/operatore per modificare deliberatamente la modalità di esecuzione. I controlli di invio specifici per azione restano attivi in modalità monitor e possono rifiutare gli invii dei moduli.

Apri Configurazione > Capacità.

Le pagine servite dalla cache delle pagine non consumano uno slot di rendering. Quando una corsia è piena, il controllo in PHP restituisce HTTP 503 con Retry-After, X-MPR-Capacity: busy e un ticket per riprovare. Le normali richieste di pagina ricevono una piccola pagina per riprovare. Gli invii di moduli chiedono al visitatore di inviare nuovamente; il corpo non viene riprodotto automaticamente.

Apri Monitoraggio > Crawler per controllare il traffico denominato. I nomi dei crawler nello user-agent sono etichette di report. Il modulo non permette di consentire o bloccare una famiglia di crawler solo in base a quel nome.

L'identità dei crawler di ricerca e AI viene verificata per indirizzo usando intervalli pubblicati dall'operatore o DNS inverso comprovato. Gli indirizzi verificati sono esenti da limitazioni per indirizzo e challenge. Uno user-agent che dichiara Googlebot non basta. I crawler verificati contribuiscono comunque al carico del server gestito dai controlli di capacità.

Il modulo non offre il vecchio budget di scansione configurabile per crawler né il token bucket Redis ponderato per le faccette. Non esiste una configurazione attuale per "Bucket Capacity", "Single Filter Cost" o la vecchia risposta X-MPR-Facet-Limiter. Usa i controlli di capacità effettivi e l'integrazione supportata degli elenchi.

Apri Monitoraggio > Sessioni e il relativo pannello delle impostazioni. Attività e Traffico forniscono report correlati di richieste e azioni.

Usa le impostazioni "Scoring Points" solo dopo aver controllato la composizione effettiva dei punteggi.

Altri valori interni predefiniti: contatori di pagina attivi, cronologia dettagliata delle pagine disattivata, 10 punti per un visitatore non ancora riconosciuto come umano, analisi dopo 5 visualizzazioni di pagina e conservazione del registro richieste per 24 ore. Il debug generale e quello di registrazione sono disattivati per impostazione predefinita. Non tutti questi valori hanno un campo proprio nel modulo attuale; per modifiche temporanee alla registrazione dei log contatta il supporto.

Apri Protezione > Intestazioni. Controlla l'analisi attuale prima di applicare un preset, perché i preset cambiano più valori.

Modifica i controlli di policy e sorgenti CSP per i domini effettivamente caricati dal negozio. La base include self e sorgenti comuni PrestaShop, Google e media, ma i tuoi servizi di pagamento, analisi o incorporati possono richiederne altre. Prova checkout, font, media e widget, poi controlla le violazioni prima di applicare la policy.

I valori Permissions-Policy e delle policy cross-origin sono vuoti per impostazione predefinita. Non sono tutti disponibili come controlli etichettati in Intestazioni.

La gestione degli header di sicurezza è attiva per impostazione predefinita. La CSP gestita può anche essere riconciliata in .htaccess. Disattivare Modulo attivo da solo non rimuove quella CSP gestita separatamente. Disattivare o disinstallare il modulo rimuove il suo blocco CSP gestito in .htaccess e può non riuscire se la pulizia non può essere completata.

Apri Protezione > E-mail e la sua area di configurazione.

Salva, poi controlla stato, tipo e dati dei destinatari registrati. Conferme d'ordine, stati ordine, fatture, note di credito e messaggi di creazione account sono esclusi dal limitatore di frequenza e-mail. Questa esenzione non significa che venga impedito ogni errore di consegna non correlato.

Apri Protezione > Monitoraggio file. Crea una base di riferimento solo dopo un'installazione nota come pulita o un aggiornamento fidato. Esegui una scansione e controlla i file modificati, mancanti, nuovi o sospetti. Ricrea la base solo dopo aver verificato la legittimità delle modifiche.

Lo scanner controlla classes, controllers, src, override, config e modules per file PHP, Smarty, JavaScript e .htaccess. Esclude cache, log, caricamenti, immagini, download, librerie di fornitori e node_modules. Una base di riferimento non è una scansione forense completa di ogni file.

Apri Protezione > Vulnerabilità per eseguire i controlli disponibili di versione e impostazioni del server.

Apri Backup > Impostazioni prima di creare un archivio.

Se MPR_SECURITY_BACKUP_DIR è definito nel bootstrap del negozio, sostituisce la directory modificabile. Salva le modifiche alla directory prima di spostare gli archivi esistenti. Il flusso di spostamento verifica i file prima di rimuovere gli originali.

Usa Backup > Backup per un backup manuale e controlla il risultato completato. Usa Archiviazione per configurare l'archiviazione locale. I backup usano l'archiviazione locale; le destinazioni FTP, SFTP, S3 e WebDAV non sono disponibili. Mantieni una copia indipendente fuori dal server usando il tuo flusso di hosting/gestione operativa.

Apri Backup > Pianificazioni e aggiungi una pianificazione con nome.

Nelle nuove pianificazioni, le notifiche di successo sono disattivate per impostazione predefinita e quelle di errore sono attivate. Controlla i controlli di notifica disponibili nel modulo di pianificazione installato. Una pianificazione attiva salvata richiede comunque il runner descritto di seguito.

Usa Impostazioni > Attività pianificate per le attività condivise e Backup > Sistema cron per configurazione/stato del runner dei backup. Copia il token reale dal modulo.

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

Modifica i percorsi per il tuo host. È supportata anche l'esecuzione HTTP:

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

I valori CLI predefiniti sono 20 attività, 55 secondi e contesto cron. I contesti supportati sono cron, front e admin. Il runner al minuto avvia le attività attive in scadenza; ogni attività mantiene la propria pianificazione. Includono backup pianificati, pulizia di sicurezza/limiti di frequenza/richieste/sessioni, attività GeoIP, classificazione dei visitatori, report con buffer e manutenzione degli indirizzi crawler.

Controlla l'output del runner e lo stato delle attività. Per i backup, controlla anche che nella directory privata ci sia un archivio completato, perché un backup può fallire dopo essere stato avviato dallo scheduler.

Apri Impostazioni > Sicurezza dell'amministrazione. Controlla l'accesso di recupero prima di attivare l'applicazione obbligatoria dell'autenticazione.

Registra il tuo autenticatore, verifica una challenge e conserva i codici di backup prima di richiedere la registrazione a tutti i dipendenti. Controlla Monitoraggio > Registri di sicurezza dell'amministrazione.

Per un operatore con accesso al server, l'utilità di recupero installata supporta:

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

--all combina entrambe le operazioni. Usa l'utilità installata e controlla il risultato; il recupero cambia l'applicazione obbligatoria dell'autenticazione e deve essere seguito da una riconfigurazione.

Il form aggiuntivo Protezione dell’origine salva una policy server desiderata. Non la distribuisce. Supporta un solo negozio all'URL radice con un host HTTP/HTTPS condiviso e questo modulo come responsabile attivo del firewall. Multinegozio, URL non radice e più URL attivi del negozio non sono supportati per questa policy di origine.

Nessuna soglia della policy è attivata automaticamente. Scegli Osserva o Imponi per Modalità di protezione dell’origine e Modalità della frequenza condivisa del pool. Compila Worker totali con un valore da 3 a 64, uguale alla somma di tutti i worker dei pool.

Configura tutti e tre i pool: Pool pubblico, Pool interattivo per checkout, account e pagamento e Pool per amministrazione, download e operazioni lunghe. Ognuno ha:

Un operatore deve applicare separatamente la policy e ogni distribuzione di worker/scadenze. Una ricevuta di applicazione corrispondente registra l'ultima applicazione, non la salute continua del servizio. Esporta o importa la policy desiderata completa con:

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

Nessuno dei due comandi è un comando di distribuzione del server. I limiti di frequenza condivisi del pool coprono tutti gli indirizzi e URL nel pool senza esenzioni per cookie o user-agent.

Prova prima una registrazione e un invio di contatto controllati. Controlla Protezione > Bloccato per tipo, motivo, IP, e-mail disponibile, dati e timestamp. I motivi possono includere limiti di frequenza, domini bloccati, honeypot, nomi non latini, nomi senza senso, IP bannati, parole chiave spam e link in eccesso.

Prova la capacità in Solo monitoraggio prima di regolare i limiti su un negozio trafficato. Distingui la risposta 503 in PHP dagli errori di limite per IP o di modulo. Controlla la configurazione degli IP inoltrati se molti visitatori condividono uno stesso IP apparente. Controlla i dati degli indirizzi verificati prima di considerare fidata un'etichetta crawler.

Per dati mancanti, controlla tracciamento delle sessioni, esclusioni IP interni, conservazione e risultati cron. Per clienti reali bloccati, controlla regola e ambito esatti prima di aggiungere eccezioni. Per problemi di header, controlla header di risposta, violazioni CSP e stato gestito di .htaccess. Per errori di backup, controlla percorso privato effettivo, permessi PHP/CLI, spazio disponibile ed errore dell'attività.

Usa Impostazioni > Integrità per i controlli di installazione. Mantieni PrestaShop e moduli aggiornati e conserva backup testati fuori dal negozio; scansioni e archivi locali del modulo non sostituiscono queste operazioni.

Esporta i log e copia i backup necessari prima della disinstallazione. Controlla separatamente ogni policy di origine distribuita dall'operatore, perché salvare o rimuovere il modulo non equivale a cambiare la topologia del server.

Disattiva/disinstalla tramite "Module Manager" solo dopo aver controllato la pulizia della CSP gestita. La disinstallazione rimuove le tabelle del modulo e le attività pianificate, con la pulizia condivisa di sessioni/visualizzazioni di pagina gestita dal pacchetto condiviso. Non presumere che log e configurazione del modulo rimangano. Conserva gli archivi di backup privati in modo indipendente prima di rimuovere i file del modulo.

Richiede PrestaShop 1.6.1 o successivo e PHP 7.1 o successivo.