Scanner di malware Imunify360: funzionalità, aggiornamenti e limiti

Imunify360 come soluzione di sicurezza multistrato per l'hosting

Imunify360 non è un semplice programma antivirus, bensì una soluzione di sicurezza per Linux dotata di diversi livelli di protezione. Il Scanner antimalware analizza i file alla ricerca di contenuti noti o sospetti. Il firewall e gli IDS/IPS monitorano e limitano le attività di rete anomale, mentre un Web Application Firewall (WAF) valuta le richieste HTTP prima che raggiungano l’applicazione sulla base di regole prestabilite. I controlli di reputazione forniscono ulteriori indicazioni per la classificazione delle fonti e delle attività.

Questa suddivisione è fondamentale per i gestori di hosting, poiché i livelli intervengono in punti diversi. Un attacco HTTP mirato a una vulnerabilità nota può essere bloccato dal WAF prima che WordPress, Joomla o Magento elaborino la richiesta. Un upload dannoso, invece, diventa rilevante in fase di verifica dei file. Se viene eseguita una webshell PHP, è possibile Difesa proattiva affrontare comportamenti sospetti durante l'esecuzione di PHP; tuttavia, non si tratta di un'analisi retrospettiva dell'intero incidente.

Il modello si chiama Difesa a più livelli: Una singola vulnerabilità o un elemento trascurato non dovrebbero determinare da soli la sicurezza dell’account di un cliente. Il rilevamento del malware può rendere visibile il codice dannoso presente, ma non impedisce necessariamente l’exploit iniziale. Allo stesso modo, un WAF può bloccare un attacco senza ripulire i file già salvati o i contenuti del database manomessi.

Nessuno di questi livelli sostituisce le attività operative fondamentali. Il nucleo del CMS, i plugin, i temi e le estensioni richiedono aggiornamenti di sicurezza tempestivi; i diritti di accesso restrittivi ai file e le credenziali di accesso separate limitano le conseguenze della compromissione di un account. I backup verificati consentono il ripristino e, in caso di rilevamento di un incidente, solo un’analisi dell’incidente chiarisce la via di accesso, la portata e la possibile persistenza. Imunify360 Fornisce segnali di protezione e rilevamento, ma non la prova definitiva di un ambiente bonificato.

Differenze tra Imunify360, ImunifyAV e ImunifyAV+

Gli elenchi delle funzioni devono essere associati al prodotto di riferimento. Imunify360 è la soluzione di sicurezza per server più completa; ImunifyAV e ImunifyAV+ sono prodotti distinti con funzionalità relative al malware. Chi equipara questi nomi potrebbe, ad esempio, confondere una funzione di scansione già presente con la protezione firewall, in tempo reale o PHP, e trarne aspettative errate riguardo a un server gestito o di rivendita.

È particolarmente rilevante il fatto che, secondo la documentazione del produttore, la scansione in tempo reale e la difesa proattiva non siano disponibili in ImunifyAV e ImunifyAV+ allo stesso modo in cui lo sono in Imunify360. La scansione in tempo reale è in grado di rilevare tempestivamente i file nuovi o modificati; la difesa proattiva considera l’esecuzione PHP come un punto di intervento a sé stante. Entrambe le funzioni integrano le scansioni dei file pianificabili, ma non le rendono superflue né sostituiscono la manutenzione delle applicazioni.

Anche l’estensione di WordPress denominata “Imunify Security Plugin” non costituisce un sostituto autonomo dell’agente server. Essa viene gestita dall’agente Imunify e non viene distribuita tramite la directory di WordPress.org. Nel backend di WordPress può rendere accessibili informazioni relative alle scansioni e alla protezione; tuttavia, le funzioni disponibili dipendono dal prodotto Imunify utilizzato e dalle versioni richieste dell’Agent e dell’estensione.

Per la documentazione operativa è quindi consigliabile effettuare un chiaro inventario: variante del prodotto, versione dell’agente installata, pannello di hosting e moduli di protezione attivati devono essere riportati tutti insieme in una documentazione delle modifiche. Un amministratore di WordPress può quindi classificare i messaggi nel backend senza presumere che il plugin controlli le regole del firewall o protegga altri account utente sul server. L’architettura di sicurezza lato server rimane determinante.

