Seguridad en Unix y Redes
Libro en Formato HTML y PDF de seguridad informática realizado por Antonio Villalon Huerta

Los contenidos pueden estar desactualizados con respecto al original

Este documento se encuentra disponible también en formato PDF

Seguridad básica para administradores


next up previous contents
Siguiente: Normativa Subir: Apéndices Anterior: Apéndices   Índice General

Subsecciones

Seguridad básica para administradores

Introducción

Lamentablemente, muchos administradores de equipos Unix no disponen de los conocimientos, del tiempo, o simplemente del interés necesario para conseguir sistemas mínimamente fiables. A raíz de esto, las máquinas Unix se convierten en una puerta abierta a cualquier ataque, poniendo en peligro no sólo la integridad del equipo, sino de toda su subred y a la larga de toda Internet.

Aunque esta situación se da en cualquier tipo de organización, es en las dedicadas a I+D donde se encuentran los casos más extremos; se trata de redes y equipos Unix muy abiertos y con un elevado número de usuarios (incluidos externos al perímetro físico de la organización) que precisan de una gran disponibilidad de los datos, primando este aspecto de la información ante otros como la integridad o la privacidad. Esto convierte a los sistemas Unix de centros de I+D, especialmente de universidades, en un objetivo demasiado fácil incluso para los piratas menos experimentados.

Con el objetivo de subsanar esta situación, aquí se van a intentar marcar unas pautas para conseguir un nivel mínimo de fiabilidad en los equipos Unix. No se va a entrar en detalles muy técnicos o en desarrollos teóricos sobre seguridad que muy pocos van a leer (para eso está el resto de este proyecto), sino que la idea es únicamente explicar los pasos básicos para que incluso los administradores menos preocupados por la seguridad puedan aplicarlos en sus sistemas. A modo de ilustración, hay pequeños ejemplos que han sido realizados sobre una plataforma Solaris 7 (SunOS 5.7); en otros clones de Unix quizás sea necesario modificar las opciones de algún comando o la localización de ciertos ficheros.

Hay que recalcar que se trata de mecanismos básicos de seguridad, que pueden evitar la acción de algunos piratas casuales (si nuestra máquina ofrece una mínima protección abandonarán el ataque para dedicarse a equipos menos protegidos) pero no de un atacante con cierta experiencia. Lo ideal sería que las pautas marcadas aquí se complementaran con todas las medidas de seguridad posibles, y que entre los libros habituales de un administrador se encontraran títulos sobre seguridad en Unix; uno especialmente recomendado es Practical Unix & Internet Security, de Simson Garfinkel y Gene Spafford (Ed. O´Reilly and Associates, 1996). También es muy recomendable que la persona encargada de la seguridad de cada equipo permanezca atenta a los nuevos problemas que cada día surgen; una buena forma de conseguirlo es mediante listas de correo como BUGTRAQ.

Prevención

Los mecanismos de prevención han de ser los más importantes para cualquier administrador, ya que obviamente es mucho mejor evitar un ataque que detectar ese mismo problema o tener que recuperar al sistema tras detectarlo.
  • Cierre de servicios ofrecidos por inetd
    Cada servicio ofrecido en nuestro sistema se convierte en una potencial puerta de acceso al mismo, por lo que hemos de minimizar su número: se recomienda cerrar cualquier servicio que no se vaya a utilizar, y todos aquellos de los que no conozcamos su utilidad (si más tarde son necesarios, los podemos volver a abrir).
    Para cerrar un servicio ofrecido desde inetd, en el fichero /etc/inetd.conf debemos comentar la línea correspondiente a ese servicio, de forma que una entrada como 
    telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd
    se convierta en una como 
    #telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd
    Tras efectuar esta operación, debemos reiniciar el demonio inetd para que relea su configuración; esto lo conseguimos, por ejemplo, con la orden
    anita:/# pkill -HUP inetd
    o, si no disponemos de un comando para enviar señales a procesos a partir de su nombre, con la orden
    anita:/# kill -HUP `ps -ef|grep -w inetd|awk '{print $2}'`
  • Cierre de servicios ofrecidos en el arranque de máquina
    Existen una serie de demonios que ofrecen ciertos servicios, como sendmail, que no se procesan a través de inetd sino que se lanzan como procesos independientes al arrancar la máquina. Para detener este tipo de demonios hemos de comentar las líneas de nuestros ficheros de arranque encargadas de lanzarlos (generalmente en directorios como /etc/rc?.d/ o /etc/rc.d/): de esta forma conseguimos que la próxima vez que el sistema se inicie, los demonios no se ejecuten. Aparte de esto, hemos de detener los demonios en la sesión actual, ya que en estos momentos seguramente están funcionando; para ello les enviamos la señal SIGKILL mediante el comando kill.
    Por ejemplo, en el caso de Solaris, sendmail se lanza desde el archivo
    /etc/rc2.d/S88sendmail; en este fichero tendremos unas líneas similares a estas:
    if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then
   if [ ! -d /var/spool/mqueue ]; then
      /usr/bin/mkdir -m 0750 /var/spool/mqueue
      /usr/bin/chown root:bin /var/spool/mqueue
   fi
   /usr/lib/sendmail -bd -q15m &
