rkhunter avverte della modifica dell'inode ma non cambia la data di modifica del file

8

Ho diversi sistemi che eseguono Centos 6 con rkhunter installato. Ho un cron quotidiano che esegue rkhunter e riporta indietro via e-mail.

Ricevo molto spesso rapporti come:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

Da quello che ho capito, rkhunter di solito riporta un hash e / o una data di modifica cambiati sui file scansionati, quindi questo mi porta a pensare che non ci siano cambiamenti reali.

La mia domanda: c'è qualche altra attività sulla macchina che potrebbe cambiare l'inode (eseguendo ext4) o sta davvero yumfacendo delle modifiche regolari (~ una volta alla settimana) a questi file come parte dei normali aggiornamenti di sicurezza?

centos yum rkhunter

— Nic Cottrell
fonte

8

L'aggiornamento dei file viene spesso eseguito scrivendo un nuovo file nella stessa directory seguito da un nuovo nome del file sopra il vecchio file. Questo metodo viene solitamente applicato a tutto ciò che è installato tramite un gestore di pacchetti, ma anche a qualsiasi aggiornamento eseguito su eseguibili e librerie anche se aggiornato per altri motivi.

Questo modo di aggiornare i file garantisce che qualsiasi processo che apre il file otterrà il vecchio o il nuovo e non vedrà nulla cambiare nel file che hanno aperto. Significa che ogni volta che viene aggiornato, avrai effettivamente un nuovo file con lo stesso nome, quindi il numero di inode è cambiato.

Immagino che questo sia il motivo per cui quei file hanno un nuovo numero di inode.

Un aggiornamento di sicurezza potrebbe essere uno dei motivi. Ma c'è un'altra possibilità, che ho osservato per la prima volta su Fedora Core 1, e che a un certo punto avrebbe potuto trasformarsi in Centos.

I file eseguibili e le librerie vengono prelink in modo tale che possano avviarsi più velocemente e utilizzare meno memoria. Durante questo processo l'indirizzo di caricamento viene randomizzato per rendere un po 'più difficile lo sfruttamento delle vulnerabilità della sicurezza. Un cron job ripeterebbe periodicamente il processo con nuovi indirizzi casuali, facendo sì che tutti gli eseguibili e le librerie prelink vengano aggiornati.

— kasperd
fonte

2

Sì, il prelinking sembra la spiegazione più probabile qui.

— Michael Hampton,

C'è un buon modo per gestire questo però? Se avessi solo un cron da eseguire, rkhunter --propupdpotrei perdere un hack e invalidare l'intero punto di rkhunter, giusto?

— Nic Cottrell,

1

@NicholasTolleyCottrell lo rpmgestisce verificando prima l'integrità prelinkdell'eseguibile, quindi chiama l' prelinkeseguibile con argomenti per ripristinare il prelinking con input da un eseguibile prelinked e output su stdout. Quindi rpmpuò verificare l'integrità di tale output. Non ho idea se questo approccio può essere applicato rkhunter.

— Kasperd,

1

Vedi questo thread per come ottenere un checksum che non salterà: linuxquestions.org/questions/linux-security-4/… . Mi sono allontanato da rkhunter come strumento basato su cron. Ha molti controlli utili, ma l'incapacità di disattivare i controlli che equivalgono a falsi positivi lo rende quasi inutile per attirare la tua attenzione su dove è necessario, dato che mi sono appena abituato a ignorare i suoi rapporti via email. Lo trovo ancora occasionalmente utile come strumento di esecuzione manuale.

— mc0e,

2

L'altra opzione che ho trovato era disabilitare completamente questi test delle proprietà. Se modifichi /etc/rkhunter.confe cerchi la DISABLE_TESTSlinea e la cambi in:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

Il propertiestest è quello che controlla e restituisce falsi positivi sugli hash dei file.

— Nic Cottrell
fonte

1

Un numero di inode modificato di solito significa che il file è stato sostituito. Potrebbe, come dici tu, essere dovuto a un aggiornamento previsto. Verificherei che i md5sum di quei file corrispondano a quelli delle versioni distribuite. Se hai un altro sistema comparabile in circolazione, potrebbe essere più semplice confrontarlo.

Dai un'occhiata alla risposta accettata alle modifiche dei rapporti di rkhunter nelle proprietà dei file, ma non vedo che sono state aggiornate da yum per come controllare da quale pacchetto provengono quei binari.

Non sarebbe troppo sorprendente se quei binari provenissero da una distribuzione che è stata aggiornata a causa di un problema con un altro binario che è stato modificato, ma i binari che hai elencato sono stati inclusi nella nuova versione del pacchetto invariato. Il tuo rapporto ha anche mostrato alcuni file binari in cui è stato modificato il contenuto ?

— mc0e
fonte

No, in realtà, sembra che io abbia mai ricevuto che le proprietà del file sono cambiate, mai come il contenuto.

— Nic Cottrell,

-1

Ho clonato un'unità su un'unità più grande e ho ricevuto gli avvisi di file con numeri di inode diversi. Ho rimosso rkhunter dal sistema e reinstallato ed eseguito nuovamente la scansione senza avvertire che i numeri di inode sono stati cambiati

— Will Smith
fonte