Cosa rivelano effettivamente i casi di malware rilevati

Le scansioni in background e su richiesta forniscono i risultati nell’interfaccia di gestione, indicando l’ora, il percorso del file e il motivo del rilevamento. Queste informazioni costituiscono un punto di partenza per la selezione: il percorso associa un risultato a un account cliente e a un’applicazione, mentre l’ora aiuta a confrontarlo con distribuzioni, caricamenti o voci di log sospette. Tuttavia, non sostituiscono una verifica del contenuto specifico e della sua provenienza.

Per stabilire le priorità, è importante il tipo di rilevamento. La presenza di codice dannoso infiltrato in un file altrimenti legittimo suggerisce spesso di esaminare la provenienza di tale file, le sue modifiche e ulteriori manipolazioni all’interno dello stesso account. Un file riconosciuto come dannoso di per sé può invece indicare la presenza di una webshell nascosta, di un dropper o di uno strumento di amministrazione indesiderato. Entrambi i casi richiedono un’analisi contestuale anziché conclusioni automatiche.

Il rilevamento di un elemento non dimostra né che ogni file presente nell’account sia stato compromesso, né descrive automaticamente la portata di un’intrusione. Al contrario, una scansione che non rilevi alcun elemento non garantisce la completa integrità: exploit di nuova generazione, codice occultato o persistenza al di fuori dell’area analizzata possono richiedere ulteriori indagini. Anche l’assenza di rilevamenti da parte del WAF o dello scanner non costituisce una prova del fatto che non si sia verificato alcun attacco.

Se, ad esempio, lo scanner segnala la presenza di un file PHP all’interno di un plugin di WordPress, l’amministratore dovrebbe innanzitutto salvare la cronologia dei risultati e il percorso, quindi confrontare il file con una fonte affidabile del produttore o con un backup verificato. Successivamente, occorre verificare la versione del plugin, gli amministratori, le credenziali di accesso ed eventuali backdoor. Per l’integrazione organizzativa di più progetti WordPress, sono utili le indicazioni relative a Requisiti di sicurezza nell'hosting per blogger, ma non sostituiscono le analisi forensi specifiche per ciascun caso.

Metodi di scansione, requisiti e portata

Le scansioni regolari dei file effettuate da Imunify360 controllano i file memorizzati nel parco hosting. Sono adatte sia per esecuzioni ricorrenti in background sia per una verifica mirata a seguito di una segnalazione proveniente dal monitoraggio o dall’assistenza. Il risultato, tuttavia, riguarda solo l’archivio di file analizzato: i contenuti presenti in un database, un attacco durante una richiesta HTTP o un accesso già compromesso richiedono verifiche aggiuntive e livelli di protezione supplementari.

Il sito Scansione in tempo reale estende questa verifica a determinati canali di trasmissione. Per l’analisi degli upload HTTP e HTTPS, la documentazione indica ModSecurity come prerequisito; gli upload FTP richiedono Pure-FTPd. È quindi necessario verificare per ogni singolo server se questi servizi siano attivi e configurati correttamente. La funzionalità non è automaticamente disponibile per ogni canale di upload semplicemente installando l’agente.

La portata della scansione comprende anche il controllo degli archivi. Secondo la documentazione, a partire dalla versione 6.2 di Imunify360 gli archivi ZIP vengono scansionati di default. Ciò risulta particolarmente utile nel caso di pacchetti di plugin, archivi di backup o estensioni caricate, ma non fornisce alcuna indicazione sul fatto che un’applicazione possa successivamente decomprimere l’archivio in modo non sicuro o che il suo contenuto sia tecnicamente ammissibile.

Il sito Scanner del database dei malware (MDS) integra la scansione dei file nei casi in cui del codice dannoso sia stato inserito, ad esempio, nei post, nelle opzioni o nei contenuti dei widget di un CMS. Il supporto documentato è limitato a WordPress, Joomla e Magento 2. Per applicazioni personalizzate, strutture di database diverse o altri sistemi di e-commerce, non si deve dedurre da ciò una copertura completa del database.

Pianificare RapidScan e i controlli del database

