Sicurezza Prestashop: hardening base

Un Prestashop esposto in produzione è costantemente sotto attacco da bot che cercano login admin, file di backup esposti, parametri vulnerabili e versioni di moduli con CVE note. L'hardening base riduce drasticamente il rischio di compromissione e protegge ordini, dati personali dei clienti e credenziali di pagamento. In questa guida vediamo gli interventi prioritari per blindare il negozio, partendo dai più semplici e arrivando alle configurazioni avanzate da implementare in produzione.

Rinomina admin e protezione del login

La cartella admin è il primo bersaglio di qualsiasi attaccante automatico. Rinominala con un suffisso casuale di almeno 6 caratteri (es. admin8a72f) e aggiorna lo shortcut nei segnalibri del team. Aggiungi un layer di autenticazione HTTP con .htpasswd sulla cartella admin tramite Plesk, in modo da avere una doppia barriera prima ancora di vedere il login Prestashop. Attiva il 2FA da Parametri avanzati > Team > Profili e rendilo obbligatorio per tutti gli account con privilegi amministrativi. Limita i tentativi di login con un modulo come iqitloginprotect o con regole Cloudflare WAF e rate limiting, in modo da bloccare gli attacchi brute force prima che raggiungano il backend.

Permessi file e disabilitazione debug

Imposta i permessi corretti: 755 sulle cartelle e 644 sui file, applicati in modo ricorsivo. Non usare mai chmod 777, nemmeno temporaneamente per risolvere errori di scrittura: i bot scansionano costantemente cartelle world-writable. Disabilita il debug in produzione: in config/defines.inc.php imposta _PS_MODE_DEV_ a false e _PS_DISPLAY_COMPATIBILITY_WARNING_ a false. Nascondi o elimina la cartella install/ subito dopo il setup. Verifica che config/parameters.php abbia permessi 640 e che non sia leggibile da web. Disabilita la generazione di file di profiling in produzione, che possono esporre query SQL e percorsi sensibili.

Procedura passo-passo

1. Rinomina la cartella admin con un suffisso casuale di almeno 6 caratteri.
2. Attiva il 2FA per tutti gli account admin e rendilo obbligatorio da policy.
3. Imposta permessi 755 sulle cartelle e 644 sui file in modo ricorsivo.
4. Disabilita la modalità debug e nascondi i messaggi di errore agli utenti finali.
5. Aggiungi una protezione .htpasswd sulla cartella admin via Plesk.
6. Configura il file .htaccess per bloccare l'accesso a .env, .git, backup, dump SQL e file di log.
7. Attiva Cloudflare WAF con regole specifiche per Prestashop e rate limiting sul login.
8. Aggiorna Prestashop core e tutti i moduli alle ultime versioni stabili.
9. Disinstalla i moduli non utilizzati: anche se inattivi, restano superficie d'attacco.
10. Configura un cron per la scansione antivirus quotidiana con ImunifyAV o ClamAV.
11. Attiva backup giornalieri off-site, con retention di almeno 30 giorni e test periodici di restore.
12. Implementa monitoraggio degli accessi admin con alert su login sospetti.

Protezione di file e cartelle sensibili

Aggiungi al file .htaccess nella root regole per bloccare l'accesso diretto a file e cartelle che non dovrebbero mai essere serviti via web: file .env, cartelle .git, file di backup con estensione .sql, .zip, .tar.gz, dump di database, log di errore. Sposta tutti i backup fuori dal document root, idealmente in una cartella su livello superiore non accessibile da web. Verifica periodicamente con strumenti come curl che questi file non siano raggiungibili dall'esterno; bastano pochi minuti per scoprire esposizioni che possono compromettere l'intero database.

Aggiornamenti e gestione delle vulnerabilità

Mantieni Prestashop, i moduli e il tema sempre aggiornati. Le patch di sicurezza vanno applicate entro 7 giorni dal rilascio; gli aggiornamenti minor entro un mese. Iscriviti alla newsletter di sicurezza Prestashop e monitora CVE Details per il tuo stack. Prima di aggiornare in produzione, replica l'ambiente in staging e testa il flusso completo di checkout: un aggiornamento che rompe il pagamento può costare più di una vulnerabilità non sfruttata. Tieni un inventario dei moduli con versione, autore e data di ultimo aggiornamento del repository: i moduli abbandonati sono il vettore di attacco più frequente.

Errori comuni e come risolverli

• 2FA non attivabile: orologio del server desincronizzato. Sincronizza con NTP (chronyd o systemd-timesyncd) e verifica il fuso orario.
• Backup nel document root: file SQL accessibili da chiunque conosca il nome. Spostali fuori da httpdocs e applica regole .htaccess.
• Moduli vetusti: aggiorna o disinstalla. Un modulo abbandonato è un vettore d'attacco anche se inattivo, perché i file restano sul filesystem.
• Password admin deboli: forza almeno 12 caratteri con politica di password e attiva il blocco dopo N tentativi falliti.
• Permessi 777: anche temporanei sono pericolosi. Risolvi gli errori di scrittura cambiando l'utente del processo, non i permessi del filesystem.
• Cartella install/ dimenticata: deve essere eliminata dopo l'installazione. Verifica anche dopo gli upgrade, perché viene a volte ricreata.
• Mancanza di logging: senza log di accesso e di azione non puoi ricostruire un incidente. Attiva logging dettagliato e archivialo off-site.

Monitoraggio e risposta agli incidenti

L'hardening è prevenzione, ma non basta: serve un piano di risposta agli incidenti. Definisci chi avvisare in caso di compromissione sospetta (titolare, DPO, hosting provider), come isolare il sito (modalità manutenzione, blocco IP, snapshot forense), come ripristinare da backup pulito. Mantieni copie offline dei backup, perché un attaccante con accesso al server può cancellare anche i backup online. Tieni log di audit per almeno 90 giorni e proteggili da modifica con write-once storage o invio a SIEM esterno. Esegui annualmente un test di restore completo: un backup mai testato è equivalente a non avere backup.

Domande frequenti

D: Quanto spesso aggiornare Prestashop?
R: Le patch di sicurezza vanno applicate entro 7 giorni dal rilascio; gli aggiornamenti minor entro un mese. I major richiedono test approfonditi in staging.

D: Un antivirus sul server è davvero utile?
R: Sì, ClamAV o ImunifyAV su Plesk rilevano webshell e malware noti. Non basta da solo, ma è un layer importante della difesa in profondità.

D: WAF Cloudflare basta da solo?
R: Aiuta molto contro bot e attacchi automatici comuni, ma non sostituisce l'hardening del server e degli applicativi. Va combinato con le altre misure.

D: Come capire se il sito è già stato compromesso?
R: Cerca file PHP sospetti nei percorsi di upload, controlla i log di accesso admin, verifica gli account amministratori e usa Maldet o ImunifyAV per una scansione completa.

D: Conviene un servizio gestito di sicurezza?
R: Per negozi con fatturato significativo sì, perché il costo è inferiore al danno di una compromissione, che include downtime, perdita dati e sanzioni GDPR.

Hai bisogno di aiuto?

Se vuoi un Prestashop performante e sicuro curato dal team di G Tech Group, scrivici tramite il modulo di contatto. Ti aiutiamo con hardening, monitoraggio continuo, aggiornamenti pianificati e risposta rapida agli incidenti.