La semana pasada se dio la necesidad de revisar los logs de conexiones de usuarios de un servidor Unix, específicamente un SCO Openserver 6.0, en realidad lo que estaba buscando era un log en el cual aparezca el login de los usuarios con el que se conectaron al servidor y las direcciones IP o nombres de los Host’s desde donde lo hicieron. El protocolo por medio del cual se conectan los usuarios es telnet, ya se que dirán que el protocolo telnet es poco seguro, lo se pero no está a mi alcance promover el cambio a un protocolo más seguro como sería ssh, sin embargo, en este caso me tocó ayudar en la investigación.

Como yo estoy más acostumbrado a Distribuciones GNU/Linux, encontrar todos los logs es una tarea muy simple ya que todos se encuentran en el directorio /var/log de forma muy organizado, sin embargo, los Unix tienen la particularidad de tenerlos en otros lugares, por ejemplo, algunos de los logs del Unix SCO Openserver 6.0 se pueden encontrar en /var/log (Casi siempre de servicios GNU), /var/adm, /usr/adm, etc, pues bien, hasta ahí todo tranqui, no es tanto problema acostumbrarse a otros directorios de logs.

Busqué un log que contenga información acerca de las conexiones de telnet, primeramente me puse a verificar si el archivo syslog tuviese esa información pero el servicio syslog no estuvo correctamente configurado para llevar ese tipo de control, luego, buscando en la red encontré que en el archivo wtmp y en algunos casos en el archivo wtmpx (archivo con información extendida al contenido de wtmp, no todos los Unix utilizan este archivo extendido) estaría la información que yo necesitaba y en definitiva así fue.

Estos archivos son binarios y para desplegar la información que contienen es necesario utilizar el comando last. Si ejecutamos el comando last sin pasarle ningún argumento, éste desplegará la información contenida en el archivo wtmp, en mi caso la información que alberga el Unix SCO Openserver 6.0 en el archivo wtmp no me sirvió ya que en este archivo no se guarda la dirección IP o nombre del host desde donde se produjo la conexión y es ahí donde entra a jugar el archivo wtmpx.

Para desplegar la información del archivo wtmpx necesitamos pasarle como parámetro al comando last la ubicación del archivo como por ejemplo:

Comando shell:

server# last -W /var/adm/wtmpx (En el Unix SystemV de AT&T y en GNU/Linux se utiliza el argumento -f para indicar una ruta de archivo).

La información que desplegará este comando es como sigue:
maplaya1 p3 ttyp3 3085 playa1 Sun Apr 27 05:34 13:02 ??
maplaya p2 ttyp2 3072 playa Sun Apr 27 05:32 14:27 ??
maplaya p1 ttyp1 3060 playa Sun Apr 27 05:31 14:31 ??
...

Pensando que ya tenía todo a mi disposición me encontré con una cruda realidad, el contenido de los archivos wtmp y wtmpx solo se remontaba a lo que iba de la semana en curso, no había registros de semanas ni meses anteriores, algo que me sorprendió mucho, no lo podía creer, esto me imposibilitó obtener la información que tanto necesitaba para resolver el caso, dejándome una pregunta, ¿Como puede ser que este Sistema Operativo tan famoso solo registre los acontecimientos de la semana actual?, me fije en mis servidores GNU/Linux y pude constatar que dejaban como mínimo 2 meses estos archivos antes de limpiarlos (el openSuSE mantiene mas copias de meses anteriores aún, aunque en todos los GNU/Linux esto es configurable en /etc/logrotate.conf, que es una herramienta (logrorate) que realiza copias de seguridad de archivos logs y que se instala y se ejecuta por defecto en la mayoría de los linux).

Siempre sostuve que los Unix soy muy fiables, pero así también muy toscos, cosas como estas me molestan, aunque quizás tengan sus razones, hay cosas que pudieran mejorar para facilitar y agilizar el trabajo a los administradores del SO, así que sin más remedio me puse a investigar cual era la causa de que solo mantuviera el registro de conexiones de la semana en curso, este mismo caso era visible también en otro servidor en el cual corría un Unix SystemV de AT&T.

Después de investigar un buen tiempo descubrí que hay un script llamado cleanup en el directorio /etc que limpia los archivos wtmp y wtmpx, pero lo peor es que había una tarea programada que ejecutaba este script cada domingo a las 5:17 hs. sin ni siquiera hacer una copia de seguridad antes, esto lo pude constatar estando conectado con el usuario root y ejecutando el comando crontab -l, al percatarme de este grave error en la configuración que afecta directamente la seguridad le consulté a los administradores si habían registrado esa tarea programa a lo que me respondieron que no, así que supongo que la misma se registró por defecto durante la instalación del sistema operativo, el mismo caso lo tenía el SO Unix SystemV de AT&T. Viendo esta paupérrima configuración que teníamos para nuestro contexto de seguridad, prepare un script que hace una copia de seguridad automática de los archivos wtmp y wtmpx antes de que estos sean vaciados.

Así que a tener cuidado con estos aspectos de seguridad, los registros de log son de mucha importancia y siempre se necesitan en el momento menos esperado, a veces nosotros los administradores no nos tomamos el tiempo para hacer las configuraciones pertinentes y en muchos casos ni siquiera estamos en conocimiento de como hacerlo.