Tux, the Linux penguin

Tux, the Linux penguin (Photo credit: Wikipedia)

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  esto se  pudo finalmente descubrir cómo se estaban realizando los borrados misteriosos de ficheros y quién era el responsable