rkhunter advierte sobre el cambio de inodo pero no cambia la fecha de modificación del archivo

8

Tengo varios sistemas que ejecutan Centos 6 con rkhunter instalado. Tengo un cron todos los días ejecutando rkhunter e informando por correo electrónico.

Muy a menudo recibo informes como:

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

Por lo que entiendo, rkhunter generalmente informará un cambio de fecha de modificación o hash en los archivos escaneados, por lo que esto me lleva a pensar que no hay un cambio real.

Mi pregunta: ¿hay alguna otra actividad en la máquina que pueda hacer el cambio de inodo (ejecutando ext4) o esto realmente está yumhaciendo cambios regulares (~ una vez por semana) a estos archivos como parte de las actualizaciones de seguridad normales?

centos yum rkhunter

— Nic Cottrell
fuente

8

La actualización de archivos a menudo se realiza escribiendo un nuevo archivo en el mismo directorio seguido de cambiar el nombre del archivo en la parte superior del archivo anterior. Este método generalmente se aplica a todo lo instalado a través de un administrador de paquetes, pero también a cualquier actualización realizada en ejecutables y bibliotecas, incluso si se actualiza por otros motivos.

Esta forma de actualizar los archivos garantiza que cualquier proceso que abra el archivo obtendrá el antiguo o el nuevo, y no verá nada que cambie en el archivo, que han abierto. Significa que cada vez que se actualiza, en realidad tendrá un nuevo archivo con el mismo nombre, por lo tanto, el número de inodo ha cambiado.

Supongo que esta es la razón por la que esos archivos tienen un nuevo número de inodo.

Una actualización de seguridad podría ser una razón. Pero hay otra posibilidad, que observé por primera vez en Fedora Core 1, y que bien podría haber llegado a Centos en algún momento.

Los archivos ejecutables y las bibliotecas se están vinculando previamente para que puedan comenzar más rápido y usar menos memoria. Durante este proceso, la dirección de carga se aleatoriza para hacer que la explotación de las vulnerabilidades de seguridad sea un poco más difícil. Un trabajo cron repetiría periódicamente el proceso con nuevas direcciones aleatorias, lo que haría que todos los archivos ejecutables y bibliotecas vinculados previamente se actualizaran.

— kasperd
fuente

2

Sí, la vinculación previa parece la explicación más probable aquí.

— Michael Hampton

Sin embargo, ¿hay una buena manera de manejar esto? Si solo tengo un cron para ejecutar, rkhunter --propupdentonces podría perder un truco e invalidar todo el punto de rkhunter, ¿verdad?

— Nic Cottrell

1

@NicholasTolleyCottrell lo rpmmaneja verificando primero la integridad del prelinkejecutable, luego llama al prelinkejecutable con argumentos para revertir la vinculación previa con la entrada de un ejecutable vinculado previamente y la salida a stdout. Luego rpmpuede verificar la integridad de esa salida. No tengo idea si ese enfoque puede aplicarse rkhunter.

— kasperd

1

Vea este hilo para saber cómo obtener una suma de verificación que no salte: linuxquestions.org/questions/linux-security-4/… . Me he alejado de rkhunter como una herramienta basada en cron. Tiene muchas comprobaciones útiles, pero la incapacidad de desactivar las comprobaciones que equivalen a falsos positivos lo hace casi inútil para llamar su atención hacia donde es necesario, ya que me acostumbro a ignorar sus informes enviados por correo electrónico. Todavía lo encuentro ocasionalmente útil como herramienta de ejecución manual.

— mc0e 01 de

2

La otra opción que encontré fue deshabilitar estas pruebas de propiedades por completo. Si edita /etc/rkhunter.confy busca la DISABLE_TESTSlínea y la cambia a:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

La propertiesprueba es la que verifica y devuelve falsos positivos en los hashes del archivo.

— Nic Cottrell
fuente

1

Un número de inodo modificado generalmente significa que el archivo ha sido reemplazado. Como puede decir, podría deberse a una actualización esperada. Verificaría que los md5sums de esos archivos coinciden con los de las versiones distribuidas. Si tiene otro sistema comparable, puede ser más fácil compararlo.

Eche un vistazo a la respuesta aceptada en rkhunter informa el cambio en las propiedades del archivo, pero no veo que hayan sido actualizadas por yum para saber de qué paquete provienen esos binarios.

No sería demasiado sorprendente si esos archivos binarios fueran de una distribución que se actualizó debido a un problema con otro binario que se modificó, pero los archivos binarios que usted enumeró se incluyeron en la nueva versión del paquete sin cambios. ¿Su informe también mostró algún binario donde se cambió el contenido ?

— mc0e
fuente

No, en realidad, parece que solo he recibido que las propiedades del archivo han cambiado, nunca que los contenidos hayan cambiado.

— Nic Cottrell

-1

Cloné una unidad en una unidad más grande y recibí las advertencias de archivos con diferentes números de inodes. Eliminé rkhunter del sistema y volví a instalarlo y ejecuté el escaneo nuevamente sin advertencias sobre el cambio de los números de inodes

— Will Smith
fuente