Vai al contenuto

Guida completa Magento e Adobe Commerce

Sicurezza, malware e accessi in Magento e Adobe Commerce

In breve: Compromissioni, file modificati, utenti sospetti, permessi e prevenzione. Questa guida riunisce i casi che prima erano distribuiti in trenta URL molto simili e li organizza in un unico percorso diagnostico verificabile.

Ambito e componenti da controllare

Il sintomo visibile è soltanto il punto di partenza. Prima di modificare Magento e Adobe Commerce, separa applicazione, estensioni, tema, database, cache, web server e servizi esterni. Cambia una variabile per volta e conserva sempre l’evidenza che conferma o esclude un livello.

Sintomi ed evidenze da raccogliere

Sintomo Prima evidenza utile
Segnali di compromissione Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Accessi o account sospetti Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
File modificati senza autorizzazione Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Redirect verso siti esterni Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.
Infezione che ritorna dopo la pulizia Registra URL, utente, orario, risultato atteso e messaggio esatto; poi cerca la stessa evidenza nei log.

Diagnosi per componente

Ogni componente può produrre sintomi simili. Le schede seguenti indicano cosa significa ciascun caso e quale prova raccogliere prima della correzione.

I file applicativi

Nel contesto di Magento e Adobe Commerce, i file applicativi partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando i file applicativi mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando i file applicativi crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando i file applicativi modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando i file applicativi reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando i file applicativi torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Gli utenti Admin

Nel contesto di Magento e Adobe Commerce, gli utenti Admin partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando gli utenti Admin mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando gli utenti Admin crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando gli utenti Admin modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando gli utenti Admin reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando gli utenti Admin torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Token e integrazioni

Nel contesto di Magento e Adobe Commerce, token e integrazioni partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando token e integrazioni mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando token e integrazioni crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando token e integrazioni modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando token e integrazioni reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando token e integrazioni torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Un modulo vulnerabile

Nel contesto di Magento e Adobe Commerce, un modulo vulnerabile partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando un modulo vulnerabile mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando un modulo vulnerabile crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando un modulo vulnerabile modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando un modulo vulnerabile reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando un modulo vulnerabile torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Permessi e proprietà

Nel contesto di Magento e Adobe Commerce, permessi e proprietà partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando permessi e proprietà mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando permessi e proprietà crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando permessi e proprietà modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando permessi e proprietà reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando permessi e proprietà torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

CSP, WAF e regole server

Nel contesto di Magento e Adobe Commerce, CSP, WAF e regole server partecipa a un flusso più ampio. Assistenza Magento e Adobe Commerce su catalogo, checkout, Composer, cron, indexer, cache, OpenSearch, code e infrastruttura. Per questo è necessario osservare non soltanto la pagina finale, ma anche ciò che accade nel pannello Admin di Magento o Adobe Commerce, nei processi pianificati e nei servizi collegati.

Segnali di compromissione

Quando CSP, WAF e regole server mostra segnali di compromissione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Accessi o account sospetti

Quando CSP, WAF e regole server crea accessi o account sospetti, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

File modificati senza autorizzazione

Quando CSP, WAF e regole server modifica file senza autorizzazione, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Redirect verso siti esterni

Quando CSP, WAF e regole server reindirizza verso siti esterni, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Infezione che ritorna dopo la pulizia

Quando CSP, WAF e regole server torna compromesso dopo la pulizia, il sintomo non basta per scegliere la correzione. Su Magento e Adobe Commerce conviene prima contenere l’incidente, conservare evidenze, individuare il vettore iniziale e rimuovere persistenza e accessi compromessi prima di riaprire il sito. La prima evidenza utile è il messaggio registrato nei log nello stesso momento della richiesta, insieme alla versione del CMS, di PHP e dei componenti modificati di recente.

Percorso diagnostico in ordine

Esegui i controlli dal meno invasivo al più profondo. Un tentativo è utile solo se ha un risultato atteso, produce un’evidenza e può essere annullato.

  1. Mettere il sito in modalità controllata e limitare gli accessi

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  2. Conservare log e copie dei file sospetti prima della pulizia

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  3. Inventariare utenti, chiavi, sessioni e modifiche recenti

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  4. Confrontare core ed estensioni con pacchetti affidabili

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  5. Cercare persistenza in database, cron, code e file di configurazione

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

  6. Bonificare credenziali e dispositivi collegati

    Esegui questo controllo su un caso preciso e annota il risultato. Se l’evidenza cambia, ripeti la richiesta nelle stesse condizioni per evitare che cache, sessioni o dati differenti falsino il confronto.

Strumenti e percorsi utili in Magento

  • Esegui bin/magento --version e bin/magento deploy:mode:show per registrare versione e modalità.
  • Controlla var/log/, var/report/ e i log dei servizi collegati nello stesso timestamp della richiesta.
  • Verifica in modo mirato bin/magento cache:status, bin/magento indexer:status e lo stato dei cron.
Attenzione: comandi, percorsi e nomi dei menu cambiano tra versioni e ambienti. Verifica sempre la documentazione della versione installata e non eseguire comandi distruttivi senza backup.

Verifica finale e rollback

Il ritorno della pagina non basta a chiudere l’intervento. Ripeti il caso iniziale, un caso di controllo e i flussi collegati; poi verifica che non siano comparsi nuovi errori.

  • i file applicativi nel caso che generava il problema e in un secondo caso di controllo
  • frontend e area amministrativa con utenti e permessi differenti
  • salvataggio dei dati e assenza di nuovi errori nei log
  • email, attività pianificate, API, code o callback coinvolte
  • cache e CDN dopo la riattivazione
  • prestazioni, consumo risorse e stabilità per un intervallo adeguato
  • backup aggiornato e documentazione della modifica

Riferimenti ufficiali

I percorsi e i comandi possono cambiare tra versioni. Prima di intervenire, confronta la procedura con la documentazione della versione installata e conserva un rollback verificato.

Domande frequenti

Da quale controllo partire per sicurezza, malware e accessi in Magento?

Parti da un caso riproducibile e dal log registrato nello stesso orario. Versioni, ultima modifica, URL, utente e risultato atteso permettono di distinguere un errore applicativo da cache, infrastruttura o servizi esterni.

È sufficiente svuotare la cache?

No. La cache è un livello da verificare, ma non corregge file mancanti, dipendenze incompatibili, dati incoerenti o configurazioni errate. Usala come test e annota quale livello ha restituito la risposta.

Quando serve un ambiente di staging?

Quando la correzione può influire su utenti, ordini, contenuti, permessi o configurazioni. Lo staging deve rappresentare il caso reale senza esporre dati personali e deve avere un piano di riallineamento con la produzione.

Quali informazioni preparare prima di chiedere assistenza?

Prepara URL, messaggio, orario, versione di Magento e Adobe Commerce, versione PHP e database, modifiche recenti, accessi disponibili e un estratto pertinente dei log. Non inviare password nel primo messaggio.

Quando è preferibile un rollback?

Quando il ripristino del servizio è prioritario e la modifica può essere annullata senza perdere dati recenti. Prima confronta file e database del backup con lo stato corrente e conserva separatamente ordini, utenti o contenuti creati dopo la copia.

Serve una diagnosi sul tuo sito?

Se il problema riguarda un’installazione reale, prepara versione, URL, orario, modifiche recenti e log pertinenti.

Assistenza Magento Invia i dettagli del problema