1 15/04/2026 9 min

Su CentOS 7, chkrootkit resta uno strumento utile per un controllo rapido di compromissione locale, ma va usato per quello che è: un indicatore, non una sentenza. La scansione intercetta segnali noti di rootkit, backdoor e manomissioni di base, però può produrre falsi positivi su sistemi con kernel vecchi, servizi custom o binari non standard. La scelta sensata è installarlo, automatizzare l’esecuzione e conservare l’output in modo leggibile, così da confrontare i risultati nel tempo e capire quando un alert merita davvero un approfondimento.

Quando ha senso usarlo su CentOS 7

CentOS 7 è ancora presente in molti ambienti legacy, spesso con host esposti a Internet, pannelli di controllo, stack LAMP/LEMP e servizi SSH aperti da anni. In questi contesti chkrootkit ha senso come controllo periodico di igiene operativa: non sostituisce EDR, audit di integrità o hardening, ma può intercettare anomalie grossolane come binari alterati, hook sospetti o segnali di compromissione noti.

Il punto importante è non trattarlo come un antivirus “magico”. Se il server è già compromesso con privilegi elevati, qualsiasi verifica locale può essere manipolata. Per questo la scansione va affiancata almeno a log centralizzati, controllo degli accessi SSH, patching regolare e una procedura di risposta che preveda anche una verifica da ambiente esterno o da snapshot pulita.

Installazione da EPEL su CentOS 7

Su CentOS 7 chkrootkit si installa normalmente dal repository EPEL. Prima conviene verificare che il sistema sia aggiornato e che il repository sia disponibile. L’installazione non richiede modifiche invasive, quindi il blast radius è basso: si aggiunge un pacchetto e, se vuoi automatizzare, un file cron dedicato.

Comandi essenziali:

sudo yum install -y epel-release
sudo yum install -y chkrootkit

Verifica immediata dell’installazione:

rpm -q chkrootkit
which chkrootkit
chkrootkit -V

Atteso: il pacchetto risulta installato, il binario è presente in un path come /usr/sbin/chkrootkit e la versione viene stampata senza errori. Se epel-release non è disponibile, il problema è a monte nel repository: in quel caso va verificata la connettività verso i mirror, la configurazione di yum.repos.d e l’eventuale policy di rete che blocca HTTP/HTTPS in uscita.

Esecuzione manuale e lettura dell’output

Prima di automatizzare, esegui una scansione manuale e osserva l’output completo. È il modo più rapido per capire se il sistema genera segnalazioni pulite o se ci sono già falsi positivi da classificare. Il comando standard è semplice:

sudo chkrootkit

In genere vedrai controlli su binari, processi, porte e pattern noti. Le righe con INFECTED non vanno lette in modo automatico: una parte delle segnalazioni può dipendere da processi legittimi, container, strumenti di hardening o servizi che usano nomi non banali. La procedura corretta è confrontare il risultato con il contesto del server: cosa gira davvero, quali porte sono attese, quali binari sono stati personalizzati e quali differenze ci sono rispetto a un sistema pulito dello stesso ruolo.

Se compare un warning su uno specifico item, la verifica non si fa “a sensazione”: si controllano il processo, il pacchetto proprietario e il file coinvolto. Per esempio, se un controllo segnala un demone sospetto, puoi incrociare il PID con ps, il socket con ss e il file con il package manager:

ps -fp <PID>
ss -ltnp
rpm -qf /percorso/del/binario

Se il binario non appartiene ad alcun pacchetto RPM, non significa automaticamente compromissione, ma aumenta l’attenzione: molti agenti, tool di monitoraggio e software installati manualmente finiscono lì. In quel caso il controllo utile è il confronto con inventario, checksum noti e origine del deployment.

Automatizzare la scansione con cron

Per un server legacy, la soluzione più pratica è schedulare chkrootkit una volta al giorno o più spesso se il rischio operativo è alto. L’obiettivo non è saturare la macchina con controlli continui, ma avere una foto ricorrente, salvata in un file, che possa essere consultata e confrontata. Su CentOS 7 il modo più lineare è usare cron con un piccolo wrapper shell.

Crea uno script dedicato, ad esempio /usr/local/sbin/chkrootkit-scan.sh:

sudo tee /usr/local/sbin/chkrootkit-scan.sh >/dev/null <<'EOF'
#!/bin/bash
set -u
PATH=/usr/sbin:/usr/bin:/sbin:/bin
OUTDIR=/var/log/chkrootkit
DATE=$(date +%F_%H-%M-%S)
mkdir -p "$OUTDIR"
/usr/sbin/chkrootkit > "$OUTDIR/chkrootkit-$DATE.log" 2>&1
EOF
sudo chmod 750 /usr/local/sbin/chkrootkit-scan.sh

La scelta di un wrapper è utile per tre motivi: standardizza il PATH, separa l’output per data e rende più semplice il rollback. Se qualcosa non va, puoi disabilitare solo il cron senza toccare il pacchetto installato.

Poi aggiungi una voce in cron, ad esempio giornaliera alle 02:15:

sudo tee /etc/cron.d/chkrootkit >/dev/null <<'EOF'
SHELL=/bin/bash
PATH=/usr/sbin:/usr/bin:/sbin:/bin
15 2 * * * root /usr/local/sbin/chkrootkit-scan.sh
EOF

Verifica che cron stia leggendo il file e che il job sia eseguibile. Su CentOS 7 il servizio è gestito da systemd, quindi puoi controllare lo stato del demone e i log recenti:

systemctl status crond
journalctl -u crond --since today