RapidScan modifica il processo delle scansioni ripetute, non l’obiettivo fondamentale di una scansione alla ricerca di malware. A tal fine, Imunify360 memorizza localmente i metadati dei file e gli hash, confrontando questi ultimi con un database basato sul cloud. Durante i cicli successivi, l’analisi locale può concentrarsi sui file che sono stati modificati o che sono ancora sconosciuti.

Il primo ciclo richiede innanzitutto una verifica standard dell’archivio. Il produttore indica che le scansioni successive potrebbero essere da cinque a venti volte più veloci. Questo intervallo è un dato fornito dal produttore in base alla situazione specifica e non costituisce una garanzia vincolante per ogni server: le dimensioni e la composizione dell’archivio, la frequenza delle modifiche, le prestazioni I/O disponibili e le condizioni di rete influenzano il risultato.

In termini di progettazione, ciò significa che un server con molti file web non modificati può essere RapidScan ne trarrà maggiori vantaggi rispetto a un account che genera continuamente upload, cache o file di log. Pertanto, non limitarti a misurare il tempo di esecuzione complessivo, ma documenta, prima di apportare modifiche, i percorsi interessati, il volume dei file e i tempi di attesa I/O. In questo modo è possibile definire le finestre di scansione e le esclusioni sulla base di cause concrete anziché di supposizioni.

In caso di post di WordPress manomessi o script inseriti nelle opzioni, una semplice scansione dei file potrebbe non essere sufficiente. MDS può essere utilizzato inizialmente in modalità non invasiva per i database WordPress supportati --scan Verificare. Questa operazione non modifica alcun dato e fornisce una base per valutare le posizioni, le ripercussioni sul sito web e la possibilità di ripristino prima di prendere una decisione.

La pulizia o il ripristino, invece, sono interventi sui contenuti produttivi. Prima di procedere, è necessario disporre di un backup aggiornato e verificato, di un’autorizzazione tecnica per il sito web in questione e di un piano di emergenza nel caso in cui vengano modificati contenuti legittimi. Nel caso di molti progetti separati dei clienti, è utile una chiara separazione dei contenuti, come avviene anche in Hosting multidominio È importante: delimita le competenze e facilita l'attribuzione dei reperti.

MDS non sostituisce un’analisi completa dell’incidente. La ricomparsa di codice dannoso nel database può indicare la presenza di un plugin vulnerabile, credenziali di accesso compromesse o una backdoor nel file. Una volta individuato, è quindi necessario esaminare non solo il contenuto del database, ma anche il CMS, le estensioni, gli account utente e l'origine dell'operazione di scrittura.

Integrazione con WordPress e aggiornamenti controllati del WAF

L'estensione per WordPress denominata "Imunify Security Plugin" viene gestita dall'agente Imunify sul server e non viene distribuita tramite la directory di WordPress.org. Consente agli amministratori di WordPress di visualizzare nel backend le informazioni di stato e, a seconda del prodotto Imunify utilizzato, ulteriori funzioni di sicurezza. Si tratta quindi di un’interfaccia e di un’integrazione, ma non sostituisce i meccanismi di scansione e protezione lato server.

Per la funzionalità di base, la documentazione indica come requisito minimo Imunify360 8.4.1 sul lato server. Funzionalità quali l’integrazione WAF o la gestione dei bot tramite IA sono state sviluppate separatamente e sono legate a versioni specifiche di agenti e plugin. Verifica quindi, prima di procedere al rollout, la combinazione specifica delle versioni, anziché dedurre l’esistenza di una determinata funzione di protezione dalla semplice presenza del plugin.

Anche il WAF dovrebbe essere gestito come livello a sé stante. A partire da imunify360-firewall 8.6.0 È disponibile una procedura documentata per disattivare gli aggiornamenti automatici delle regole di ModSecurity, elencare le versioni delle regole disponibili e selezionarne una in modo mirato. Ciò consente ai gestori di hosting di programmare in modo controllato le modifiche alle regole e, se necessario, di tornare a una versione nota.