fi
    Podemos renombrar este archivo como disabled.S88sendmail o comentar estas líneas de la forma siguiente:
    #if [ -f /usr/lib/sendmail -a -f /etc/mail/sendmail.cf ]; then
#   if [ ! -d /var/spool/mqueue ]; then
#      /usr/bin/mkdir -m 0750 /var/spool/mqueue
#      /usr/bin/chown root:bin /var/spool/mqueue
#   fi
#   /usr/lib/sendmail -bd -q15m &
#fi
    Y a continuación eliminaremos el proceso sendmail enviándole la señal SIGKILL:
    anita:/# ps -ef |grep sendmail
root   215     1  0 01:00:38 ?        0:00 /usr/lib/sendmail -bd -q15m
anita:/# kill -9 215
  • Instalación de wrappers
    A pesar de haber cerrado muchos servicios siguiendo los puntos anteriores, existen algunos que no podremos dejar de ofrecer, como telnet o ftp, ya que los usuarios van a necesitar conectar al sistema de forma remota o transferir ficheros. En estos casos es muy conveniente instalar wrappers para los demonios que sigan recibiendo conexiones; mediante el uso de estos programas vamos a poder restringir los lugares desde los que nuestro equipo va a aceptar peticiones de servicio. Especialmente recomendable es el programa TCP-Wrapper para controlar las conexiones servidas por inetd (incluso sendmail se puede controlar por inetd, lo cual es muy útil si queremos restringir los lugares desde los que nos pueda llegar correo).
    Por ejemplo, si no utilizamos wrappers para controlar el servicio de telnet, cualquier máquina de Internet puede intentar el acceso a nuestro sistema:
    luisa:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is '^]'.

SunOS 5.7

login:
    Sin embargo, configurando TCP-Wrapper para que no admita conexiones desde fuera de la universidad, si alguien intenta lo mismo obtendrá un resultado similar al siguiente:
    luisa:~$ telnet anita
Trying 192.168.0.3...
Connected to anita.
Escape character is '^]'.
Connection closed by foreign host.
luisa:~$
    De esta forma, incluso si el atacante conociera un nombre de usuario y su clave le sería más difícil acceder a nuestro equipo por telnet.
  • Ficheros setuidados y setgidados
    En un sistema Unix recién instalado podemos tener incluso más de cincuenta ficheros con los modos setuid o setgid activados; cualquiera de estos programas representa un potencial agujero a la seguridad de nuestro sistema, y aunque muchos son necesarios (como /bin/passwd en la mayoría de situaciones), de otros se puede prescindir. Para localizar los ficheros setuidados podemos utilizar la orden
    anita:/# find / -perm -4000 -type f -print
    mientras que para localizar los setgidados podemos utilizar 
    anita:/# find / -perm -2000 -type f -print
    Es conveniente que reduzcamos al mínimo el número de estos archivos, pero tampoco se recomienda borrarlos del sistema de ficheros; es mucho más habitual resetear el bit de setuid o setgid, y en caso de que sea necesario volverlo a activar. Para desactivar estos bits podemos usar la orden chmod -s, mientras que para activarlos utilizaremos chmod u+s o chmod g+s.
    Por ejemplo, si el fichero /usr/lib/fs/ufs/ufsdump está setuidado, un listado largo del mismo nos mostrará una s en el campo de ejecución para propietario, mientras que si está setgidado aparecerá una s en el campo de ejecución para grupo; podemos resetear los dos bits con la orden vista anteriormente:
    anita:/# ls -l /usr/lib/fs/ufs/ufsdump
