rkhunter memperingatkan perubahan inode tetapi tidak ada perubahan tanggal modifikasi file

8

Saya memiliki beberapa sistem yang menjalankan Centos 6 dengan rkhunter diinstal. Saya memiliki cron harian yang menjalankan rkhunter dan melaporkan kembali melalui email.

Saya sangat sering mendapat laporan seperti:

---------------------- 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

Dari apa yang saya mengerti, rkhunter biasanya akan melaporkan hash dan / atau modifikasi tanggal yang diubah pada file yang dipindai, jadi ini membuat saya berpikir bahwa tidak ada perubahan nyata.

Pertanyaan saya: apakah ada beberapa aktivitas lain pada mesin yang dapat membuat perubahan inode (menjalankan ext4) atau apakah ini benar-benar yummembuat perubahan reguler (~ seminggu sekali) ke file-file ini sebagai bagian dari pembaruan keamanan normal?

centos yum rkhunter

— Nic Cottrell
sumber

8

Memperbarui file sering dilakukan dengan menulis file baru di direktori yang sama diikuti dengan mengganti nama file di atas file lama. Metode ini biasanya diterapkan untuk semua yang diinstal melalui manajer paket, tetapi juga untuk setiap pembaruan yang dilakukan ke executable dan perpustakaan bahkan jika diperbarui karena alasan lain.

Cara memperbarui file ini memastikan bahwa setiap proses membuka file akan mendapatkan yang lama atau yang baru, dan tidak melihat perubahan apa pun dalam file, yang telah mereka buka. Itu berarti bahwa setiap kali diperbarui, Anda benar-benar akan memiliki file baru dengan nama yang sama, maka nomor inode telah berubah.

Saya kira ini adalah alasan untuk file-file tersebut memiliki nomor inode baru.

Pembaruan keamanan bisa menjadi salah satu alasan. Tetapi ada kemungkinan lain, yang pertama kali saya amati pada Fedora Core 1, dan itu bisa saja membuatnya menjadi Centos di beberapa titik.

File executable dan pustaka sedang di-prelink sehingga mereka dapat mulai lebih cepat dan menggunakan lebih sedikit memori. Selama proses ini, alamat muat diacak untuk membuat mengeksploitasi kerentanan keamanan sedikit lebih sulit. Pekerjaan cron secara berkala akan mengulangi proses dengan alamat acak baru yang menyebabkan semua executable dan pustaka yang telah diproyeksikan untuk diperbarui.

— kasperd
sumber

2

Yap, prelink sepertinya merupakan penjelasan yang paling mungkin di sini.

— Michael Hampton

Apakah ada cara yang baik untuk menangani ini? Jika saya hanya memiliki cron untuk dijalankan rkhunter --propupdmaka saya bisa melewatkan hack dan membatalkan seluruh poin rkhunter, kan?

— Nic Cottrell

1

@NicholasTolleyCottrell rpmmenanganinya dengan terlebih dahulu memverifikasi integritas prelinkexecutable, kemudian memanggil prelinkexecutable dengan argumen untuk mengembalikan prelinking dengan input dari executable prelink dan output ke stdout. Kemudian rpmdapat memeriksa integritas output itu. Tidak tahu apakah pendekatan itu dapat diterapkan rkhunter.

— kasperd

1

Lihat utas ini untuk cara mendapatkan checksum yang tidak akan melompat-lompat: linuxquestions.org/questions/linux-security-4/… . Saya telah pindah dari rkhunter sebagai alat berbasis cron. Ini memiliki banyak pemeriksaan yang berguna, tetapi ketidakmampuan untuk mematikan pemeriksaan yang berjumlah positif palsu membuatnya hampir tidak berguna untuk mendapatkan perhatian Anda ke tempat yang diperlukan, karena saya hanya terbiasa mengabaikan laporan yang dikirim melalui email. Saya masih menemukan itu kadang-kadang berguna sebagai alat yang dijalankan secara manual.

— mc0e

2

Opsi lain yang saya temukan adalah untuk menonaktifkan tes properti ini sepenuhnya. Jika Anda mengedit /etc/rkhunter.confdan mencari DISABLE_TESTSbaris dan mengubahnya ke:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

The propertiestes adalah satu memeriksa dan kembali positif palsu pada hash file yang.

— Nic Cottrell
sumber

1

Nomor inode yang diubah biasanya berarti file telah diganti. Bisa seperti yang Anda katakan karena pembaruan yang diharapkan. Saya akan memverifikasi md5sums dari file-file itu cocok dengan versi yang didistribusikan. Jika Anda memiliki sistem yang sebanding lainnya, mungkin lebih mudah untuk membandingkannya.

Lihatlah jawaban yang diterima di rkhunter melaporkan perubahan dalam properti file, tapi saya tidak melihat bahwa mereka telah diperbarui oleh yum untuk cara memeriksa paket mana dari binari tersebut.

Tidak akan terlalu mengejutkan jika binari-binari itu berasal dari distribusi yang telah diperbarui karena ada masalah dengan biner lain yang diubah, tetapi binari yang Anda daftar dimasukkan dalam versi baru paket tidak berubah. Apakah laporan juga menunjukkan beberapa biner dimana isinya itu berubah?

— mc0e
sumber

Tidak, sebenarnya, sepertinya saya hanya pernah menerima bahwa properti file telah berubah - tidak pernah kontennya berubah.

— Nic Cottrell

-1

Saya mengkloning drive ke drive yang lebih besar dan menerima peringatan file dengan nomor inode yang berbeda. Saya menghapus rkhunter dari sistem dan menginstal ulang dan menjalankan scann lagi tanpa peringatan tentang nomor inode yang diubah

— Will Smith
sumber