Installare Linux Malware Detect e ClamAV su CentOS

Installare Linux Malware Detect e ClamAV su CentOS

Su CentOS, mettere insieme Linux Malware Detect (LMD) e ClamAV ha senso quando vuoi un controllo locale su file web, upload e home utente senza affidarti solo a protezioni perimetrali. LMD ti aiuta a intercettare firme e comportamenti tipici del malware PHP, shell e script offuscati; ClamAV aggiunge un motore antivirus più generico, utile per allegati, archivi e contenuti che passano dai servizi esposti.

Il punto non è “installare due pacchetti e via”. La parte delicata è evitare falsi positivi inutili, non saturare I/O e CPU durante le scansioni, e non lasciare in giro credenziali o permessi troppo larghi. Se il server ospita siti in produzione, conviene partire da un set minimo, verificare il comportamento sui percorsi critici e solo dopo schedulare i controlli periodici.

Quando ha senso usare entrambi

LMD e ClamAV non fanno esattamente la stessa cosa. LMD è molto orientato all’hosting Linux: trova payload web, webshell, pattern diffusi nei compromessi PHP e tracce di infezione in directory come `public_html`, `www`, `uploads` o cache applicative. ClamAV è più trasversale e lavora bene su malware noto, documenti infetti e archivi compressi.

In pratica, LMD è più utile per il filesystem di un server web, mentre ClamAV è il motore che puoi riusare anche per mail gateway, upload e integrazioni applicative. Se hai poco margine di risorse, non serve spingere entrambe le scansioni in modo aggressivo sugli stessi path alla stessa ora: meglio separare i ruoli. LMD può girare con frequenza maggiore su directory web, ClamAV può coprire controlli più ampi ma meno frequenti.

Prerequisiti e verifica del sistema

Su CentOS conviene verificare prima versione, repository e stato di SELinux, perché i problemi più comuni non sono l’installazione in sé ma il blocco su download, esecuzione script o accesso ai path da scansionare. I comandi seguenti ti danno la fotografia minima del nodo.

cat /etc/centos-release
getenforce
rpm -q yum-utils epel-release
uname -r

Se `getenforce` restituisce `Enforcing`, non è un problema di per sé. Vuol dire solo che eventuali mismatch di contesto o policy vanno tenuti in conto quando LMD o ClamAV devono leggere directory non standard. Se manca `epel-release`, installarlo è quasi sempre il primo passo utile, perché ClamAV su CentOS spesso arriva da EPEL oppure da repository compatibili.

Installazione di ClamAV su CentOS

Prima installi il motore antivirus, poi costruisci sopra la logica di scansione. Su CentOS 7 e derivate storiche, il pacchetto può richiedere EPEL; su installazioni più recenti il nome dei pacchetti resta simile, ma cambia spesso la disponibilità dei repository. Il metodo più pulito è usare il gestore nativo, così mantieni aggiornamenti e dipendenze allineate.

sudo yum install -y epel-release
sudo yum install -y clamav clamav-update clamd

Se `clamav-update` o `clamd` non sono disponibili con quel nome, non forzare tentativi casuali: controlla i pacchetti disponibili con `yum list available | grep -i clam`. In alcuni casi il servizio può chiamarsi `clamd@scan` o avere unità diverse a seconda della release. La logica resta la stessa: motore, database firme, servizio daemon.

Dopo l’installazione, aggiorna le firme. La prima sincronizzazione può richiedere un po’ di tempo e, se il mirror è lento o limitato, il problema si manifesta come timeout più che come errore netto.

sudo freshclam

Se `freshclam` fallisce per rate limit o mirror bloccato, non insistere a raffica. Verifica il file di log di `freshclam` e, se necessario, imposta un mirror locale o lascia che il servizio aggiorni in autonomia dopo il primo bootstrap. Il file tipico da controllare è `/var/log/clamav/freshclam.log`, ma il path può cambiare in base al pacchetto installato.

Avvio e abilitazione del servizio clamd

Il daemon `clamd` è il pezzo che rende le scansioni più rapide rispetto all’invocazione del motore ad ogni controllo. Una volta installato, devi assicurarti che parta al boot e che il socket o la porta siano coerenti con la configurazione. Prima di toccare i file, guarda lo stato del servizio.

sudo systemctl enable --now clamd
sudo systemctl status clamd --no-pager

Se il servizio non si avvia, i primi punti da controllare sono il file di configurazione del daemon, i permessi sulle directory del socket e la presenza delle firme aggiornate. Un errore classico è un path sbagliato nel file `clamd.conf`, oppure un socket non scrivibile dal processo che lancia la scansione.

Su macchine con carico web, non è raro dover limitare il numero di thread o la dimensione massima dei file processati. È una scelta di capacità, non di funzionalità: un antivirus troppo aggressivo può diventare lui stesso il collo di bottiglia.