-r-sr-sr-x  1 root  tty   144608 Oct 6 1998 /usr/lib/fs/ufs/ufsdump
anita:/# chmod -s /usr/lib/fs/ufs/ufsdump
anita:/# ls -l /usr/lib/fs/ufs/ufsdump
-r-xr-xr-x  1 root  tty   144608 Oct 6 1998 /usr/lib/fs/ufs/ufsdump
  • Cifrado de datos
    El principal problema de las claves viajando en texto claro por la red es que cualquier atacante puede leerlas: si usamos telnet, rlogin o ftp, cualquier persona situada entre nuestra estación de trabajo y el servidor al que conectamos puede `esnifar' los paquetes que circulan por la red y obtener así nuestro nombre de usuario y nuestro password. Para evitar este problema es conveniente utilizar software que implemente protocolos cifrados para conectar; el más habitual hoy en día es SSH (Secure Shell). Por una parte, tenemos el programa servidor sshd, que se ha de instalar en el equipo al que conectamos, y por otra programas clientes (ssh para sustituir a rsh/rlogin y scp para sustituir a rcp).
    Una vez instalado, este software es transparente al usuario: simplemente ha de recordar su clave, igual que si conectara por telnet o rlogin.
  • Relaciones de confianza
    En el fichero /etc/hosts.equiv se indican, una en cada línea, las máquinas confiables. >Qué significa confiables? Básicamente que confiamos en su seguridad tanto como en la nuestra, por lo que para facilitar la compartición de recursos, no se van a pedir contraseñas a los usuarios que quieran conectar desde estas máquinas con el mismo login, utilizando las órdenes BSD r (rlogin, rsh, rcp...). Por ejemplo, si en el fichero /etc/hosts.equiv del servidor anita hay una entrada para el nombre de host luisa, cualquier usuarioA.1 de este sistema puede ejecutar una orden como la siguiente para conectar a anita <sin necesidad de ninguna clave!:
    luisa:~$ rlogin anita
Last login: Sun Oct 31 08:27:54 from localhost
Sun Microsystems Inc.   SunOS 5.7       Generic October 1998
anita:~$
    Obviamente, esto supone un gran problema de seguridad, por lo que lo más recomendable es que el fichero /etc/hosts.equiv esté vacío o no exista. De la misma forma, los usuarios pueden crear ficheros $HOME/.rhosts para establecer un mecanismo de confiabilidad bastante similar al de /etc/hosts.equiv; es importante para la seguridad de nuestro sistema el controlar la existencia y el contenido de estos archivos .rhosts. Por ejemplo, podemos aprovechar las facilidades de planificación de tareas de Unix para, cada cierto tiempo, chequear los directorios $HOME de los usuarios en busca de estos ficheros, eliminándolos si los encontramos. Un shellscript que hace esto puede ser el siguiente:
    #!/bin/sh
for i in `cat /etc/passwd |awk -F: '{print $6}'`; do
    cd $i
    if [ -f .rhosts ]; then
        echo "$i/.rhosts detectado"|mail -s "rhosts" root
        rm -f $i/.rhosts
    fi
done
    Este programa envía un correo al root en caso de encontrar un fichero .rhosts, y lo elimina; podemos planificarlo mediante cron para que se ejecute, por ejemplo, cada cinco minutos. La forma de planificarlo depende del clon de Unix en el que trabajemos, por lo que se recomienda consultar la página del manual de cron o crond; en el caso de Solaris, para que se ejecute cada vez que cron despierte, y suponiendo que el script se llame /usr/local/sbin/busca, pondríamos en nuestro crontab (con crontab -e) una línea como
    * * * * *      /usr/local/sbin/busca 2>&1 >/dev/null
    Hemos de estar atentos a la carga que este tipo de actividades periódicas puede introducir en el sistema; la orden anterior se va a ejecutar cada vez que cron despierta, generalmente una vez por minuto, lo que implica que en máquinas con un gran número de usuarios puede introducir un factor importante de operaciones de I/O. Una solución más adecuada en estas situaciones sería planificar el programa para que se ejecute cada cinco o diez minutos, o el tiempo que estimemos necesario en nuestro equipo.
  • Política de cuentas
    Muchos clones de Unix se instalan con cuentas consideradas `del sistema', es decir, que no corresponden a ningún usuario concreto sino que existen por cuestiones de compatibilidad o para la correcta ejecución de algunos programas. Algunas de estas cuentas no tienen contraseña, o tienen una conocida por todo el mundo, por lo que representan una grave amenaza a la seguridad: hemos de deshabilitarlas para evitar que alguien pueda conectar a nuestro equipo mediante ellas. Algunos ejemplos de este tipo de cuentas son guest, demo, uucp, games, 4DGifts o lp.
    Para deshabilitar una cuenta, en Unix no tenemos más que insertar un asterisco en el campo passwd en la línea correspondiente del fichero de claves (generalmente /etc/passwd o
    /etc/shadow). De esta forma, una entrada como 
    toni:7atzxSJlPVVaQ:1001:10:Toni Villalon:/export/home/toni:/bin/sh
    pasaría a convertirse en 
    toni:*7atzxSJlPVVaQ:1001:10:Toni Villalon:/export/home/toni:/bin/sh
    Aparte de este tipo de cuentas, hemos de tener un especial cuidado con las cuentas de usuario que no tienen contraseña o que tienen una clave débil; para detectar este último problema podemos utilizar programas adivinadores como Crack, mientras que para evitarlo podemos utilizar NPasswd o Passwd+, además de sistemas Shadow Password para que los usuarios no puedan leer las claves cifradas. Para detectar cuentas sin contraseña (aunque también Crack nos las indicará), podemos utilizar la siguiente orden, obviamente sustituyendo /etc/passwd por el fichero de claves de nuestro sistema:
    anita:~# awk -F: '$2=="" {print $1}' /etc/passwd
    Por último, hay que decir que una correcta política de cuentas pasa por deshabilitar la entrada de usuarios que no utilicen el sistema en un tiempo prudencial; por ejemplo, podemos cancelar las cuentas de usuarios que no hayan conectado a la máquina en los últimos dos meses, ya que son firmes candidatas a que un pirata las aproveche para atacarnos; la orden finger nos puede ayudar a detectar este tipo de usuarios.
  • Negaciones de servicio
    Un tipo de ataque que ni siquiera suele necesitar de un acceso al sistema es el conocido como la negación de servicio (Denial of Service). Consiste básicamente en perjudicar total o parcialmente la disponibilidad de un recurso, por ejemplo utilizando grandes cantidades de CPU, ocupando toda la memoria del sistema o incluso deteniendo una máquina. Obviamente las negaciones de servicio más peligrosas son las que detienen el sistema o alguno de sus servicios de forma remota:
    Las paradas de máquina son, por norma general, fruto de un fallo en la implementación de red del núcleo: por ejemplo, la llegada de un paquete con una cabecera extraña, de una longitud determinada, o con una cierta prioridad, puede llegar a detener la máquina si ese paquete no se trata correctamente en la implementación del sistema de red. La mejor forma de prevenir estos ataques (que no suelen dejar ningún rastro en los ficheros de log) es actualizar el núcleo de nuestro Unix periódicamente, manteniendo siempre la última versión estable.
    En el caso de la detención de servicios determinados, habitualmente los ofrecidos desde inetd, la negación de servicio suele ser fruto de un excesivo número de peticiones `falsas' al demonio correspondiente; por ejemplo, un atacante enmascara su dirección IP para sobrecargar de peticiones un demonio como in.telnetd hasta detenerlo. Para evitar estos ataques podemos incrementar el número de peticiones simultáneas que un demonio acepta (en la opción wait de la línea correspondiente en el fichero /etc/inetd.conf), aunque esto también implica peligros de negación de servicio (puede aumentar demasiado el tiempo de respuesta del equipo); una forma mucho más recomendable de actuar no es prevenir estos ataques sino minimizar sus efectos: si enviamos una señal SIGHUP al demonio inetd éste relee su configuración, por lo que el servicio bloqueado vuelve a funcionarA.2. Por tanto, es recomendable enviar una de estas señales de forma automática cada cierto tiempo; podemos planificar esta acción para que cron la ejecute cada vez que despierte, incluyendo en nuestro archivo crontab una línea como la siguiente:
    * * * * *        /usr/bin/pkill -HUP inetd 2>&1 >/dev/null

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 archivosA.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 similarA.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.

Recuperación

>Qué hacer cuando se detecta una intrusión en la máquina? Muchos administradores se hacen esta pregunta cuando se dan cuenta de que su seguridad ha sido quebrada. Por supuesto, en esta situación se pueden hacer muchas cosas, desde ignorar el hecho y dejar que el pirata haga lo que quiera en nuestro sistema (obviamente, esto no es recomendable) hasta intentar localizar al intruso mediante denuncia y orden judicial para tracear la llamada; esto tampoco es habitual, ya que es muy difícil demostrar ante un juez que un atacante ha violado nuestra seguridad, por lo que sólo vamos a perder tiempo y dinero. Lo habitual en entornos universitarios es intentar detectar si el atacante pertenece a la comunidad universitaria (en cuyo caso se le puede sancionar), restaurar la integridad del equipo de forma que un ataque similar no vuelva a tener éxito, y poner de nuevo la máquina a trabajar (recordemos que la disponibilidad suele ser lo más importante en organizaciones de I+D). Pero, hagamos lo que hagamos, hay que cumplir una norma básica: no ponernos nerviosos; si no logramos mantener la calma podemos ser incluso más perjudiciales para el sistema que el propio intruso o podemos poner a éste nervioso, lo que puede convertir un simple fisgoneo en una pérdida irrecuperable de datos.

Desde el punto de vista de Unix, es posible que nos interese localizar el fallo de seguridad aprovechado por el pirata para cerrarlo y que el problema no vuelva a ocurrir; sin entrar en temas complejos como el jailing o la simulación, una de las formas que tenemos para realizar esta tarea es monitorizar las actividades del intruso, incluso arriesgando la integridad del sistema (podemos hacer una copia de seguridad por lo que pueda pasar). Para realizar esto, hemos de ser conscientes de que si alguien ha conseguido privilegios de administrador en la máquina, puede haber modificado desde los programas del sistema hasta las librerías dinámicas, pasando incluso por el subsistema de accounting de procesos. Por tanto, hemos de desconfiar de los resultados que cualquier orden nos proporcione, ya que el intruso puede haberlos modificado para ocultar sus actividades. Si queremos auditar las actividades del atacante hemos de utilizar programas `nuevos', a ser posible compilados estáticamente (sin dependencia de librerías dinámicas): podemos utilizar versiones de código fuente disponible para adecuarlas a nuestro sistema, compilarlas estáticamente en un sistema similar al atacadoA.5, y utilizarlas en la máquina donde está el intruso.

