Detección

La mayoría de problemas de seguridad en sistemas de I+D implican accesos no autorizados, bien por usuarios externos a la máquina o bien por usuarios internos que consiguen un privilegio mayor del que tienen asignado. >Cómo detectar estos problemas? Hacer esto puede ser algo muy complicado si el atacante es un pirata con cierta experiencia y no hemos tomado algunas medidas en nuestro sistema antes de que el ataque se produzca. Aquí se presentan unos mecanismos que pueden indicar que alguien ha accedido ilegalmente a nuestro equipo.

• Logs
  Casi cualquier actividad dentro del sistema es susceptible de ser monitorizada en mayor o menor medida. Unix ofrece un estupendo sistema de logs que guarda información en ficheros contenidos generalmente en /var/adm/, /var/log/ o /usr/adm/; esta información varía desde los usuarios que han conectado al sistema últimamente hasta los mensajes de error del núcleo, y puede ser consultada con órdenes como who o last, o con un simple editor de textos.
  Aunque un atacante que consiga privilegios de root en el equipo puede modificar (<o borrar!) estos archivos^A.3, los logs son con frecuencia el primer indicador de un acceso no autorizado o de un intento del mismo. Dependiendo de nuestra configuración (/etc/syslog.conf), pero generalmente en los archivos messages o syslog, podemos ver mensajes que pueden indicar un ataque al sistema; a continuación se presentan algunos de ellos:
  • Nov 12 05:35:42 anita in.telnetd[516]: refused connect from bg.microsoft.com
    Este mensaje (conexión rehusada a un servicio) en sistemas con TCP-Wrappers instalado indica que alguien ha intentado conectar a nuestro equipo desde una máquina no autorizada a hacerlo.
  • Nov 7 23:06:22 anita in.telnetd[2557]: connect from localhost
    Alguien ha conectado con éxito a nuestro equipo desde una determinada máquina; no implica que haya accedido con una nombre de usuario y su contraseña, simplemente que ha tenido posibilidad de hacerlo.
  • SU 11/17 03:12 - pts/3 toni-root
    El usuario toni ha intentado conseguir privilegios de administrador mediante la orden su; si lo hubiera conseguido, en lugar de un signo `-' aparecería un `+'. En Solaris, esto se registra en el fichero sulog, aunque en el fichero messages se notifica si el su ha fallado.
• Procesos
  Si un atacante ha conseguido acceso a nuestro equipo, y dependiendo de sus intenciones, es probable que ejecute programas en el sistema que permanecen en la tabla de procesos durante un largo periodo de tiempo; típicos ejemplos son sniffers (programas para capturar tráfico de red) o bouncers (programas para ocultar una dirección en IRC). Debemos desconfiar de procesos que presenten un tiempo de ejecución elevado, especialmente si no es lo habitual en nuestro sistema. Incluso si el nombre del proceso no es nada extraño (obviamente un pirata no va a llamar a su analizador de tráfico sniffer, sino que le dará un nombre que no levante sospechas, como xzip o ltelnet) es muy conveniente que nos preocupemos de comprobar cuál es el programa que se está ejecutando.
  Algo que nos puede ayudar mucho en esta tarea es la herramienta de seguridad lsof, que nos indica los ficheros abiertos por cada proceso de nuestro sistema, ya que programas como los sniffers o los crackers de claves suelen mantener archivos abiertos para almacenar la información generada.