Installazione di Linux Malware Detect

LMD non sempre arriva dai repository standard nello stesso modo di ClamAV. In molti ambienti hosting si installa scaricando l’archivio ufficiale, estraendolo e lanciando lo script di installazione. La procedura è semplice, ma va fatta con attenzione per non sporcare il sistema con file sparsi o esecuzioni fuori contesto.

cd /usr/local/src
sudo wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
sudo tar -xzf maldetect-current.tar.gz
cd maldetect-*
sudo ./install.sh

Se l’host non ha accesso diretto a Internet, scarica l’archivio su una macchina fidata, verifica checksum o firma se disponibili, e trasferiscilo in modo controllato. In un contesto serio, evitare download “al volo” da server di produzione è una buona abitudine di igiene operativa, non un eccesso di prudenza.

Dopo l’installazione, LMD crea normalmente binari e file di configurazione sotto `/usr/local/maldetect/` e un comando eseguibile come `maldet`. Verifica che sia raggiungibile e che la versione corrisponda a quella attesa.

sudo maldet -v

Configurazione minima di LMD per un server web

La configurazione va adattata al profilo del server. Su un nodo hosting classico, l’obiettivo è scansionare directory web e limitare il rumore. I file di configurazione più importanti sono in genere `conf.maldet` e, in alcuni casi, il file di integrazione con `clamd`.

Apri il file di configurazione e controlla i parametri che impattano davvero: path di scansione, modalità quarentena, notifiche, integrazione con ClamAV e limiti di esclusione. Non serve cambiare dieci opzioni insieme; meglio una modifica alla volta, con controllo del risultato.

sudo cp /usr/local/maldetect/conf.maldet /usr/local/maldetect/conf.maldet.bak.$(date +%F)
sudo vi /usr/local/maldetect/conf.maldet

Le opzioni esatte possono variare tra versioni, quindi la strategia corretta è leggere il file e cercare le voci che controllano `scan`, `quarantine`, `email_alert`, `clamav_scan` o equivalenti. Se la tua versione supporta l’integrazione diretta con `clamd`, abilitala solo dopo aver verificato che il daemon sia operativo. La combinazione più robusta è LMD per il rilevamento e ClamAV per l’analisi con database aggiornato.

Su server con molti virtual host, ha senso escludere directory temporanee ad alta rotazione come cache applicative, spool e snapshot di backup, almeno nella scansione giornaliera. Scansionarle tutte ogni volta aumenta i tempi e spesso non aggiunge valore, perché il segnale utile sta nelle directory di upload e nei document root.

Integrazione con ClamAV: quando e come

Se vuoi che LMD usi ClamAV come motore di supporto, devi assicurarti che `clamd` sia in ascolto e che il percorso del socket sia noto alla configurazione di LMD. In alcuni casi il collegamento avviene via socket Unix, in altri via TCP locale. Il socket è preferibile quando possibile: meno superficie esposta e meno dipendenze di rete.

Prima di modificare, verifica dove il daemon espone il servizio. Un controllo utile è cercare il parametro `LocalSocket` o equivalente nel file di configurazione di ClamAV.