El proceso de modificar librerías dinámicas habitualmente excede los conocimientos del atacante medio de entornos I+D; como además conseguir programas estáticos para nuestro equipo suele ser complejo y lento en la mayoría de situaciones, y un objetivo básico es devolver el sistema a su funcionamiento normal cuanto antes, lo habitual no es utilizar programas compilados de forma estática sino confiar en que el intruso no haya modificado librerías dinámicas y utilizar versiones `limpias' de programas dinámicos; por ejemplo, podemos utilizar los programas originales del sistema operativo que se encuentran en el CD-ROM de instalación del mismo.

Si en lugar de intentar monitorizar las actividades del intruso en el sistema lo único que queremos es echarlo de nuestra máquina (esto tiene su parte positiva, pero también su parte negativa), hemos de tener siempre presente que desconocemos lo que ha hecho; la forma más efectiva de tirarlo de nuestro equipo es desconectando el cable de red (mucho mejor que utilizar ifconfig para detener la tarjeta o shutdown para parar el sistema, ya que el atacante puede haber contaminado estos programas para que realicen una actividad diferente a la que en teoría están destinados). Pero no nos podemos limitar únicamente a desconectar el cable de red: el atacante puede tener procesos activos en el sistema, bombas lógicas, o simplemente tareas destructivas planificadas con at o cron; hemos de chequear todo el sistema en busca de este tipo de amenazas. Un lugar interesante donde el intruso nos puede causar un problema grave es en los ficheros de inicialización de la máquina, situados generalmente en /etc/rc?.d/ o /etc/rc.d/.

Una vez detectado y solucionado el problema de seguridad hemos de restaurar un estado fiable de la máquina, esto es, un estado similar al que tenía antes de ser atacada. Aunque en muchos lugares se indica restaurar una copia de seguridad anterior al ataque, esto presenta graves problemas: realmente no sabemos con certeza cuando se produjo el ataque al sistema, sino que en todo caso sabemos cuándo se detectó el mismo, por lo que corremos el peligro de utilizar una copia de seguridad que ya esté contaminada por el atacante. Es mucho más seguro reinstalar el sistema completo y actualizarlo para solucionar los fallos que posibilitaron la entrada del intruso, por ejemplo aplicando patches sobre la versión que hemos instalado.

Restaurar y actualizar el sistema operativo y sus programas puede ser una tarea pesada, pero no implica ninguna complicación: con toda probabilidad tenemos a nuestra disposición los CD-ROMs con el software que hemos de instalar; los problemas reales surgen con los archivos de los usuarios: evidentemente, no podemos decirles que para evitar posibles conflictos de seguridad se les han borrado sus archivos, sino que lo habitual va a ser mantener el estado de sus ficheros justo como estaban durante el ataque o, en caso de que este haya eliminado o corrompido información, tal y como estaban exactamente antes del ataque. Por tanto, especialmente si mantenemos el estado de los ficheros de usuario, hay que estar atentos a posibles problemas que estos puedan introducir en el sistema, comentados en el apartado A.3.

Recomendaciones de seguridad para los usuarios

Con frecuencia la parte más complicada de una política de seguridad es concienciar a los usuarios de la necesidad de medidas básicas de prevención contra ataques. Demasiados usuarios opinan que las historias de crackers que atacan ordenadores sólo suceden en las películas o en organizaciones militares de alta seguridad; nada más lejos de la realidad: en cualquier universidad ocurren a diario incidentes de seguridad, de los que sólo una pequeña parte se detecta (y muchos menos se solucionan). Sería pues muy recomendable para el administrador imprimir una hoja con las medidas de seguridad básicas o la política del sistema, y entregar una copia a cada usuario al crear su cuenta.
  • Contraseñas aceptables
    Es conveniente que los usuarios elijan claves medianamente resistentes a ataques de diccionario; una contraseña como patata o valencia es un gran agujero de seguridad para la máquina, aunque el usuario que la usa no tenga ningún privilegio especial. Hemos de ver la seguridad como una cadena cuya fuerza depende principalmente del eslabón más débil: si falla éste, falla toda la cadena. Sin embargo, el problema de estas claves es que pueden llegar a ser difíciles de recordar, de forma que mucha gente opta por apuntarlas en el monitor de su estación o en la parte inferior de sus teclados; obviamente, esto es casi peor que el problema inicial, ya que como administradores no podemos controlar estas situaciones la mayor parte de las veces. Podemos (y sería lo recomendable) recomendar a los usuarios que utilicen combinaciones de mayúsculas, minúsculas, números y símbolos para generar sus claves, pero de forma que la combinación les pueda resultar familiar: por ejemplo, combinar números y letras de la matrícula del coche con algunos símbolos de separación; claves de este estilo podrían ser V#GF&121, @3289?DH o JKnB0322. Obviamente estas claves son más resistentes a un ataque que beatles, pero tampoco son seguras: las acabamos de escribir.
  • Confidencialidad de las claves
    Hemos de concienciar a nuestros usuarios de que las contraseñas no se comparten: no es recomendable `prestar' su clave a otras personas, ajenas o no al sistema, ni por supuesto utilizar la misma clave para diferentes máquinas. Este último punto muchas veces se olvida en sistemas de I+D, donde el usuario se ve obligado a utilizar passwords para muchas actividades y tiende invariablemente a usar la misma contraseña; incluso se utiliza la clave de acceso a un equipo Unix para autenticarse en juegos de red (MUDs o IRC) o, lo que es igual de grave, para acceder a equipos Windows, de forma que las vulnerabilidades de seguridad de estos sistemas se trasladan a Unix.
  • Conexiones cifradas
    Hay que potenciar entre los usuarios el uso de programas como ssh/scp o
    ssl-telnet/ssl-ftp para conectar al equipo. La parte cliente de estos programas es muy simple de utilizar, y nos puede ahorrar muchos dolores de cabeza como administradores. Incluso existen clientes para Windows y MacOS, por lo que nadie tiene excusa para no usar sistemas cifrados (se puede conseguir que su uso sea completamente transparente al usuario); casi la mejor forma de que los usuarios los utilicen es dejando de ofrecer ciertos servicios sin cifra, como telnet, ftp, rlogin o rsh.
  • Ejecución de programas
    Nunca, bajo ningún concepto, instalar o ejecutar software que no provenga de fuentes fiables; hay que prestar atención especial a programas que nos envíen por correo o por IRC, ya que se puede tratar de programas trampa que, desde borrar todos nuestros ficheros, a enviar por correo una copia del archivo de contraseñas, pueden hacer cualquier cosa: imaginemos que un `amigo' nos envía un juego a través de cualquier medio - especialmente IRC - y nosotros lo ejecutamos; incluso disponer del código fuente no es ninguna garantía (>qué usuario medio lee un código en C de, quizás, miles de líneas?). Ese programa puede hacer algo tan simple como rm -rf $HOME/* sin que nosotros nos demos cuenta, con las consecuencias que esta orden implica.
  • Desconfianza
    Hemos de desconfiar de cualquier correo electrónico, llamada telefónica o mensaje de otro tipo que nos indique realizar una determinada actividad en el sistema, especialmente cambiar la clave o ejecutar cierta orden; con frecuencia, un usuario se convierte en cómplice involuntario de un atacante: imaginemos que recibimos una llamada de alguien que dice ser el administrador del sistema y que nos recomienda cambiar nuestra clave por otra que él nos facilita, con la excusa de comprobar el funcionamiento del nuevo software de correo. Si hacemos esto, esa persona ya tiene nuestra contraseña para acceder ilegalmente a la máquina y hacer allí lo que quiera; hemos de recordar siempre que el administrador no necesita nuestra ayuda para comprobar nada, y si necesita cambiar nuestra clave, lo puede hacer él mismo.
  • Un último consejo...
    Cualquier actividad sospechosa que detectemos, aunque no nos implique directamente a nosotros, ha de ser notificada al administrador o responsable de seguridad del equipo. Esta notificación, a ser posible, no se ha de realizar por correo electrónico (un atacante puede eliminar ese mail), sino en persona o por teléfono.
    En muchas ocasiones, cuando un usuario nota un comportamiento extraño en el sistema, no notifica nada pensando que el administrador ya se ha enterado del suceso, o por miedo a quedar en ridículo (quizás que lo que nosotros consideramos `extraño' resulta ser algo completamente normal); esta situación es errónea: si se trata de una falsa alarma, mucho mejor, pero...>y si no lo es?