• Sistemas de ficheros
  Otro punto que puede denotar actividades sospechosas en la máquina es su sistema de ficheros:
  Por un lado, hemos de estar atentos al número de archivos setuidados en el sistema: es frecuente que un pirata que ha conseguido privilegios de root guarde archivos con este bit activo para volver a conseguir esos privilegios de una forma más sencilla (por ejemplo, una copia de un shell setuidado como root dará privilegios de administrador a cualquiera que lo ejecute).
  Además, los intrusos suelen crear directorios `difíciles' de localizar, donde poder guardar herramientas de ataque: por ejemplo, si alguien es capaz de crear el directorio /dev/.../, seguramente cuando el administrador haga un listado de /dev/ ni se dará cuenta de la existencia de un directorio con un nombre tan poco común como `...'.
  Otra actividad relacionada con el sistema de ficheros es la sustitución de ciertos programas que puedan delatar una presencia extraña, como ps, who o last, o programas críticos como /bin/login por versiones `troyanizadas' que no muestren nada relacionado con el atacante; por ejemplo, alguien podría sustituir el programa /bin/login por otro que aparentemente se comporte igual, pero que al recibir un nombre de usuario concreto otorgue acceso al sistema sin necesidad de clave. Un ejemplo muy simple de este tipo de troyanos es el siguiente: alguien mueve el archivo /bin/ps a /bin/OLDps y a continuación ejecuta

  anita:~# cat >/bin/ps
  #!/bin/sh
  /bin/OLDps $1|grep -v '^    toni'|grep -v grep|grep -v OLD
  ^D
  anita:~#
  

  A partir de ahora, cuando alguien teclee ps -ef no verá los procesos del usuario toni. Se puede seguir un mecanismo similar^A.4 con programas como w, finger, last, who o ls para conseguir ocultar a un usuario conectado, sus procesos, sus ficheros...
  Otro síntoma que denota la presencia de un problema de seguridad puede ser la modificación de ciertos ficheros importantes del sistema; por ejemplo, un atacante puede modificar /etc/syslog.conf para que no se registren ciertos mensajes en los archivos de log, o /etc/exports para exportar directorios de nuestro equipo. El problema de este estilo más frecuente es la generación de nuevas entradas en el fichero de claves con UID 0 (lo que implica un total privilegio); para detectar este tipo de entradas, se puede utilizar la siguiente orden:

  anita:~# awk -F: '$3=="0" {print $1}' /etc/passwd
  root
  anita:~#
  

  Obviamente, si como salida de la orden anterior obtenemos algún otro nombre de usuario, aparte del root, sería conveniente cancelar la cuenta de ese usuario e investigar por qué aparece con UID 0.
  Detectar este tipo de problemas con el sistema de ficheros de nuestro equipo puede ser una tarea complicada; la solución más rápida pasa por instalar Tripwire, comentado en este mismo punto.
• Directorios de usuarios
  Dentro del sistema de ficheros existen unos directorios especialmente conflictivos: se trata de los $HOME de los usuarios. La conflictividad de estos directorios radica principalmente en que es la zona más importante del sistema de archivos donde los usuarios van a tener permiso de escritura, por lo que su control (por ejemplo, utilizando Tripwire) es a priori más difícil que el de directorios cuyo contenido no cambie tan frecuentemente. Algunos elementos dentro de estos directorios que pueden denotar una intrusión son los siguientes:
  • Hemos de chequear el grupo y propietario de cada archivo para comprobar que no pertenecen a usuarios privilegiados en lugar de a usuarios normales, o a grupos especiales en lugar de a grupos genéricos (users, staff...). Por ejemplo, si el padre de los directorios de usuario es /export/home/, podemos buscar dentro de él ficheros que pertenezcan al administrador con la orden

    anita:~# find /export/home/ -user root -type f -print
    

  • >Hay archivos setuidados o setgidados en los directorios de usuario? No debería, por lo que su existencia es algo bastante sospechoso...
  • La existencia de código fuente, generalmente C, de exploits (programas que aprovechan un fallo de seguridad en el software para utilizarlo en beneficio del atacante) puede ser indicativo de una contraseña robada, o de un usuario intentando conseguir un privilegio mayor en el sistema. >Cómo saber si un código es un exploit o una práctica de un alumno? La respuesta es obvia: leyéndolo. >Y si se trata de ficheros ejecutables en lugar de código fuente? man strings.
• El sistema de red
  Estar atentos al sistema de red de nuestro equipo también nos puede proporcionar indicios de accesos no autorizados o de otro tipo de ataques contra el sistema. Por ejemplo, si utilizamos netstat para comprobar las conexiones activas, y detectamos una entrada similar a

  anita.telnet         luisa.2039           16060      0 10136      0 ESTABLISHED
  

  esto indica que desde el host luisa alguien está conectado a nuestro sistema mediante telnet; puede haber accedido o no (si ha tecleado un nombre de usuario y la contraseña correcta), pero el hecho es que la conexión está establecida.
  Otro método muy seguido por los piratas es asegurar la reentrada al sistema en caso de ser descubiertos, por ejemplo instalando un programa que espere conexiones en un cierto puerto y que proporcione un shell sin necesidad de login y password (o con los mismos predeterminados); por ejemplo, si el programa espera peticiones en el puerto 99, el atacante puede acceder al sistema con un simple telnet:

  luisa:~# telnet anita 99
  Trying 192.168.0.3...
  Connected to anita.
  Escape character is '^]'.
  Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
  anita:~#
  

  Podemos detectar los puertos que esperan una conexión en nuestro sistema también con la orden netstat:

  anita:~# netstat -P tcp -f inet -a|grep LISTEN
        *.sunrpc             *.*                0      0     0      0 LISTEN
        *.32771              *.*                0      0     0      0 LISTEN
        *.ftp                *.*                0      0     0      0 LISTEN
        *.telnet             *.*                0      0     0      0 LISTEN
        *.finger             *.*                0      0     0      0 LISTEN
        *.dtspc              *.*                0      0     0      0 LISTEN
        *.lockd              *.*                0      0     0      0 LISTEN
        *.smtp               *.*                0      0     0      0 LISTEN
        *.8888               *.*                0      0     0      0 LISTEN
        *.32772              *.*                0      0     0      0 LISTEN
        *.32773              *.*                0      0     0      0 LISTEN
        *.32774              *.*                0      0     0      0 LISTEN
        *.printer            *.*                0      0     0      0 LISTEN
        *.listen             *.*                0      0     0      0 LISTEN
        *.6000               *.*                0      0     0      0 LISTEN
        *.32775              *.*                0      0     0      0 LISTEN
  anita:~#
  

• Tripwire
  Quizás una de las formas más efectivas de detectar accesos no autorizados es mediante el programa Tripwire. La idea es sencilla: en un sistema `limpio' (por ejemplo, recién instalado, antes de ser conectado a red) se aplica una función de resumen (message digest) sobre los ficheros importantes del equipo, (por ejemplo, ficheros en /etc/, /bin/ o /sbin/). Los resultados de este proceso se almacenan en un medio que a partir de ese momento será de sólo lectura, como un disco flexible protegido contra escritura o un CD-ROM, y periódicamente volvemos a aplicar el resumen sobre los ficheros de nuestro equipo; si se detecta un cambio (por ejemplo, una variación en el tamaño, un cambio de propietario, la desaparición de un archivo...), Tripwire nos lo va a indicar. Si no lo hemos realizado nosotros, como administradores, es posible (muy posible) que ese fichero haya sido modificado en beneficio propio por un intruso.