Artículo para la revista Linux Actual número 7: Auditores de Seguridad en GNU/Linux (y II).

Javier Fernández-Sanguino Peña jfs@computer.org

15 dic 1998


Seguiremos viendo herramientas disponibles para comprobar la seguridad de un sistema GNU/Linux, en este caso más específicas a GNU/Linux, y los problemas de portar herramientas de seguridad otros entornos a GNU/Linux.

1. NESSUS

Se vieron en el artículo anterior herramientas, quizás ya algo antiguas, para intentar introducir el concepto de auditores de seguridad. Ahora toca el turno de hablar de una herramienta de última generación para GNU/Linux, y este es el caso de NESSUS (ver http://www.nessus.org).

NESSUS da un paso más alla en el diseño de herramientas de seguridad. Con SATAN (y SAINT) se vió que se podía introducir una gran capacidad para detectar fallos comunes haciendo uso de un sencillo interfaz. Sin embargo, quizás el lector no se percatara de ello en el anterior artículo, pero el uso de un interfaz WWW, aunque bueno por su facilidad de manejo (y porque quizás sea el interfaz genérico más usado actualmente) plantea un problema respecto a la autentificación de los administradores que hagan uso de SATAN en una máquina.

Por un lado obliga a que SATAN sea ejecutado localmente por parte del administrador y a que luego éste lanze el navegador en la misma máquina, de hecho es el primer paso que realiza SATAN. El problema puede darse cuando se quiera instalar SATAN en una máquina que carece de interfaz gráfico, es necesario exportar la aplicación (el cliente de WWW) a través de la red a otra que sí lo tenga. Esto no es problema si el administrador usa lynx ya que puede seguir utilizando un interfaz textual para la aplicación y ejecutar el navegador en la conexión remota.

Si se desea también acceder desde un servidor a otro para ejecutar SATAN en aquél, es necesario que el navegador de WWW envíe en todas las peticiones al servidor de WWW que SATAN lanza, el número mágico que ha generado al arrancar y se encuentra almacenado en los ficheros HTML. Por ello la primera petición del navegador es a un fichero (su URL es file://) y posteriormente al servidor (con el URL http://). Este número es la única prueba para SATAN de que el cliente es quien dice ser, si cualquier otro intercepta este número y accede al servidor de SATAN podrá acceder a toda la información almacenada en este, e incluso ¡hacer sus propias pruebas de seguridad sobre otros servidores! Esto se podría evitar haciendo uso del protocolo seguro de conexión a servidores de WWW, https (que usa el SSL de Netscape).

Esta situación no es del todo insospechada, ya que si el cliente y el servidor están separados, los paquetes enviados de uno a otro, las solicitudes mediante el protocolo HTTP y las respuestas mediante páginas en HTML, no están cifradas ni van por un canal cifrado. Cualquier "espía" en el camino de estos datos podría sacar fácilmente el número utilizado como prueba de autentificación del administrador.

NESSUS es una herramienta que consta de dos módulos separados. De un lado el servidor, que debe ser ejecutado como superusuario, que es el encargado de realizar los tests y que funciona como un demonio en la máquina en la que se lanza, y en el otro el cliente, que puede estar en otra máquina distinta. La comunicación entre ambos se hace a través de un protocolo (que los autores han llamado NTP: Nessus Transfer Protocol) que, en su última versión (1 de febrero de 1999: 990201) puede llevarse a cabo de forma cifrada (con clave pública/privada), de forma que el servidor no podría ser usado por alguien que "espiara" la red y fuera capaz de obtener la palabra clave utilizada. Esta funcionalidad no estaba presente en la anterior versión estable del programa (16 de octubre de 1998: 981016).

Si no se compila NESSUS con la opción de encriptación (./configure --enable-cipher), sin embargo, la autenticación entre el cliente y el servidor se realiza mediante un nombre de usuario y una palabra clave cuyo intercambio debe darse antes de solicitarle ninguna acción al servidor. Las palabras clave están almacenadas en un fichero en el servidor, y es posible limitar sobre qué máquinas puede realizar pruebas de seguridad a un usuario dado.

Existen clientes para GNU/Linux, usando la librería gráfica gtk (la última versión de NESSUS utiliza la versión 1.1), con la que se ha diseñado el famoso programa Gimp y el entorno GNOME (ver http://www.gnome.org, pero también los hay escritos en Java y para Windows NT. El servidor, sin embargo, ha de ejecutarse en un servidor Linux. La interfaz gráfica con gtk (es expléndida, con un buen aspecto y muy sencilla de manejar. Además de todo esto, y algo a destacar por su tremenda importancia, NESSUS está siendo desarrollado bajo la licencia GPL, lo que significa que su modelo de desarrollo es abierto (cualquiera puede colaborar) y que el código fuente del programa está disponible para su revisión.

El diseño de NESSUS, como se puede ver en el código fuente, es muy modular. Todos los tests (algunos los llamarían "ataques") están escritos por separado, y es fácil insertar nuevos programas. Actualmente tiene más de 180 pruebas de seguridad de diversa índole, que el interfaz agrupa por tipos según sean, por ejemplo: agujeros de sendmail, problemas con servidores de FTP, problemas con servidores de WWW... Aunque las vulnerabilidades no están tan detalladas como en otras herramientas (veáse las anteriores), si se da una breve descripción del problema y una ayuda de cómo solucionarlas.

Al igual que SATAN o SAINT, NESSUS puede expandir los servidores que conoce de varias maneras: vía subredes de un dominio, haciendo uso del DNS o cuando ve nuevos servidores a los que se les da acceso mediante NFS. Se pueden definir reglas para limitar a los servidores que va a acceder, de una forma más compleja que hacía SATAN (y por ende SAINT), en éste es posible definir la "profundidad" de la prueba y servidores que nunca serán probados, pero en NESSUS es posible limitar de tres formas: no probar ('n'), sí probar ('y') y no probar nunca ('N'). Por ejemplo la regla: "n:*; y:*.foo.org; N:ppp*.foo.org" probaría sólo sobre las máquinas en el dominio foo.org (y:*.foo.org), excepto todas las máquinas en este dominio cuyo nombre empezara por ppp (N:ppp*.foo.org), otras máquinas que se puedan encontrar no serán probadas (n:*).

Los usuarios puede definir sus propias reglas, aunque existen unas reglas predefinidas por defecto. Las reglas se almacenan en el fichero /usr/local/share (aunque si se instala un paquete de una distribución en lugar de las fuentes originales, seguramente lo instale en /usr/share).

2. Instalar NESSUS

Si la distribución que usa el lector provee el paquete NESSUS, la instalación de éste se limitará a instalar dicho paquete y configurarlo apropiadamente. Sin embargo, si éste no es el caso, será necesario obtener las fuentes originales (ver listado 1 ).

Una vez obtenidas, se deben seguir los siguientes pasos para instalar el programa:

Una vez hecho esto la configuración, según indica la página de manual, será creada al arrancar el programa nessusd en el directorio /usr/local/share/nessus. La forma de configurar el programa está perfectamente documentada en el Manual que acompaña el programa.

NESSUS no es el único programa de este estilo diseñado para GNU/Linux, también existe Gate Security, de Stan Lanford, con un interfaz del tipo curses (en consola). El autor indica que es muy modular y que sería fácil de ampliar con nuevos tests, ya que actualmente cuenta con tan sólo tres sobre los servicios de: finger, NFS y WWW. Está aún en fase de desarrollo (la última versión de mayo de 1998 es la 0.1.4), así que quizás en su versión final sea un programa a valorar.

3. Detectar escáneres remotos

Dado que las herramientas de seguridad mediante tests remotos (SAINT, SATAN...) pueden convertirse en un arma en manos de una persona que pretenda utilizarla para fines ilícitos, es necesario disponer de programas que sean capaces de avisar al administrador cuando se detecte accesso a la máquina realizados por estos programas con la intención de obtener información o de probar vulnerabilidades.

Este es el caso de Courtney y Gabriel, se verá algo más de éste último más adelante. El primero de ellos es un programa desarrollado en la Universidad de California por Marvin J. Christensen. Está diseñado para detectar este tipo de paquetes. Aunque se distribuya indicando que dectará ataques de SATAN en realidad será capaz de detectar un tipo de ataques concreto, denominado port scanning, consistente en probar todos (o un gran número) de los puertos de una máquina (cada puerto está ligado a un servicio, ver inetd.conf(5)). Los programas pueden así encontrar servicios vulnerables o no usados para hacerse una idea más precisa de los servicios ofrecidos por una máquina.

Se va a estudiar Courtney para observar el funcionamiento de estos detectores. Este programa está escrito en Perl, con lo que es más fácil de interpretar. El flujo de control del programa es como sigue: una vez leídas e interpretadas las opciones, ejecuta el programa tcpdump junto con una reglas de filtro de paquetes. El programa tcpdump devolverá todos los paquetes que se lean en una interfaz de red dada que cumplan alguna de las reglas, estas reglas especifican que, por ejemplo, se deben mostrar los paquetes dirigidos a diversos puertos. Courtney leerá de éste todas las conexiones de interés cuando se produzca alguna, y se apuntará su origen, posteriormente comprobará si ese mismos origen ha hecho acciones similares y, si es así, avisa al sistema mediante la llamada a logger y envía un mensaje de correo al administrador.

Así pues, si un ordenador accediera uno detrás de otro a todos los puertos de una máquina que tuviera Courtney, éste empezaría a "hacer saltar las alarmas" del sistema. Posteriormente el administrador podría tomar la decisión de cerrar el acceso a la máquina atacante o no, en función de la política de seguridad de éste.

Se puede ajustar el "nivel de alarma" del programa, que indica bajo qué condiciones se disparará esta. Hay que fijar adecuadamente este nivel ya que si es muy bajo se disparará ante eventos que son perfectamente normales (un usuario de una máquina hace una conexión vía slogin y posteriormente una conexión de FTP), y si es muy alta no se disparará con los denominados "ataques ligeros", que esperan un determinado tiempo antes de realizar la siguiente conexión.

Otro programa de las mismas características es Gabriel, diseñado originalmente para Solaris 1 y 2. Éste hace algo similar pero utilizando los filtros de paquetes de estas plataformas (etherfind y snoop respectivamente), pero además incorpora en su configuración otras formas de avisar al administrador (ver más abajo)

4. Adaptar Gabriel a GNU/Linux

Gabriel es un programa de Los Altos Technologies, Inc., como ya se ha indicado detecta escáneres en la red como SATAN. Pero tiene el aliciente de que es distribuido, los clientes (implementados en gabriel_client.c) avisan de un execeso de accesos a la red y el servidor (implementado en gabriel_server.c) integra la información de estos y avisa de diversas formas al administador: mediante correo electrónico, vía el demonio talk, en la pantalla e incluso a través del teléfono o el beeper si existen las pasarlelas adecuadas (y un módem).

La idea que da lugar a que exista un cliente y un servidor parte del hecho de que SATAN es capaz de realizar tests sobre más de un host de una misma red, e incluso descubrirlos a medida que realiza los tests. Así, puede ser más fácil localizar el segmento de red en que se encuentra el ordenador que está ejecutando SATAN si se recibe la información de todos los ordenadores en varios segmentos.

El cliente esta escrito enteramente en C y muy ligado a su plataforma original, ya que utiliza filtros de paquetes ya existentes, para poder comprobar todos los paquetes iniciales de conexión (ICMP, UDP y TCP). En principio sólo tiene soporte Solaris 1.x o 2.x, y aún no ha sido portado a Linux. Sin embargo este programa sirve como muestra botón de la manera en que se portan este tipo de programas al sistema GNU/Linux. Una de las ventajas fundamentales es que la librería de C de los sistemas UNIX es bastante compatible entre diversas plataformas, con lo que el código original no es necesario casi tocarlo si hace uso de ésta. Otra ventaja es que no hace falta modificar casi el servidor, ya que éste es un shell script que hace uso de programas comúnes en la comunidad UNIX (como awk)

Por tanto las modificaciones para poder portar este programa a Linux serían modificar el cliente para soportar la plataforma Linux haciendo uso de tcpdump, modificar los scripts de shell caso de que hubiera diferencias entre éstas, y modificar el fichero Makefile para poder compilar la versión de Linux.

En el CD se ofrecen tanto una versión modificada por el escritor como la versión original, para hacer posible la comparación entre ambas.

5. CRACK, comprobar la seguridad de las passwords adivinándolas

Finalmente, se va a ver una de las herramientas más usadas en auditorías de seguridad, y no es para menos, ya que una de las formas habituales de tener acceso a una máquina UNIX es directamente accediendo a cuentas (vía telnet, rlogin o slogin) con passwords que se han descubierto fácilmente (o inexistentes). Es por tanto importante probar los mismos métodos que probaría un cracker para asegurar que una máquina es segura a estos intentos. Aunque esto no impide que los usuarios puedan dejarse las password escrita, olvidada por algún lado, si servirá para asegurar que las passwords del sistemas no son fácilmente vulnerables.

Aunque atrás quedan los tiempos en que los sistemas UNIX no registraban los accesos no autorizados y los sistemas VMS eran considerados más seguros por hacerlo, uno de los métodos empleados por posibles "intrusos" es obtener el fichero de passwords del sistema a través de cualquier agujero de seguridad de la máquina, por ejemplo, un PHP/FI en el servidor de WWW mal configurado. El conjunto de herramientas shadow ha hecho esto más difícil a posibles intrusos dado que por un lado se almacena la información del usuario en el fichero /etc/passwd y por otro las passwords de los usuarios en el fichero /etc/shadow. El primero puede ser leído por cualquier usuario del sistema, el segundo sólo por root.

Este fichero contiene las passwords de los usuarios encriptadas, es decir, no están en claro, pero la función que utilizan los sistemas UNIX (un triple DES), que, aunque es difícil de romper por fuerza bruta, sí es posible "atacarla" mediante el uso ingenioso de un diccionario y de reglas. El ataque consiste en encriptar una palabra dada con la función (que es pública) y compararla con el valor encriptado de la password (que es el que contiene el fichero), el algoritmo de encriptación asegura que si ambos son iguales entonces la palabra usada es la password que se quiere adivinar.

El programa Crack realizará esta función. Dado un fichero de claves, intentará "adivinar" las claves de todos los usuarios que en ella encuentre usando un diccionario de palabras comunes y un conjunto de reglas que indican cambios frecuentes que se realizan sobre ellas. Serían reglas, por ejemplo, el poner la primera y la última letra en mayúsculas, o el cambiar todas las vocales por su número correspondiente (la 'a' por '1', la 'e' por '2'...). Con estas reglas Crack realiza manipulaciones con las palabras: las invierte, mezcla, cambia la capitalización, transpone letras.. según una serie de reglas. El programa viene con unas 240 reglas de manipulación aunque se pueden construir otras nuevas. Además, es posible conseguir abundantes diccionarios por FTP, y no sólo de palabras comunes, sino de hobbies, películas, argot...

Así mismo es capaz de realizar ataques de fuerza bruta, aunque se estima que para poder adivinar una password de ocho caracteres (el máximo) con la actual potencia de un ordenador se tardarían varias decenas de años (debido al gran número de posibilidades, más de cien billones, teniendo en cuenta todos los caracteres ASCII imprimibles), si se limita el ataque a un menor número de caracteres (por ejemplo 4), y de menor rango (por ejemplo sólo números) el número desciende considerablemente (diez mil en el caso propuesto).

Este tipo de ataque puede dar resultados sorprendentes, en poco tiempo, ya que si no se ha obligado a los usuarios a hacer uso de passwords difíciles será capaz de adivinar un buen número de ellas. El programa incopora una función para poder avisar a un usuario de que su password es excesivamente fácil, para lograr que la cambie, al tiempo que almacena sus resultados en una base de datos para consulta posterior del administrador.

Este auditoría sobre la seguridad de las passwords se puede evitar (o se pueden evitar "sorpresas") de varias formas:

6. Otros auditores para de GNU/Linux

Aunque parezca complicado portar este tipo de programas a GNU/Linux, la experiencia demuestra lo contrario. Por ejemplo, Robert L. Ziegler, como ya se ha comentado, modificó Tiger para que pudiera ser usado en RedHat 5.1 el 14 de septiembre de 1998.

Y también es posible diseñar auditores de forma que sean portables entre plataformas, como es el caso del denominado gomagog de C. Parisel, que ha sido probado sobre AIX 4.2, HP-UX 10 y Linux 2.0

Este paquete de seguridad se divide en tres módulos: un cliente gog, un servidor magog, y un interfaz para el servidor vía HTML llamado gogview.

El cliente gog, es un script en shell que recoge información sobre los directorios indicados en la configuración, que, por ejemplo, pueden ser el directorio /etc y los directorios donde se almacen los binarios del sistema. Sobre estos extrae la información de permisos y pertenencia, al tiempo que extrae una firma del documento a través de la función md5. Toda esta información es almacenada en un directorio determinado. Se supone que esta información se recrea cada cierto tiempo, la documentación sugiere que mediante una entrada en el cron.

El servidor magog accede vía FTP a los clientes identificándose con un nombre de usuario y password y recupera los ficheros que éstos han dejado con la información sobre cada uno de sus sistemas. Comprueba esta información con los históricos que ha almacenado y avisa de algún cambio.

De esta forma es posible saber si se ha modificado un binario (quizás indique que un intruso ha instalado un troyano), o si se han modificado los permisos (quizás alguien le ha puesto el bit de setuid a alguno de los ficheros).

La idea general es que los clientes ejecuten rutinariamente gog y que cada cierto tiempo se ejecute magog para comprobar los cambios. Además, la filosofía de descentralización permite que todos los clientes sean gestioados desde una sóla máquina.

El interfaz añadido en la segunda versión del paquete (que fue distribuida el 21 de diciembre de 1998) llamado gogview, permite configurar el programa servidor añadiendo y eliminando clientes a los que debe acceder, y ver la integridad de cada uno de los clientes, que puede estar en uno de cuatro estados: en buen estado, con una alteración en el perfil, con varias alteraciones en el perfil o inalcanzable. Los programas que lo forman deben ser instalados en el directorio /cgi-bin/ de un servidor de WWW ya funcional. Los programas de configuración del programa que acompañan la distribución realizan automáticamente esta tarea.

7. Resumen de la serie de artículos

Se han visto múltiples herramientas de seguridad, haciendo un largo recorrido desde las primeras herramientas disponibles para los sistemas UNIX en general, hasta herramientas ya específicas de GNU/Linux, como es el caso de NESSUS con su interfaz gtk.

Se recomienda en cualquier caso encarecidamente al lector que acuda a las fuentes de información indicadas (ver listado 4 -- id="mas-info">--> y que "meta la cabeza" (ver listado 1 en las fuentes de los programas ofrecidos, ya que éstos son la mejor muestra de cómo funcionan este tipo de programas.

8. Contenido del CD

En el CD se han vuelto a incluir todas las herramientas comentadas en el artículo, al menos aquellas cuya licencia permite su distribución en dicho CD. Asimismo, y por considerarlo de interés para los lectores, se han incluido otras herramientas de seguridad de sistemas UNIX en general y GNU/Linux en particular, haciendo una réplica de los servidores de sunsite (ahora metalab.unc.edu) y de CIAC.

Como ya se comentó en el anterior artículo, con intención de hacer más accesible la instalación de estos paquetes, el autor ha creado esta vez, el paquete para Debian GNU/Linux que permite instalar la última version de NESSUS (990201). Este paquete, ofrecido en primicia para los lectores de Linux Actual, formará, si es posible, parte de la distribución de Debian en un futuro.

9. Sumarios

NESSUS consta de dos módulos separados.

La última versión de NESSUS permite que la comunicación sea encriptada.

NESSUS ha sido implementado usando la librería gtk.

Es necesario disponer de escáneres de segurodad.

Courtney utiliza tcpdump y reglas de filtro de paquetes.

Es posible adaptar Gabriel a GNU/Linux con modificaciones mínimas.

Una de las herramientas más usadas en auditorías es Crack.

Es importante "pensar como un cracker" para asegurar un sistema.

Los intrusos intentan obtener el fichero de contraseñas a través de agujeros de seguridad.

El programa Crack intenta adivinar las contraseñas.

Hay que obligar a los usuarios a utilizar contraseñas seguras.

10. Listados

LISTADO 1-

He aquí el listado de los programas que se comentan en este artículo y el servidor donde se puede obtener la fuente original:

En general se pueden encontrar muchos programas de seguridad en los siguientes servidores, aunque el contenido de algunos de éstos se incluye en el CD, se recomienda su visita para buscar nuevas herramientas de seguridad:

PIE LISTADO 1: Programas relacionados con la seguridad y dónde encontrarlos.

LISTADO 2-

Los programas que se han visto en los dos artículos tienen limitaciones, propias o impuestas por el usuario (esto es, configurables) para poner límite a los ordenadores a los que van a inspeccionar. Esto es así porque es muy posible, sobre todo debido a una mala configuración, que se inspeccionen ordenadores fuera de la red que uno está administrando, es decir fuera de su "jurisdicción".

Evidentemente nadie quiere que sus ordenadores sean inspeccionados de esta forma sin haber dado su consentimiento, y este tipo de acciones puede ser considerado un ataque contra sus equipos informáticos, es posible que incluso sea consideraod ilegal. Los autores de SATAN advierten de estos peligros en la documentación del programa.

Este tipo de escaneres "despertarán", además, muchas alarmas en los sistemas (incluyo en aquellos que no tengan programas específicos para detectarlos) y que estarán a la vista de cualquier administrador.

En resumen, tener cuidado cuando se hace uso de estos programas y limitar al máximo la "libertad" que se les da para acceder a otros servidores. En todos ellos (SATAN, SAINT y NESSUS) es posible definir un "límite de profundidad", así como servidores sobre los que nunca realizará las pruebas; es conveniente usar estas facilidades.

Como dicen los autores: "Last but not least, SATAN was written to improve Internet security. Don't put our work to shame."

PIE LISTADO 2: Por qué no auditar TODOS los ordenadores

LISTADO 3-

Los programas auditores de seguridad vistos utilizan métodos rudimentarios para "adivinar" el sistema operativo que utiliza la máquina sobre la que se están haciendo los tests. NESSUS (como se verá en el próximo artículo), por ejemplo, lo hace en base a dos conexiones: una conexión al puerto de FTP (21) y otra al puerto de telnet (23- login remoto). Con la primera identifica si es un sistema Windows o un UNIX, basándose en la cadena de bienvenida recibida; si contiene a la palabra "Microsoft" se trata de un NT y si contiene la palabra "wu-" decide que es un UNIX (el servidor wu-ftp, es el más utilizado en el mundo UNIX). Mirando en el puerto de telnet busca determinadas cadenas de caracteres para adivinar si es un Linux, IRIX, FreeBSD, etc.. Esto está implementado como un "plugin" llamado guess_os.

SATAN implementa algo parecido en su lista de reglas rules/hosttype, en la que simplemente busca expresiones regulares en las respuestas de los programas que utiliza para monitorizar el servidor remoto y en función de éstas decide si es un SGI, SUN, APOLLO, VMS, Linux..

Ambos métodos pueden ser engañados por un administrador que cambie las cabeceras de sus servicios para indentificarse de forma distinta, y además fallarán si no existe ningún servicio que proporcione esta información textual.

Un método técnicamente más avanzado, y con más estilo, es el implementado por QueSO de Jordi Murgo. Se trata de una idea apuntada por otros programas como por ejemplo tft de Lamont Granquist (enviado a rootshell el 7 de julio de 1998), que realiza pruebas sobre la respuesta de una máquina a las 64 "banderas" del protocolo TCP.

QueSO (también llamado WathOS) identifica el sistema operativo en función de la implementación TCP/IP; en particular en función de la respuesta a paquetes "extraños" cuyo comportamiento no está definido en ningún RFC y por tanto cuya respuesta depende de la programación de la pila de protocolos en el sistema operativo concreto. En total envía siete paquetes, y compara la respuesta con una base de datos de respuestas típicas por sistemas operativos entregada con el programa.

El programa está disponible en código fuente, bajo la licencia GNU en http://apostols.org/projectz/queso/, ha sido programado por un español y es capaz de reconocer entre más de ochenta implementaciones distintas en diversos sistemas operativos.

PIE LISTADO 3: QueSO, un programa que indica el SO

LISTADO 4-

Existen invaluables fuentes de información en la Red concernientes a seguridad de GNU/Linux, en particular, y de cualquier otro sistema operativo en general. Servidores como "rootshell" (www.rootshell.com) ponen a disposición del usuario una gran cantidad de información aplicable a problemas de seguridad. Algunos de estos servidores han sido instalados por agencias gubernamentales y otros pertenecen al lado algo más "oscuro" de Internet:

PIE LISTADO 4: Dónde buscar información relativa a la seguridad

11. Capturas

Las capturas incluidas con el artículo son las siguientes

12. Notas de maquetación

13. Notas de coordinación