rkhunter cảnh báo thay đổi inode nhưng không thay đổi ngày sửa đổi tập tin

Tôi có một số hệ thống chạy Centos 6 với cài đặt rkhunter. Tôi có một cron hàng ngày chạy rkhunter và báo cáo lại qua email.

Tôi rất thường nhận được các báo cáo như:

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

Theo những gì tôi hiểu, rkhunter thường sẽ báo cáo băm thay đổi và / hoặc ngày sửa đổi trên các tệp được quét, do đó, điều này khiến tôi nghĩ rằng không có thay đổi thực sự.

Câu hỏi của tôi: có một số hoạt động khác trên máy có thể làm thay đổi inode (chạy ext4) hay điều này thực sự yumtạo ra thay đổi thường xuyên (~ một lần một tuần) cho các tệp này như một phần của các cập nhật bảo mật thông thường?

Việc cập nhật tệp thường được thực hiện bằng cách viết một tệp mới trong cùng thư mục, sau đó đổi tên tệp ở trên cùng của tệp cũ. Phương pháp này thường được áp dụng cho mọi thứ được cài đặt thông qua trình quản lý gói, nhưng cũng áp dụng cho mọi cập nhật được thực hiện cho các tệp thực thi và thư viện ngay cả khi được cập nhật vì các lý do khác.

Cách cập nhật tệp này đảm bảo rằng mọi quá trình mở tệp sẽ nhận được cũ hoặc mới và không thấy bất kỳ thay đổi nào trong tệp mà chúng đã mở. Điều đó có nghĩa là mỗi lần cập nhật, bạn thực sự sẽ có một tệp mới có cùng tên, do đó số inode đã thay đổi.

Tôi đoán đây là lý do cho những tập tin có số inode mới.

Một bản cập nhật bảo mật có thể là một lý do. Nhưng có một khả năng khác, lần đầu tiên tôi quan sát thấy trên Fedora Core 1, và điều đó rất có thể đã biến nó thành Centos vào một lúc nào đó.

Các thư viện và thư viện đang được xem trước để có thể bắt đầu nhanh hơn và sử dụng ít bộ nhớ hơn. Trong quá trình này, địa chỉ tải được chọn ngẫu nhiên để khai thác các lỗ hổng bảo mật khó hơn một chút. Một công việc định kỳ sẽ lặp lại định kỳ quy trình với các địa chỉ ngẫu nhiên mới khiến tất cả các thư viện và thư viện được thực hiện trước được cập nhật.

Tùy chọn khác tôi tìm thấy là vô hiệu hóa hoàn toàn các kiểm tra thuộc tính này. Nếu bạn chỉnh sửa /etc/rkhunter.confvà tìm kiếm DISABLE_TESTSdòng và thay đổi nó thành:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

Các propertiesthử nghiệm là một kiểm tra và gửi lại dương tính giả trên băm tập tin.

Số inode thay đổi thường có nghĩa là tệp đã được thay thế. Nó có thể như bạn nói là do một bản cập nhật dự kiến. Tôi sẽ xác minh md5sums của các tệp đó khớp với các phiên bản được phân phối. Nếu bạn có một hệ thống tương đương khác xung quanh, có thể dễ dàng so sánh với hệ thống đó.

Hãy xem câu trả lời được chấp nhận tại các báo cáo của rkhunter thay đổi thuộc tính tệp, nhưng tôi không thấy rằng chúng đã được cập nhật bởi yum để biết cách kiểm tra các gói nhị phân đó đến từ đâu.

Sẽ không quá ngạc nhiên nếu những nhị phân đó là từ một bản phân phối đã được cập nhật do sự cố với một nhị phân khác đã bị thay đổi, nhưng các nhị phân mà bạn liệt kê được bao gồm trong phiên bản mới của gói không thay đổi. Có phải báo cáo của bạn cũng hiển thị một số nhị phân nơi nội dung đã được thay đổi?

Tôi đã nhân bản một ổ đĩa sang một ổ đĩa lớn hơn và nhận được các cảnh báo về các tệp có số lượng inodes khác nhau. Tôi đã gỡ rkhunter khỏi hệ thống và cài đặt lại và chạy lại scann mà không có cảnh báo nào liên quan đến số inodes bị thay đổi