Una procedura ottimale prevede che una nuova versione delle regole venga inizialmente implementata su un server di staging con siti WordPress rappresentativi, promozioni del negozio e file caricati. Solo quando non si riscontrano blocchi errati rilevanti o problemi di funzionamento, si procede all’implementazione graduale nell’ambiente di produzione. Il controllo delle versioni riguarda le regole ModSecurity, non le firme malware in generale, l’intero agente o altri componenti di Imunify.

Controllata Aggiornamenti delle regole WAF Non evitano ogni malfunzionamento, ma definiscono responsabilità chiare: chi verifica le modifiche, quali applicazioni fungono da casi di test e quando si esegue il rollback? Queste domande devono essere integrate nel processo operativo. Restano comunque necessari aggiornamenti tempestivi del CMS e delle estensioni, diritti di accesso restrittivi e backup testati, poiché nessun WAF elimina le vulnerabilità note presenti nel software installato.

Verificare e gestire in modo sicuro i malware rilevati

Il rilevamento di un malware è un’operazione di analisi, non comporta automaticamente un comando di eliminazione. Verifica innanzitutto nella dashboard la cronologia dei rilevamenti, l'ora, il percorso completo e il motivo del rilevamento. Queste informazioni aiutano a stabilire se il file appartiene a un plugin, a un tema, a una directory di upload o a un'applicazione sviluppata su misura e se lo stesso risultato è già stato riscontrato in precedenza.

Confronta un file PHP sospetto con una fonte affidabile del produttore della stessa versione o con un backup verificato. Nel caso di componenti standard, una nuova verifica completa è solitamente più significativa rispetto all’analisi isolata di singole righe di codice, che potrebbero essere state alterate. Salva il file individuato e i relativi log prima di apportare qualsiasi modifica, in modo da poter ricostruire in un secondo momento la via di ingresso.

L'analisi delle cause effettive va oltre il percorso segnalato: aggiorna le versioni dei CMS, dei plugin e dei temi interessati, controlla gli account utente e, in caso di sospetto fondato, cambia le credenziali di accesso. Cerca inoltre eventuali altre webshell, amministratori sconosciuti e attività pianificate sospette. La rimozione di un file non esclude che l’autore dell’attacco abbia lasciato un secondo punto di accesso.

L'individuazione di un problema nel database richiede particolare cautela, poiché gli interventi di pulizia possono modificare contenuti o impostazioni. Una scansione è innanzitutto una verifica; la pulizia o il ripristino presuppongono la disponibilità di un backup, l’approvazione da parte di un tecnico e un piano di emergenza. Il Malware Database Scanner supporta solo i casi documentati relativi ai database di WordPress, Joomla e Magento 2 e non costituisce una verifica generale di schemi applicativi generici.

Se viene rilevato Adminer, lo strumento potrebbe essere installato legittimamente, ma costituisce un riscontro comprensibile a causa delle sue funzionalità suscettibili di abuso. Anziché disattivare globalmente una categoria di rilevamento, verifica la necessità, l’integrità e la protezione degli accessi del file specifico. Se un’eccezione è inevitabile, un’esclusione limitata a un percorso specifico riduce la vulnerabilità in modo più efficace rispetto alla disattivazione del rilevamento a livello di account o di server.

Analizzare il carico, i falsi allarmi e la persistenza

Se il carico della CPU o il tempo di attesa I/O aumentano, l’esclusione non dovrebbe essere la prima misura da adottare. Raccogli innanzitutto i dati relativi agli eventi di scansione, ai percorsi interessati, ai tassi di modifica, ai processi attivi e al periodo in cui si verifica il carico. Solo la correlazione temporale mostra se la scansione in tempo reale potrebbe essere coinvolta o se, ad esempio, un backup, un’importazione, applicazioni difettose o un altro servizio stanno consumando le risorse.

I file di log descritti frequentemente possono innescare ripetute attività di scansione e costituire quindi una possibile causa di carico aggiuntivo. Un caso di assistenza documentato tratta questo modello relativo ai file di log di WordPress, ma non dimostra l’esistenza di una regola generale di causa-effetto valida per ogni server sovraccarico. Verifica quindi in modo specifico i percorsi dei file e le frequenze di scrittura, invece di escludere preventivamente intere directory dei clienti dal Scanner antimalware da escludere.