Referencias rápidas

Prevención

  • Cerrar los servicios de inetd que no sean estrictamente necesarios.
  • No lanzar demonios en el arranque de máquina que no sean estrictamente necesarios.
  • Minimizar el número de ficheros setuidados o setgidados en la máquina.
  • Instalar TCP Wrappers y utilizar una política restrictiva: echo ALL:ALL >/etc/hosts.deny.
  • Utilizar TCP Wrappers para controlar el acceso a nuestro sendmail, o utilizar un wrapper propio para este demonio.
  • Sustituir telnet, ftp o similares por ssh y scp.
  • No permitir ficheros $HOME/.rhosts en los directorios de usuarios, y no establecer relaciones de confianza en /etc/hosts.equiv.
  • Deshabilitar las cuentas del sistema que no corresponden a usuarios reales (uucp, lp...).
  • Instalar un sistema Shadow Password para que los usuarios no puedan leer las claves cifradas.
  • Deshabilitar las cuentas de usuarios que no conecten al sistema.
  • Utilizar versiones actualizadas del núcleo del sistema operativo.
  • Evitar sobrecargas de servicio planificando pkill -HUP inetd en nuestro fichero crontab.

Detección

  • Configurar Tripwire nada más instalar el sistema y guardar sus resultados en un medio fiable; cada cierto tiempo, ejecutar Tripwire para comparar sus resultados con los iniciales.
  • Chequear periódicamente los logs en busca de actividades sospechosas.
  • Utilizar órdenes como ps, netstat o last para detectar cualquier evento fuera de lo normal en el sistema, pero no confiar ciegamente en los resultados que se nos muestran en pantalla: seamos paranoicos.
  • Comprobar periódicamente la integridad de ficheros importantes de nuestro sistema, como /etc/passwd, /etc/exports, /etc/syslog.conf, /etc/aliases o ficheros de arranque.
  • Comprobar también elementos como los permisos o el propietario de los ficheros que se encuentran en los directorios de usuarios.