Atteso: crond attivo e nessun errore di parsing nel file sotto /etc/cron.d/. Se il job non parte, il primo controllo è sempre la sintassi: un cron file errato viene spesso ignorato o loggato in modo molto esplicito nel journal.

Gestione log e conservazione dei risultati

Salvare l’output in file separati per data è più utile che appendere tutto in un unico log infinito. Ti permette di capire quando nasce una segnalazione e se si ripete. Per un ambiente piccolo può bastare una retention di 30 giorni con rotazione semplice. Se invece hai più host, conviene spedire l’output a syslog, a un SIEM o almeno a uno share centralizzato, così i log non restano solo sul server che stai controllando.

Una rotazione base con logrotate può essere sufficiente. Esempio file /etc/logrotate.d/chkrootkit:

/var/log/chkrootkit/*.log {
    daily
    rotate 30
    missingok
    compress
    delaycompress
    notifempty
    create 0640 root root
}

Qui il rischio è minimo, perché si tratta solo di file di log. Il rollback è immediato: rimuovi il file di rotazione e i log restano intatti. Se usi un sistema di monitoring, puoi anche creare una regola che notifica solo quando nel log compare INFECTED o quando la scansione non riesce a completarsi.

Ridurre i falsi positivi senza perdere valore operativo

Il problema più comune non è la mancanza di alert, ma l’eccesso di rumore. Un chkrootkit configurato male finisce ignorato. Il metodo giusto è trattare ogni segnalazione come un dato da verificare, non come un verdetto. Se un controllo segnala un processo noto, bisogna capire se il software è legittimo o se il server è davvero anomalo.

Tre casi tipici:

  • servizi custom installati fuori da RPM che generano warning su binari non gestiti;
  • ambienti con container o hosting condiviso, dove alcuni controlli vedono processi legittimi ma non usuali;
  • kernel e toolchain vecchi di CentOS 7, che possono far scattare controlli pensati per sistemi più moderni.

Per ogni allarme, il filtro corretto è sempre la verifica incrociata: processo, pacchetto, hash, origine del deploy, orario della comparsa. Se il software è installato da tarball o da uno script interno, conviene documentarlo in un inventario tecnico, perché altrimenti ogni scan futura produrrà lo stesso dubbio.

Integrazione minima con monitoring

Se vuoi fare un passo in più, puoi fare in modo che lo script segnali solo le anomalie principali. Per esempio, puoi cercare la stringa INFECTED nell’output e generare un exit code utile per il monitoring. In questo modo Zabbix, Nagios, Icinga o un semplice wrapper cron possono distinguere tra esito pulito ed esito sospetto.

sudo tee /usr/local/sbin/chkrootkit-scan.sh >/dev/null <<'EOF'
#!/bin/bash
set -u
PATH=/usr/sbin:/usr/bin:/sbin:/bin
OUTDIR=/var/log/chkrootkit
DATE=$(date +%F_%H-%M-%S)
mkdir -p "$OUTDIR"
OUTFILE="$OUTDIR/chkrootkit-$DATE.log"
/usr/sbin/chkrootkit > "$OUTFILE" 2>&1
if grep -q 'INFECTED' "$OUTFILE"; then
  logger -t chkrootkit "Potential issue detected in $OUTFILE"
  exit 2
fi
exit 0
EOF

Questo approccio non elimina il rischio di falsi positivi, ma rende il risultato machine-readable. L’alerting va comunque tarato con attenzione: un controllo troppo aggressivo crea rumore, uno troppo permissivo non serve a nulla. La soglia pratica è semplice: notifica automatica solo su presenza di indicatori chiari, revisione manuale per il resto.

Controlli di sicurezza complementari

chkrootkit è un tassello, non il perimetro. Su CentOS 7 ha senso affiancarlo ad altre verifiche di base: aggiornamenti di sicurezza, audit dei servizi esposti, controllo dei permessi su /etc e /var/www, verifica delle chiavi SSH e monitoraggio di accessi anomali. Se il server ospita mail, web o database, una scansione rootkit non basta a intercettare abuso di credenziali, web shell o escalation applicativa.

In ambienti esposti, controlla anche la superficie di attacco: porte in ascolto, firewall attivo, SELinux in modalità enforcing quando possibile, e servizi non necessari disabilitati. Un rootkit spesso è la fase finale di un problema iniziato molto prima, con una vulnerabilità non patchata o una password debole. Se non chiudi la causa, il controllo periodico diventa solo un termometro su un paziente lasciato scoperto.

Rollback e manutenzione ordinaria

La manutenzione è semplice: se il job non serve più, rimuovi il file in /etc/cron.d/chkrootkit e lo script in /usr/local/sbin/chkrootkit-scan.sh. Se vuoi disinstallare tutto, puoi togliere il pacchetto senza toccare i log già raccolti:

sudo rm -f /etc/cron.d/chkrootkit
sudo rm -f /usr/local/sbin/chkrootkit-scan.sh
sudo yum remove -y chkrootkit

Prima di rimuovere, conserva almeno un paio di report storici: sono utili per confrontare un eventuale incidente futuro. Se invece mantieni il sistema in esercizio, rivedi periodicamente il cron, la retention dei log e l’elenco dei falsi positivi noti. Su un host legacy il valore vero non è l’installazione in sé, ma la disciplina con cui lo usi nel tempo.

In sintesi operativa: installa da EPEL, verifica a mano, automatizza con cron, salva l’output in file separati, integra un minimo di alerting e non confondere un warning con una compromissione fino a quando non hai fatto un controllo incrociato. Su CentOS 7 questa è una base sensata, leggera e abbastanza robusta da stare in produzione senza trasformarsi in un altro pezzo di rumore operativo.