Le eccezioni devono avere uno scopo ben definito, un responsabile e essere sottoposte a verifica periodica. Per un percorso generato in modo legittimo e molto attivo, un’eccezione limitata può essere giustificabile previa analisi. Tuttavia, essa non deve essere estesa in modo inavvertito alle directory di upload o alle directory delle applicazioni, nelle quali gli aggressori potrebbero depositare o modificare file.

La ricomparsa di reperti dopo una pulizia suggerisce di effettuare un’analisi per verificare la presenza di Persistenza anziché limitarsi a una semplice cancellazione. Oltre all’archivio dei file e al database, la verifica deve includere i cronjob, gli account amministratore sconosciuti, le credenziali di accesso, i log del server web e i processi in esecuzione. In particolare, le attività pianificate possono scaricare nuovamente codice dannoso o sostituire una webshell rimossa.

A partire dalla versione 6.10, Imunify360 documenta la scansione dei file crontab di sistema e degli utenti come funzione sperimentale e disattivata per impostazione predefinita. Ciò amplia l’interfaccia di controllo, ma non sostituisce la valutazione manuale di un’attività sospetta. Prima di attivarla, verifica il carico, la compatibilità e l’impatto sulle proprie operazioni; ciò non implica un’attivazione generalizzata per ogni ambiente di hosting.

Decidere in merito a gestione, migrazione e implementazione

Per un piccolo server con pochi siti web possono essere sufficienti scansioni in background programmabili, notifiche tracciabili e l’approvazione manuale delle misure da adottare. Negli ambienti di hosting rivenditori e condiviso, invece, crescono i requisiti relativi a Procedure di escalation: Chi valuta i risultati delle ricerche, chi contatta i clienti, chi è autorizzato a concedere deroghe e quando viene limitato un account? Definire chiaramente le responsabilità evita che gli interventi correttivi o le falle nella sicurezza rimangano in sospeso tra l’assistenza e l’amministrazione.

La protezione in tempo reale, gli intervalli di scansione e le notifiche devono essere adeguati al tasso di modifica e alle risorse del server. Molti account clienti indipendenti traggono vantaggio da procedure coerenti e da una registrazione tracciabile. Un singolo progetto critico per l'azienda richiede spesso anche un processo di manutenzione e approvazione coordinato. Misure di protezione fondamentali come aggiornamenti, diritti minimi e backup testati rimangono comunque necessarie a prescindere da ciò.Criteri per la scelta di un’offerta di web hosting adeguata

Il repository di produzione e le installazioni di test devono essere rigorosamente separati. Il produttore distribuisce gradualmente le versioni stabili nel canale di produzione, indicando un periodo di tempo che può arrivare fino a circa due settimane. Una funzione disponibile solo nel repository di test o dopo un'installazione con --beta Se è visibile, non significa quindi automaticamente che sia disponibile in modo stabile.

Un controllato Lancio Si inizia con l'identificazione della versione e un server di staging o pilota rappresentativo. Dopo l'aggiornamento, controlla lo stato dell'agente, la gestione dei pacchetti, i log anomali e le funzioni importanti per i clienti. Solo se tutto procede senza intoppi si procede alla distribuzione graduale. Ciò non elimina ogni rischio, ma rende visibili prima eventuali anomalie e facilita una reazione mirata.

La migrazione volontaria a Patchman è una decisione operativa, non un aggiornamento automatico. Dopo la migrazione, i file non potranno più essere ripristinati dalla precedente quarantena di Patchman; secondo la documentazione, Imunify crea copie di backup dei file ripuliti. Prima di procedere alla migrazione, gli operatori dovrebbero quindi chiarire in modo vincolante le modalità di conservazione, i percorsi di ripristino, la comunicazione con i clienti e le responsabilità.

Un problema specifico di aggiornamento relativo a imunify-common Il problema della versione 1.3.21-1 su CloudLinux 8 con database RPM basato su Berkeley DB è stato risolto, secondo il produttore, a partire dalla versione 1.3.22-2. Ciò non costituisce un argomento generale contro gli aggiornamenti. Tuttavia, sottolinea perché le finestre di manutenzione, le versioni documentate e i controlli successivi della gestione dei pacchetti facciano parte di una procedura di aggiornamento professionale.