sudo grep -E '^(LocalSocket|TCPSocket|TCPAddr)' /etc/clamd.d/*.conf /etc/clamd.conf 2>/dev/null
sudo ss -lntp | grep -i clamd

Se LMD non riesce a parlare con `clamd`, il problema di solito è uno tra questi: path del socket errato, permessi insufficienti, servizio non attivo, oppure configurazione incoerente tra i due demoni. In quel caso è inutile cambiare le regole di scansione: prima devi ristabilire il canale di comunicazione.

Primo test controllato su una directory reale

Una volta installati e configurati i due componenti, fai un test su una directory piccola e rappresentativa, non sull’intero filesystem. L’idea è capire se il motore parte, se i log si scrivono e se eventuali file sospetti vengono rilevati senza far esplodere il carico.

sudo maldet -a /var/www/html
sudo maldet --report <ID_REPORT>

Se il comando restituisce un report, controlla il numero di file analizzati, gli eventuali match e il tempo impiegato. Se non hai un file realmente infetto da testare, puoi usare il classico file di test EICAR per validare la pipeline antivirus senza rischi. Va posizionato in una directory di prova, mai in produzione vera, e rimosso subito dopo il test.

printf 'X5O!P%%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > /tmp/eicar.com
sudo clamscan /tmp/eicar.com

Il risultato atteso è un rilevamento coerente del file di test. Se ClamAV non lo segnala, non fidarti ancora della configurazione: prima verifica aggiornamento firme, stato del daemon e correttezza del comando usato. Un test che non rileva l’EICAR non ti dice nulla di buono sulla catena di scansione.

Schedulazione delle scansioni senza saturare il server

La scansione manuale è utile per validare, ma il valore vero arriva dalla continuità. Su CentOS puoi usare cron per LMD e, dove opportuno, un timer systemd o una semplice entry cron per ClamAV. La regola è non far partire controlli pesanti negli orari di picco del traffico web o dei backup.

Un approccio pratico è differenziare i livelli: scansione rapida giornaliera sui document root, scansione più ampia settimanale sulle home utente e verifica delle firme ClamAV più frequente ma leggera. Se il server è multi-tenant, pianifica in finestre separate per evitare contesa su disco.

sudo crontab -e

Un esempio di schedulazione prudente può essere una scansione notturna e un aggiornamento firme al mattino presto. L’importante è registrare l’output in un log dedicato, così puoi distinguere un falso positivo da un blocco reale di configurazione.

0 3 * * * /usr/local/maldetect/maldet -a /var/www >> /var/log/maldetect-scan.log 2>&1
30 5 * * * /usr/bin/freshclam >> /var/log/freshclam.log 2>&1

Se usi cron, ricorda che l’ambiente è minimale: path assoluti, permessi corretti e output rediretto. Se il job fallisce, il primo controllo è il log che hai impostato tu, non quello che “dovrebbe” esserci da qualche parte.

Gestione delle quarantene e dei falsi positivi

La quarantena è utile solo se sai cosa ci finisce dentro e come recuperare un file legittimo. Prima di abilitarla in modo aggressivo, definisci una procedura di ripristino e un responsabile del controllo. Su hosting condiviso, un falso positivo su un plugin o su un uploader può generare più danni di un’infezione contenuta.

La prassi corretta è spostare in quarantena, registrare il report e verificare manualmente il file sospetto prima di eliminarlo. Non cancellare in automatico senza una finestra di osservazione, almeno nei primi giorni di esercizio. Se un file è davvero infetto, la pulizia o la sostituzione del codice devono essere tracciate, non improvvisate.

Per ridurre i falsi positivi, conviene escludere directory note di cache, archivi di backup e librerie terze che sono già validate da checksum o da deployment controllato. Il criterio è semplice: escludi ciò che ha già un’altra catena di fiducia; ispeziona ciò che riceve input esterni o viene scritto dagli utenti.

Controlli operativi dopo l’installazione

Dopo aver messo tutto in piedi, i controlli che contano davvero sono pochi ma concreti: servizio attivo, firme aggiornate, scansione eseguita, log scritti e nessun impatto anomalo su CPU, I/O o latenza HTTP. Se hai un pannello di monitoraggio, affianca ai log almeno il grafico del carico disco e dell’uso CPU durante la finestra di scansione.

systemctl is-active clamd
freshclam --version
maldet -v
journalctl -u clamd --since '1 hour ago' --no-pager

Se il server ospita siti PHP, un segnale da osservare è il tempo di risposta delle pagine durante la scansione. Un aumento marcato di TTFB o una coda anomala su I/O indica che la schedulazione è troppo aggressiva o che le directory scansionate sono troppo ampie. In quel caso riduci il perimetro o sposta il job in una fascia più tranquilla.

Manutenzione periodica e aggiornamenti

Antivirus e malware detector non sono installazioni “una tantum”. Le firme cambiano, i pattern di attacco evolvono e i percorsi applicativi si modificano quando aggiorni CMS, plugin o framework. Una revisione mensile della configurazione basta spesso per evitare che il sistema resti formalmente attivo ma praticamente cieco sui path nuovi.

Ogni volta che aggiorni applicazioni web o pannelli di hosting, controlla se sono comparsi nuovi directory root, nuovi upload path o nuove cache persistenti. È lì che il malware tende a nascondersi quando trova un perimetro troppo statico. Dopo l’aggiornamento, lancia una scansione mirata su quei path e confronta il numero di match con il baseline precedente.

In ambienti esposti, aggiungi anche un controllo minimo sulle esposizioni: il demone ClamAV non deve accettare connessioni non necessarie dall’esterno, e i file di configurazione non devono essere modificabili da utenti non privilegiati. La sicurezza qui è soprattutto disciplina operativa: meno superficie d’attacco, meno sorprese.

Schema rapido da tenere come riferimento

La sequenza più pulita, in sintesi, è questa: installa ClamAV, aggiorna le firme, avvia `clamd`, installa LMD, verifica la sua versione, collega i due componenti se serve, poi testa su una directory ridotta e infine schedula le scansioni. Saltare il test iniziale è l’errore più comune, e quasi sempre si paga quando il server è già sotto carico.

Se devi portare questa configurazione in produzione, la regola operativa è: cambia una cosa alla volta, conserva backup dei file di configurazione e registra i log prima di decidere se la modifica ha funzionato. Un antivirus ben installato ma non verificato è solo rumore in più; uno ben tarato diventa invece una rete di contenimento utile, misurabile e sostenibile.