Archivos que desaparecen en el servidor Linux

Tengo 4 archivos específicos que parecen seguir desapareciendo del directorio de inicio de un usuario. Hasta donde sabemos, no hay cronjobs u otras tareas automatizadas que los eliminen. He configurado la auditoría en ellos, pero los registros realmente no muestran nada de interés. Puedo ver nuestra utilidad de respaldo accediendo a ellas todas las noches hasta el punto en que ya no están allí, pero nada más. ¿Hay algo que estaría causando la eliminación de esos archivos que podrían ser auditados?

Los archivos en cuestión son estos:

/home/username/.bashrc
/home/username/.bash_profile

así como un par de archivos en el directorio .ssh de ese usuario. Las copias de estos archivos colocados en una subcarpeta llamada "guardianes" también se eliminan al mismo tiempo. Cambiar los permisos sobre ellos a 000 y tenerlos propiedad de root no ha ayudado.

Actualmente tengo la configuración de inotifywait para registrar crear, eliminar, mover esa subcarpeta, así que espero que aparezca algo, aunque no registra mucho aparte de cuando sucedió, no lo que lo causó.

Solución 1 : systemtap
Puede usar systemtap para mostrar todos los PID que intentan usar unlink () en el inodo de .bashrcy .bash_profilearchivos.

Instale systemtap y los símbolos de depuración para su núcleo.

Cree un archivo con nombre unlink.stapcon el siguiente contenido:

probe syscall.unlink
{
    printf ("%s(%d) unlink (%s) userID(%d)\n", execname(), pid(), argstr, uid())
}

Luego ejecútalo con sudo stap unlink.stap

Solución 2 : inotify
También puede usar inotify para ver cuándo se elimina el archivo.

Solución 3 : ftrace
Otra solución es usar ftrace :

trace-cmd record -e \*unlink\*

Espere a que se elimine el archivo, presione CTRL + C para detener trace-cmd record ..., luego ejecute:

trace-cmd report

Solución 4 : bpftrace
Instalar bpftrace, luego ejecute:

bpftrace -e 'tracepoint:syscalls:sys_enter_unlink* { printf("%s %s\n", comm, str(args->pathname)); }'

Además de la respuesta de micea, puede chatear + i los archivos como root y ver si algo registra un error al intentar eliminarlos.

¿Estás absolutamente seguro de que el usuario mismo no los está eliminando (accidentalmente)?

Tuve algunos usuarios despistados (Windows) con el mismo problema. Resultó que ellos mismos borraron esos archivos cada vez que visitaron su directorio de inicio con un cliente ftp. Notaron los archivos .xxxx (el cliente ftp no los ocultó) y eliminaron el "desorden".

Nunca se me ocurrió que se lo hicieran a sí mismos hasta que uno de ellos se quejó de la reaparición espontánea de archivos que había eliminado varios días antes.

Utilizamos scripts de cierre de sesión de bash (~ / .bash_logout) para limpiar ciertos archivos al cerrar sesión; puede verificar si tiene esa configuración, tal vez con un globo engorroso.

More parece un intruso, que está haciendo un find / home / user -name nombrearchivo -exec rm -f {} \; después de todo su furtividad :). Solo adivinando, porque mencionaste que los archivos de copia de seguridad también se están eliminando.

Para evitar perder los archivos y su contenido, puede configurar libtrash a través de LD_PRELOAD. Usando libtrash puedes hacer varias cosas, pero las que pueden ser interesantes para ti son

INTERCEPT_UNLINK
INTERCEPT_RENAME
INTERCEPT_FOPEN
INTERCEPT_OPEN

Un buen artículo sobre libtrash se puede encontrar aquí

Otra cosa que mencionas es que elegiste archivos para rootearlos y aún así se eliminaron. Es porque / home / username es propiedad de username; y si dir tiene mod 755; entonces cualquier archivo o directorio en ese directorio propiedad de no importa quién puede ser eliminado por el usuario; incluso si es un archivo raíz o dir. Básicamente se debe al hecho de que eliminar el archivo en el directorio significa cambiar el contenido del directorio y el usuario tiene 7 (en 755) de ese directorio para que pueda hacer lo que quiera.

Hay formas de bloquear esto ya que otras personas ya sugirieron a través de chattr en sistemas de archivos ext para configurar archivos como inmutables (+ i). Entonces uno necesitaría desactivar la marca inmutable antes de hacer cualquier cambio en el archivo / directorio que tiene la marca + i. La bandera / chat inmutable solo puede ser utilizada por root.