Recuperación

  • Nunca hay que ponerse nervioso: nuestra máquina ni ha sido la primera ni lamentablemente será la última en sufrir un ataque. No es el fin del mundo.
  • Desconfiar de cualquier programa que se encuentre en el sistema; utilizar programas del CD-ROM del sistema operativo, o versiones estáticas de los mismos, para tracear las actividades del intruso.
  • Si es posible, reinstalar el sistema operativo completo y aplicarle los parches de seguridad que el fabricante pone a nuestra disposiciónA.6; permanecer atentos a los directorios de usuarios y a los programas que éstos contienen.
  • Si pensamos que la integridad del sistema peligra mucho, desconectar directamente el cable de red: utilizar ifconfig down o detener el sistema con shutdown puede incluso acarrearnos problemas.
  • Obviamente, antes de poner el sistema de nuevo a funcionar en red, estar completamente seguro que los problemas de seguridad que el atacante aprovechó están solucionados.

Usuarios

  • No elegir claves de menos de seis caracteres, y combinar mayúsculas, minúsculas, números, signos de puntuación...cualquier cosa que nos permita el teclado.
  • No apuntar nuestras claves ni compartirlas con otras personas.
  • No utilizar nuestra contraseña de acceso en otros sistemas, especialmente juegos en red o equipos Windows.
  • Sustituir telnet y ftp por ssh y scp o similares.
  • Nunca ejecutar programas que nos envien por correo o que consigamos a partir de fuentes poco fiables (como un `amigo' que nos pasa un programa por IRC). Tampoco ejecutar órdenes cuyo funcionamiento desconocemos, especialmente si alguien desconocido nos indica teclear `algo' para ver el resultado.
  • Desconfiar de llamadas telefónicas o correo electrónico que nos incita a realizar cualquier actividad dentro del sistema, especialmente cambiar nuestra clave; si estas situaciones se producen, indicarlo inmediatamente al responsable de seguridad del equipo, mediante teléfono o en persona.
  • Ante cualquier actividad sospechosa que se detecte es recomendable ponerse en contacto con el responsable de seguridad o el administrador, a ser posible por teléfono o en persona.
next up previous contents
Siguiente: Normativa Subir: Apéndices Anterior: Apéndices   Índice General
2002-07-15