Cazando al destructor de ficheros

En este artículo os voy a contar una forma de auditar el uso de un sistema Linux, en concreto para saber quién ha modificado o borrado un fichero concreto.

La historia empieza cuando un amigo nos pregunta sobre la mejor forma de auditar los accesos a una carpeta concreta de un servidor linux, ya que han desplegado una aplicación nueva que interactúa con un servidor de ficheros linux y se han encontrado con que, en servidores y carpetas diferentes, se han borrado misteriosamente algunos ficheros sin encontrarse al culpable ni el porqué del borrado misterioso de los ficheros.

Tras una búsqueda de las mejores alternativas, entre las que planteamos, por ejemplo, Tripwire o algún HIDS como OSSEC, nos encontramos con audit, un demonio específicamente diseñado para monitorizar ficheros y carpetas y registrar cualquier modificación realizada.

La instalación es trivial, y existe paquete para las distribuciones más utilizadas:

Debian y derivados: apt-get install auditd.
RHEL y derivados: yum install audit.

Tras esto debemos añadir la siguiente línea en el fichero del servicio dentro de la carpeta /etc/pam.d/ que queramos monitorizar (en nuestro caso eran accesos SSH, por lo que modificamos /etc/pam.d/sshd) para que entre en funcionamiento el demonio:

session required pam_loginuid.so

Finalmente añadimos la regla para monitorizar la ruta en cuestión:

auditctl -w /home/prueba -p w

Esto crea, en el fichero de log del demonio (/var/log/audit/audit.log), entradas por cada acción de inicio y cierre de sesión que se realiza en el sistema, además de cada acción que se realiza sobre la carpeta que hemos seleccionado:

type=LOGIN msg=audit(1348584458.716:2200): login pid=28278 uid=0 old auid=0 new auid=502 old ses=148 
   new ses=202
type=LOGIN msg=audit(1348584458.716:2201): login pid=28278 uid=0 old auid=502 new auid=502 old 
   ses=202 new ses=203
type=SYSCALL msg=audit(1348584471.100:2202): arch=c000003e syscall=83 success=yes exit=0 
   a0=7f41f39dc990 a1=1ff a2=ffffffffffffffa0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502 
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584471.100:2202):  cwd="/home/prueba"
type=PATH msg=audit(1348584471.100:2202): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584471.100:2202): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=SYSCALL msg=audit(1348584476.181:2203): arch=c000003e syscall=84 success=yes exit=0 
   a0=7f41f39dc990 a1=3 a2=ffffffffffffffb0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584476.181:2203):  cwd="/home/prueba"
type=PATH msg=audit(1348584476.181:2203): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584476.181:2203): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00

En este log podemos ver como un usuario (uid 502) inicia sesión, y posteriormente accede al directorio /home/prueba y crea, para posteriormente eliminar, la carpeta /home/prueba/aa.

La aplicación utilizada para acceder a los archivos, marcado con la etiqueta “exe”, es sftp-server, ya que la aplicación utiliza SFTP para interactuar con el sistema de archivos.

En la mayoría de supuestos tendríamos suficiente con la información aportada por auditd, ya que si, por ejemplo, realizamos una orden de tipo rm <fichero>, el campo exe contendrá el comando rm lanzado y, con la información del uid del usuario que ha realizado la acción, podríamos saber quién ha borrado dicho fichero.

En este caso no tenemos información suficiente, ya que aunque sí que sabemos que es el servidor SFTP quien ha realizado el borrado, no sabemos exactamente el comando que se ha lanzado para efectuar el borrado de ficheros en nuestra carpeta monitorizada.

Para solucionar este problema, el servidor SFTP incluido en OpenSSH a partir de la versión 4.4, publicada en septiembre de 2006, ofrece la posibilidad de añadir un registro de las acciones realizadas dentro de cada sesión SFTP (ver página del man para más información). Para activar este registro debemos modificar la siguiente línea:

Subsystem sftp /usr/lib/openssh/sftp-server

añadiendo el parámetro -l INFO, por lo que quedará:

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO

Tras reiniciar el servidor SSH, en el fichero /var/log/auth.log obtendremos, además de los registros habituales, otros como los siguientes:

Sep 25 16:52:16 lab1 sftp-server[28846]: session opened for local user user1 from [127.0.0.1]
Sep 25 16:52:23 lab1 sftp-server[28846]: sent status No such file
Sep 25 16:52:23 lab1 sftp-server[28846]: mkdir name "/home/prueba/aa" mode 0777
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: rmdir name "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"

Este extracto nos permite, por ejemplo, saber que el usuario ha accedido al directorio /home/prueba, y ha creado y posteriormente borrado el directorio aa, del mismo modo que en el ejemplo anterior.

Utilizando todo esto nuestro compañero pudo finalmente descubrir cómo se estaban realizando los borrados misteriosos de ficheros y quién era el responsable.

(N.d.E. Dado que es festivo en la Comunidad Valenciana mañana nueve de octubre, les vemos el próximo miércoles. Cuidado ahí fuera.)

Comments

  1. Buenas.

    Antes de nada genial artículo.

    He estado probando a intentar aplicarlo en plan rápido a un servidor linux al cual accede por samba a un recurso compartido en un servidor Windows.

    No sé si esta herramienta sería posible hacer este tipo de auditoría. En la web del autor no me ha parecido ver nada.

  2. Hola Alex,

    Me alegra que te guste el artículo.

    No he probado la configuración que indicas, pero si montas el recurso compartido en una ruta local entiendo que debería funcionar.

    Te invito a que nos comentes si al final consigues hacerlo funcionar.

    Gracias por tu interés ;)

    Jose.

  3. Estoy haciendo pruebas en ratos muertos metiendo una ubuntu incluso en dominio.

    A ver si hay suerte y funciona.

    :)

  4. Después de realizar más pruebas no lo permite o no se puede hacer lo que yo quería. :(

    Una pena.

  5. Buenas Alex,

    Lamentamos que no hayas podido registrar lo que querías. A ver si puedo probar algo y ya te cuento.

    Saludos y gracias por seguirnos ;)

  6. Muy buen artículo! Me ha gustado mucho la caza del destructor y esto puede tener muchas aplicaciones. Aunque tal vez los ficheros de informe puedan ser muuuuy grandes pasado un tiempo.

  7. Buenas Gaspar,

    Tienes razón, si lo dejas activo por defecto la extensión del log sería un detalle a tener en cuenta. En mi opinión sería mejor activarlo sólo en casos de necesidad.

    Me alegra que te guste el artículo. Gracias por seguirnos.

Trackbacks

  1. […] Cazando al destructor de ficheros o como auditar tu sistema para ver por qué han desaparecido algunos archivos. […]

  2. […] En este artículo os voy a contar una forma de auditar el uso de un sistema Linux, en concreto para saber quién ha modificado o borrado un fichero concreto. La historia empieza cuando un amigo nos p…  […]