A veces se le ha atribuido al sistema GNU/Linux una escasez de seguridad, a pesar de ser un sistema multiusuario real, y sí que han existido conocidos agujeros de seguridad, no en el sistema en su conjunto sino en diversas aplicaciones. El gestor de correo, enorme y complejo, Por esto, y a pesar de que la respuesta de los desarrolladores de las diversas distribuciones de GNU/Linux, y de los creadores de aplicaciones ha sido siempre rápida, es posible que en un sistema no se tapen los agujeros de seguridad porque el administrador no ha tenido tiempo de actualizar a la última versión, no conoce de la existencia de aquél, o no ha sabido configurar adecuadamente las aplicaciones o servicios ofrecidos.

Las distribuciones basadas en GNU/Linux ofrecen a sus usuarios una gran cantidad de información en sus servidores de WWW referentes a actualizaciones de paquetes que proporcionaban programas a los cuales les ha sido detectado un posible peligro de seguridad. RedHat hace esto frecuentemente, incluso se vió obligada a sacar la versión 5.1 de forma acelerada para tapar el gran número de agujeros existentes en su versión estrella, la 5.0. Debian también pone avisos de seguridad, cuando son recibidos, relacionados con los programas que se ofrecen dentro de la distribución, aunque con su modelo de desarrollo más abierto, veáse por ejemplo el BTS (Bug Tracking System), consigue ofrecer antes nuevas versiones de los programas con los problemas de seguridad resueltos. Así mismo, Debian, con posterioridad a la salida de la versión final de su distribución, crea una nueva sección llamada stable-updates que contiene actualizaciones a paquetes de la versión estable en su mayor parte relacionadas con problemas de seguridad.

Sin embargo los problemas que dan lugar a que una determinada máquina esté "comprometida" no se limita exclusivamente a que se haya instalado la última versión de un determinado programa, también es necesario cuidar la configuración de ciertos programas, vigilar la información ofrecida a los extraños y el contenido de los diversos ficheros de un sistema.

El sistema GNU/Linux se surte, desde sus principios, de los programas surgidos dentro de la comunidad UNIX en muchos ámbitos, ya que éste es un sistema UNIX para PCs, como ya saben los lectores de la revista. Desde gestores de correo, a servidores de ftp o servidores de WWW, algunos de los existentes en GNU/Linux son, o provienen de, programas diseñados en principio para otros sistemas UNIX, aunque con el auge actual de GNU/Linux estos programas se diseñan específicamente para Linux. Es por lo primero que los problemas de seguridad de estos programas se pueden trasladar a una distribución de GNU/Linux, pero también es por esto que existen gran cantidad de auditores de seguridad para Linux.

Se tratarán primero herramientas que no son específicas de GNU/Linux, sino del mundo UNIX en general, y tratando de comentar las particularidades de aquellos en cuanto a GNU/Linux se refiere. Posteriormente se comentarán también herramientas exclusivas, surgidas más recientemente, para GNU/Linux, y se incidirá en las facilidades (o problemas) de portabilidad de estas herramientas a GNU/Linux. Auditores de seguridad

¿Qué son los programas auditores de seguridad?

Los programas auditores de seguridad son herramientas tremendamente útiles para la administración de un sistema, ya que permiten detectar, de forma rutinaria, problemas de seguridad para los que pudieran existir ataques conocidos.

Un programa auditor de seguridad debería ser capaz de detectarlos sin vulnerar la integridad del sistema, es decir, no debería, por ejemplo, detectar que un sistema es vulnerable a un ataque del tipo DoS (Denial of Service), dejando al sistema "colgado". Este tipo de programas no sustituyen al sentido común ni a la experiencia de un buen administrador, sino que suponen una ayuda para realizar algunas tareas rutinarias que pueden llevar mucho tiempo a un administrador normal.

Estos programas pueden operar a muchos niveles, desde la comprobación de la pertenencia de archivos a usuarios y grupos del sistema hasta pruebas sobre aplicaciones instaladas para verificar si éstas tienen agujeros conocidos. Una forma sencilla de demonstrarlo sería, por ejemplo, mirar la versión de ésta última, y ver si se trata de una versión que tuviera un problema especialmente grave. Los precursores: COPS, Tiger, Tripwire e ISS

Llamamos a estos programas precursores porque fueron los primeros que empezaron a desarrollarse en la línea de automatizar las tareas del administrador para vigilar la seguridad de la máquina. Todos estos sugieron en el mundo UNIX al principio de la decada de los 90, aunque algunos se mantienen aún hoy vigentes o han sido "remozados" para adaptarlos a los nuevos tiempos.

COPS (Computer Oracle and Password System) es un paquete de herramientas de seguridad disponible de forma pública. Están diseñadas para ayudar a la tarea de un administrador identificando problemas de seguridad en un sistema UNIX, aunque no pretende arreglar las discrepancias que encuentra sino que simplemente produce un informe de lo que ha encontrado y lo almacena o lo envía por correo. COPS fue realizado por Dan Farmer, uno de los creadores de SATAN y distribuido el 31 de enero de 1989.

El paquete se divide en dos partes: un conjunto de programas que automatizan comprobaciones rutinarias y la documentación para manejarlo e interpretar su salida. COPS requiere ser ejecutado en cada máquina a chequear y es multiplataforma. El programa inicialmente fue escrito en base a shell scripts (en el intento de asegurar la portabilidad de éste) y en programas en C (para aquellas acciones que necesitan ejecutarse rápidamente), la última versión de este paquete (1.0.4, 6 de marzo de 1992) está realizada, además, en Perl.

COPS realiza un buen número de comprobaciones, con la intención de buscar vulnerabilidades: chequeo de permisos de ficheros, directorios y dispositivos. cracker de passwords a dos niveles, que de hecho ha sido realizado usando el notorio comprobación del contenido, formato y seguridad de los ficheros de passwords y ge grupo. chequeo de programas que se ejecutan en /etc/rc* y en el cron. búsqueda de programas setuid root, con permiso de escritura y avisa si son shell scripts. comprobación a través CRC de binarios y ficheros importantes para evitar modificaciones. comprobación de permisos de escritura en los directorios de los usuarios y de sus ficheros de configuración. comprobacion automática de avisos del CERT, descargándolos previamente y comprobando si existe algún aviso nuevo para el tipo de máquina sobre el que se ejecuta. un sistema experto llamado Kuang que en base a una serie de reglas indica si el sistema ha sido o no comprometido. chequeos varios: directorios en el patg, hosts.equiv, exportaciones por NFS...

Dado que no realiza ninguna modificación, no necesita ser ejecutado con privilegios de superusuario (como "root") sino que lo puede ejecutar cualquier usuario. Eso sí, para descubir parte de la información, como por ejemplo analizar todos los ficheros con el bit setuid, puede que sea necesario ejecutarlo como superusuario ya que puede que algunos ficheros (o directorios) no tengan permisos de lectura para todo el mundo.

Junto con COPS se distribuye CARP (COPS Analysis and Reporting Program), programa que realiza informes gráficos en base a los resultados de COPS.

Tiger es similar a COPS, pues se dedica a conseguir información que pueda descubrir problemas de seguridad en máquinas UNIX pero está más actualizado que COPS y más configurable. La última versión disponible es de marzo de 1994.

Tiger, que toma el nombre de un equipo de futbol americano, es un conjunto de Bourne shell scripts, programas en C y ficheros de datos que se usan para realizar una auditoría de seguridad de sistemas UNIX. Es multiplataforma, entre ellas SunOS 4.x y 5.x.

Se desarrolló para escanear sistemas que se querían fueran accesibles desde el exterior de un campus, y se ejecuta localmente.

El objetivo primordial de Tiger es analizar el sistema para tratar de encontrar maneras de obtener privilegios de superusuario. Su diseño parte de la hipótesis de que cualquier otro uid o gid puede ser obtenido por personas no autorizadas, es decir, que cualquie persona puede hacerse pasar por un usuario cualquiera de la máquina, excepto, por supuesto, por el superusuario.

Algunos de los chequeos que reliza Tiger son: aliases de mail. exportación por NFS. variables de inetd. variables del PATH. ficheros .rhosts y .netrc. permisos de ficheros y directorios. avisa de la existencia de parches de mantenimiento. paths que se encuentren en ficheros que den algún warning. ofrece ayuda sobre todos los temas. lanza automáticamente el CRACK.

Tiger está disponible para Linux 2.x, gracias al trabajo realizado por Robert L. Ziegler, aunque la versión distribuida originalmente tenía soporte para Linux 0.99. Tiger tiene soporte para muchas arquitecturas, en función de la arquitectura sobre la que se ejecuta se define las comprobaciones que va a realizar.

Por otro lado tenemos a Tripwire, un programa que comprueba la integridad de ficheros y directorios. Genera, en su primera pasada información sobre éstos en una base de datos, y posteriormente los comprueba y avisa de cualquier diferencia (incluso borrados y añadidos). Ejecutado de manera regular permite encontrar cambios en ficheros críticos que podrían haber tenido lugar por la entrada de un "intruso".

Lo que Tripwire hace es marcar en la base de datos tanto los permisos y usuarios de los ficheros como un código de redundancia cíclica (CRC) con el que luego comprueba si ha sido modificado un determinado fichero. El paquete tripwire está disponible para Debian GNU/Linux.

Finalmente dentro de este tipo de programas y en la misma época, se encuentra el ISS (Internet Security Scanner), de Christoper Klaus. En un principio el programa fue realizado por un interés, por parte del autor, de conocer los problemas de seguridad en Internet en 1993. Posteriormente, el autor creó una compañía alrededor de este producto, y distinguió la versión comercial de la versión de prueba, que carece de interfaz gráfico y de parte de la funcionalidad que tiene la primera.

En cualquier caso ISS se trata de una de las primeras herramientas que, a pesar de carecer del interfaz gráfico que luego proveerá SATAN y otras herramientas posteriores, pone en marcha el desarrollo de herramientas auditoras de seguridad de redes automatizadas. COPS, TIGER y Tripwire constituyen el primer paso ya que se tratan de herramientas que sólo ven el sistema sobre el que se ejecutan y comprueban las vulnerabilidades en éste. ISS es capaz de comprobar vulnerabilidades comunes en una o varias subrededes (en la línea de comandos se le dará un rango de una red que indica las máquinas que debe comprobar)

ISS es un programa monolítico escrito en C, que realiza comprobaciones sobre los puertos abiertos en el servidor y de los servicios RPC ofrecidos, estudio de las particiones exportadas por NFS, observación del servidor de correo, comprobaciones sobre el NIS (antes llamado YP - Yellow Pages) y accesos mediante telnet haciendo uso de pares de usuario/password comunes (que en algunos casos venían de fábrica y no se modificaban).

ISS se convierte así en uno de los primeros programas que implementan estas baterías de pruebas, de forma que para un administrador resulta más sencillo comprobar todas las máquinas a su cargo de un sólo vistazo. Más tarde, aunque muy cercano en el tiempo, llegaría SATAN, causando una auténtica revolución. SATAN

SATAN es el acrónimo de Security Administrator Tool for Analyzing Networks (ver listado ). Se trata, más que de un programa, de un conjunto de programas unidos en un interfaz común. Cuando éste fue escrito por Dan Farmen (programador de COPS) y Wietse Venema de la Universidad de Tecnología de Eindhoven, lo que se hizo fue poner una interfaz gráfica que ya se preveía poderosa, y al mismo tiempo "amigable", como es el WWW a un conjunto de programas, algunos ya existentes y otros creados de cero por sus autores, que probaban vulnerabilidades conocidas.

SATAN no es una herramienta novedosa en el aspecto técnico, pero causó una auténtica revolución. Las herramientas de este tipo, pueden convertirse, como todas las herramientas, en utensilios útiles o en armas mortíferas. Los autores tuvieron la "osadía", entonces, de poner el resultado de su trabajo en Internet y permitiendo la distribución libre de binarios y fuentes. Había otros programas disponibles libremente como COPS, para probar vulnerabilidades en un sólo sistema, o el ISS, para probarlas en sistemas remotos, pero este último, por ejemplo, carecía de suficiente funcionalidad y de un interfaz gráfico en la versión pública, aunque sí en la versión comercial. Los autores decidieron distribuirlo de forma libre ya que su experiencia les indicaba que los esfuerzos de limitar la distribución de información de seguridad y herramientas para este fin no había mejorado las cosas, dado que los elementos "no deseables" los conseguían de todas formas y las personas que deberían haber tenido acceso a ellas no lo habían tenido debido a limitaciones arbitrarias o injustas.

Esto tuvo como consecuencia una grave polémica, por la cual incluso uno de los creadores fue despedido de su trabajo. SATAN fue concebida como una herramienta para admininistradores, pero también podía ser usada como un arma por crackers. Incluso se diseñaron programas para detectar "ataques" de SATAN, como por ejemplo Courtney (desarollado por CIAC) o Gabriel.

El problema entonces, y también ahora, es que la mayor parte de los administradores de sistemas no eran capaces de estar al tanto del conjunto de agujeros de seguridad que salían en programas de uso frecuente en muchos sistemas UNIX. Un cracker, bien informado, podía hacer uso de estas vulnerabilidades reconocidas (pero aún no resueltas), para atacar a sistemas que aún no se habían actualizado a una versión del programa que resolviera los fallos.

En un sistema concurren muchos servicios que se "ven" en el exterior, como por ejemplo: servidores de WWW, de correo o de FTP, gestores de bases de datos, exportación de discos via NFS, etc... Estar al tanto de actualizaciones de todos estos y de la forma en que pueden ser usados para obtener información de un servidor que puede servir e intentar acceder a éste puede ocupar gran parte del tiempo de un administrador de sistemas.

Estar al tanto de listas de distribución como bugtrack, los avisos del CERT (ver listado ) no es fácil y, además, si no se hace de forma contínua se puede dejar un "agujero" que un intruso puede intentar aprovechar.

SATAN abrió la polémica al poner en manos de todo el mundo un programa, de fácil uso, que descubriera todas estas vulnerabilidades a un tiempo, a la vez que ponía al descubierto información sobre las relaciones entre máquinas, lo que los autores denominaron "relación de Confianza".

SATAN obtiene tanta información como le es posible de servicios de red como finger, NFS, NIS, ftp y tftp, rexd, y otros. La información extraída no sólo indica las fuentes por las que un intruso podría ganar información del sistema, sino también fallos potenciales de seguridad generalmente debidos a una mala configuración de estos servicios, problemas conocidos en herramientas de red o malas políticas de seguridad.

Pero el concepto novedoso de SATAN es el extraer, de la información inicial y con un conjunto de reglas configurables por el usuario, las relaciones de dependencia entre máquinas o servicios dados de una a otra. Esto hace posible el análisis de todos los servidores de una red para analizar las implicaciones de la política de confianza y servicios ofrecidos que, en palabras de los autores "les permitarán hacer decisiones razonables sobre el nivel de seguridad de los sistemas involucrados". Los autores de SATAN hablan de confianza cuando recursos locales de un servidor (discos duros, acceso de usuarios, servidores de X...) son usados por un cliente con o sin la autorización debida. Si el sistema X confía en el Y, un intruso que pueda poner en peligro Y podrá también poner en peligro X. Los autores indican que cualquier tipo de confianza puede ser subvertida, no sólo porque se pueda acceder a Y, sino porque el sistema que valida el acceso de Y pueda estar fuera del control del administrador. Por ejemplo, si se identifica a Y por el nombre de la máquina y se subvierte el servidor de nombres (el DNS), o si se hace uso de la técnica de IP spoofing para hacerle creer a X que otra máquina es Y.

A este respecto los autores de SATAN escribieron un excelente ensayo sobre seguridad en sistemas UNIX y en Internet en general que se titula "Improving the Security of Your Site by Breaking Into It" ("Mejorar la seguridad de su servidor entrando a la fuerza en él"), lectura recomendable para todos aquellos interesados en seguridad (ver listado )

Hay que decir que SATAN es una herramienta que podría considerarse ya obsoleta, las vulnerabilidades que intenta descubrir, eran comunes (y conocidas) cuando fue diseñada, pero se tratan de "agujeros" que, hoy por hoy, deberían estar "tapados", si se detecta algunos de estos es debido a una incompetencia por parte del administrador de la máquina. Sin embargo, donde aún sí resulta útil SATAN es en la función de recopilación de información y en la aplicabilidad del concepto de confianza. Ejecución de SATAN

SATAN debe ser ejecutado como usuario root (superusuario) ya que algunos de los tests que realiza necesita los requisitos de este usuario para funcionar (ver listado ). Hace uso, por ejemplo, de sockets abriéndolos como SOCK_RAW, para hacer accesos a bajo nivel de éstos. Es posible ejecutar SATAN como cualquier otro usuario, pero algunos de los tests, no funcionarán en absoluto.

Han existido algunos problemas a este respecto en la distribución de SATAN, ya que si el programa se ejecuta como superusuario, y el código fuente está disponible, es posible que algún desaprensivo distribuya una versión de SATAN "modificada" de forma que, al ejecutarla, se introduciría un troyano en el sistema, es decir, la copia modificada realiza más de lo que debería, enviando información, por ejemplo, de nuestro sistema al exterior. Por ello es una buena medida obtener SATAN directamente de la fuente original y comprobar que no ha sido modificado (mediante la suma MD5 del fichero recibido)

Para ejecutar SATAN hace falta Perl 5 (en este lenguaje están programados los scripts que generan las páginas automáticamente y algunos de los tests) y un navegador de WWW, bien sea textual (Lynx) o gráfico (Netscape Navigator o similares). Los programas que realizan las tareas de prueba sobre los diversos sistemas se escribieron en C, perl o lenguaje de la shell, utilizando código disponible en los grupos de noticias (comp.sources.misc.*), y de hecho es posible añadir nuevos programas a todo el conjunto de la herramienta. Otras herramientas posteriores, como , que se comentarán más adelante, o , hacen más fácil el introducir nuevos programas mediante la descripción de reglas.

Cuando se arranca el programa, éste obtiene la configuración de los ficheros localizados en el directorio config/. Estos ficheros indican dónde se encuentran herramientas habituales en entornos UNIX (como finger o ping) así como el navegador de WWW que se utilizará (almacenado en la variable $MOSAIC). Estas herramientas serán utilizados por los diversos programas de los que está compuesto SATAN, y se pueden configurar a mano o bien utilizando el script proporcionado por los autores (reconfig), que busca la localización de estas utilidades en el servidor en el que se instale SATAN.

Seguidamente, lanzará un servidor de WWW y el navegador de WWW que se haya configurado para acceder directamente a la página principal de SATAN. Desde ésta se seleccionará 'Run SATAN', posteriormente el servidor al que va a acceder, se podrá limitar si se va a probar sobre el servidor o sobre su subred, el nivel del escáner y finalmente 'Start the scan'. El acceso al servidor de WWW creado por SATAN (y que se encuentra en un puerto dedicado, en el espacio de usuario, esto es, por encima del 1024), se realiza mediante una llave de un sólo uso que SATAN genera para cada ejecución. Dado que esta llave se guarda en los ficheros HTML generados por SATAN, es importante que estos ficheros tengan permisos de lectura sólo para el superusuario y no para otros. Si no fuera así, cualquier usuario podría acceder al servidor de WWW con la clave proporcionada en ellos y acceder a toda la información disponible sobre los escáners realizados por el superusuario mientras SATAN está siendo ejecutado.

En la selección de Objetivos el usuario puede seleccionar el nivel de ataque: Ligero, Normal o Duro. Un ataque "Ligero" sólo indicará los servidores que existen y qué servicios de RPC (llamada remota a procedimiento) ofrecen. Un ataque "Normal" escaneará los objetivos probando conexiones telnet, FTP, WWW, gopher y SMTP. Se utilizará para establecer qué sistema operativo es (aunque para esto es mejor QueSO, ver listado ). Un ataque "Duro" buscará otras vulnerabilidades, como servidores de FTP que permiten escribir a todos los usuarios o servidores de confianza.

SATAN puede ejecutarse con diversas opciones que indiquen qué servidor/es probar y el nivel de ataque a utilizar, así como limitaciones en el número de servidores a probar. Además muestra de forma gráfica los resultados ordenando las vulnerabilidades por tipos, organizadas de muy diversas maneras (por nivel de riesgo, por sistema operativo...), aunque los autores indican que un trabajo a realizar sería mostrar de forma más gráfica (quizás a través de un grafo) las interrelaciones entre los servidores. Existen además tutoriales que dan información más en detalle de los problemas concretos de algunas de las vulnerabilidades, que son útiles para que el administrador busque más información antes de tomar una decisión sobre cómo arreglar el problema.

Toda la información recopilada sobre las distintas máquinas se almacena en una base de datos (se puede tener más de una base de datos sobre máquinas), que se mantiene entre ejecuciones del programa, y es útil para inferir relaciones entre máquinas que las pueda hacer vulnerables.

Además SATAN es configurable con reglas (en el directorio facts/) que le permiten inferir nueva información y detonar nuevos tests en función de los servicios que se ofrezcan. Estas reglas están escritas en Perl y, a través de ellas se puede extender el programa con nuevos tests. De hecho la decisión de qué test realizar en función de la información recibida se encuentra en estas reglas. Compilar SATAN para Linux

SATAN no fue desarrollado originalmente para GNU/Linux, sino que su documentación indica que funciona en una gran variedad de sistemas UNIX: SunOS 4.x y 5.x, AIX, IRIX5, HP-UX 9.x, SYSV-R4 y Ultrix 4.x. Sus autores destacan que hace falta modificarlo para hacerlo funcionar bajo GNU/Linux.

De hecho es así, siendo necesario modificar los ficheros que se incluyen al compilar el código fuente para hacerlo funcionar con la versión de la librería de C de GNU/Linux. Aunque los cambios difieren para libc5 y para libc6, básicamente debido a la redefinición de la implementación de los formatos de paquete de IP e ICMP en la librería estándar. Esto se puede arreglar modificando el fichero lcompat.h (que funciona para libc5) y comentando toda la definición del paquete ip e icmp, para dejar que sea la librería de C (viene definido en el fichero /usr/include/netinet/ip.h) la que los defina. Asimismo se puede eliminar las referencias en el código fuente a la librería proporcionada en el paquete, si se dispone de las cabeceras de la librería de C (en Debian las proporciona el paquete libc6-dev) para compilar el programa.

Finalmente, para adaptarse a los "nuevos tiempos" y usar los módulos de Perl instalados en el sistema en lugar de los proporcionados por el programa (como es el caso del módulo que proporciona en Perl la función getopts o ctime), es necesario cambiar ligeramente el programa principal (satan) y algunos de los tests, que están escritos en Perl.

También los autores asumen el comportamiento de la llamada al sistema select (que sirve para quedarse a la espera de recibir datos en diversos descriptores) y se ha de modificar el fichero tcp_scan.c que es el responsable de escanear todos los puertos TCP disponibles en un servidor.

Todos estos cambios se han realizado en la versión de SATAN distribuida junto con Debian. Aunque para beneficio de los usuarios de GNU/Linux se puede usar el fichero de diferencias (satan-1.1.1.diff.linux). Utilizando este fichero, realizado con el programa diff) se podrían modificar las fuentes originales (haciendo uso del programa patch, ver página de manual ).

En general, un usuario que instale SATAN dentro de una distribución de GNU/Linux no tendrá que resolver estos problemas, dado que los responsables de la distribución, presumiblemente, los habrán resuelto para que se integre dentro de ésta. Sin embargo no está de más conocerlo, caso de que se desee obtener SATAN de la fuente original y recompilarlo antes de usarlo, algo bastante aconsejable dado el hecho de que va a ser el usuario con los máximos privilegios el que va a hacer uso de éste.

Para compilar SATAN para Linux, una vez realizados los cambios arriba indicados, es necesario, desde el directorio raíz, ejecutar make linux seguido de perl reconfig. Posteriormente se puede configurar los valores que ha obtenido automáticamente editando directamente, como ya se ha dicho antes, los ficheros en el subdirectorio config/. SAINT

SAINT (Security Administrator's Integrated Network Tool) es un producto de World Wide Digital Solutions Inc. (WWDSI) derivado de SATAN, realizado en 1998. En versiones previas no se distribuía bajo la misma licencia que SATAN, aunque versiones posteriores se han distribuido bajo una licencia Open Source (aunque no es la GPL). Esta nueva licencia permite su distribución por parte de aquellos que lo obtienen así como modificaciones, sin embargo no se puede cobrar su uso más allá de los costes de distribución. Las diferencias con SATAN en cuanto a interfaz son mínimas, ambos hacen uso de un navegador de WWW, y los pasos a dar para poner en marcha el programa son los mismos.

SAINT añade a SATAN lo que éste ahora mismo no tiene y es actualidad. El programa no sólo prueba las vulnerabilidades que contemplaba SATAN, sino que añade comprobaciones de las vulnerabilidades conocidas hasta la fecha de su creación. Los tests incluyen comprobaciones sobre servidores de WWW, POP o SMB, y nuevas reglas para dirigir el funcionamiento de éste. Además, la compañía que lo diseñó lo actualiza con cierta regularidad.

A todo esto hay que añadir muchos nuevos tutoriales, hasta un total de 43, sobre las distintas vulnerabilidades que se puedan encontrar, que ayudan al administrador dándole más información sobre el peligro de ésta y sobre cómo eliminarlo. Las vulnerabilidades están clasificadas en tres categorías: Peligrosas (rojo), Proceder con Cautela (amarillo) o de Categoría Desconocida (marrones), no en dos como en SATAN.

SAINT demuestra que es posible realizar un producto comercial sobre un producto que se distribuye de forma gratuita, y con excelentes resultados. Además se trata de un programa que está siendo aún mantenido por la compañía que lo creo, que acepta envíos de nuevos módulos para su inclusión en el programa. NESSUS

Se han visto previamente 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 ).

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. 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 , 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 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). 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. Este es el caso de Debian. Sin embargo, si éste no es su caso, será necesario obtener las fuentes originales (ver listado ).

Una vez obtenidas, se deben seguir los siguientes pasos para instalar el programa: ejecutar autoconf seguido de configure, que hará uso de herramientas GNU para configurar el programa a nuestro sistema. En la documentación indica que debe ser el superusuario el que ejecute este programa, ya que para probar el tipo de ordenación de los sockets, es necesario privilegios especiales. ejecutar make para que compile los programas. Este es un proceso largo ya que ha de compilar cada uno de los tests de seguridad que luego se convertirán en librerías que cargará dinámicamente. Para compilar el programa es necesario tener la versión de desarrollo de gtk, que incluye las cabeceras (ficheros .h) para compilar programas que utilizen esta librería. En Debian ejecutar nessus y nessusd) así como las librerías y las páginas de manual serán instaladas en el sistema.

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 configurarlo está perfectamente documentada en el Manual que acompaña el programa. Gate Security

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. smb-nat

Con este programa se pueden realizar varias comprobaciones de seguridad sobre servidores remotos que estén compartiendo servicios de ficheros a través de NetBIOS. Está basado en el paquete samba y se encuentra disponible en la distribución Debian GNU/Linux. Escáneres remotos

Nmap

Nmap es una herramienta para explorar redes y determinar qué servidores están activos y qué servicios ofrecen. La ventaja con respecto a otras herramientas es que ofrece múltiples técnicas de escáner. Las versiones más recientes también ofrecen la posibilidad de detectar el sistema operativo remoto en función a la implementación del protocolo TCP/IP. El programa dispone incluso, a partir de la versión 2.0, de un interfaz gráfico realizado con gtk llamado nmapfe que permite realizar los escáneres sin necesidad de conocer las múltiples opciones de línea de comandos disponibles. Se trata de una herramienta muy útil en conjunción de otras, como scotty (ver , para conocer la estructura de la red heterogénea que se está intentando auditar. La posibilidad de hacer un escáner, además, de un grupo de servidores, permite extraer rápidamente información que pueda servir para hacer un escáner en mayor profundidad sobre servidores que posiblementa puedan ser comprometidos. 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. Courtney y Gabriel

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 ). 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 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 etherfind y snoop respectivamente), pero además incorpora en su configuración otras formas de avisar al administrador (ver más abajo) Adaptar Gabriel a GNU/Linux

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 Scanlogd Otros auditores para 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ó Y también es posible diseñar auditores de forma que sean portables entre plataformas, como es el caso del denominado Este paquete de seguridad se divide en tres módulos: un cliente El cliente /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 El servidor 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 La idea general es que los clientes ejecuten rutinariamente El interfaz añadido en la segunda versión del paquete (que fue distribuida el 21 de diciembre de 1998) llamado /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. Seguridad en las passwords

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 /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 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: adiestrando a los usuarios en la búsqueda de palabras claves fáciles de recordar pero díficiles de adivinar por estos métodos. entregando al usuario al principio una password del estilo arriba mencionado. sustituyendo el programa de cambio de passwords por uno que impida el uso de passwords inseguras, como por ejemplo, de menos de tres cifras, o sólo con letras o sólo con números. Muchas de las distribuciones de GNU/Linux existentes traen un programa de estas características. habilitar un mecanismo de "envejecimiento" de passwords, de forma que el usuario se vea obligado a cambiar su password cada cierto tiempo. Utilizar sniffers

También útiles para ver cómo de vulnerable es el tráfico que pasa por la red. Un sniffer es un programa que sirve para analizar el tráfico que pasa por una red. La relación con una auditoría de seguridad es inmediata, no sólo falicita el localizar tráfico no esperado dirigido de/hacia un servidor determinado sino que además permite filtrar un tipo de tráfico determinado para ver qué conexiones Sniffers disponibles Tcpdump e ipgrab

Se pueden conseguir herramientas para analizar los ficheros de tráfico generados en Sniffit

Karpski

Se trata de un analizador de tráfico con un interfaz en GTK. Aunque es menos potente que otros analizadores de tráfico pero posiblemente más fácil de usar. Dispone de una tabla de equipos con los permite identificar fácilmente el fabricante del equipo en base a la dirección física de su tarjeta (dirección MAC). Se puede ``pinchar'' una conexión para ver todos aquellos paquetes con origen en el servidor elegido, así como guardar todos los paquetes recibidos. Ipgrab

Ethereal

Se trata de otro analizador de tráfico con un interfaz en GTK, pero que usa la misma librería que tcpdump, es capaz de capturar los paquetes usando filtros que se definen de la misma forma que para este programa y facilita el análisis a posteriori de los paquetes. Dado que desempaqueta completamente los paquetes es una herramienta que necesita de muchos recursos para funcionar correctamente, pero, asimismo, es tremendamente instructiva porque se puede ver el contenido del paquete con respecto a información hexadecimal enviada en la trama. A diferencia de otros analizadores no está orientado a supervisar de forma inmediata la captura de paquetes, sino a descargar los paquetes en un fichero y posteriormente estudiarlos a través del interfaz. Se trata de software aún experimental pero es bastante usable. Se puede descargar de . Detectar la actividad de un sniffer

Monitorizar la red

Es útil también tener una herramienta de monitorización de red para ver los servidores activos. Scotty (antes tkined)

Auditorías y Debian GNU/Linux

En Debian GNU/Linux posiblemente estén disponibles dentro de la distribución muchos más programas útiles para hacer una auditoría de seguridad que en cualquier otra distribución de GNU/Linux. Con la ventaja añadida de, no sólo su disponibilidad, sino su fácil instalación, ya que los desarrolladores de los paquetes correspondientes ya se han preocupado de solventar los problemas de compilación e instalación existentes.

Resumen del artículo

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 ) y que "meta la cabeza" (ver listado ) en las fuentes de los programas ofrecidos, ya que éstos son la mejor muestra de cómo funcionan este tipo de programas. Apéndices Curiosidades de SATAN

Existen ciertas curiosidades relacionadas con SATAN, que se reflejan aquí para información de los lectores.

La imagen de SATAN, un personaje humanoide con una cara caótica y extraña, no ha sido fruto de la imaginación de sus programadores. Se trata de una aportación del dibujante Neil Gaiman, autor del comic Sandman, al proyecto. El boceto original, firmado por éste, forma parte de la distribución de SATAN.

El nombre SATAN también puede resultar ofensivo a algunas personas, los programadores, para evitar discrepancias aunque piensan que el nombre del programa se ajusta muy bien a su herramienta, facilitaron el que se pudiera cambiar el nombre de éste. Existe un programa en la distribución de SANTA Otra curiosidad algo más molesta es que debido al modelo de diseño de SATAN, las páginas de WWW vistas en el navegador son en realidad scripts en Perl que ejecuta éste. Por ello la extensión de todas estas páginas es text/html (que son interpretados por el navegador) la extensión Esto se debe a que cuando Dan Farmer y Wietse Venema diseñaron SATAN, aún no estaba extendido el uso de tipos MIME para todo y tampoco, desde luego, estaba asignado esta extensión al lenguaje Perl ya que por entonces andaba en sus orígenes y no se había extendido tanto como hasta ahora. El problema de ejecución de binarios como root

Es un riesgo indudable ejecutar binarios como superusuario, aunque es algo de lo más común para muchos usuarios, que encuentran que un determinado programa no se ejecuta como usuario normal y sí lo ejecutan como superusuario. Es el caso, por ejemplo, de muchos juegos que hacen uso de la librería En el caso de SATAN se conoce una distribución de binarios de la versión de este para Linux que era en realidad un troyano. Realizaba todas las funciones de SATAN perfectamente pero el que la distribuyó añadió código que ponía en compromiso el sistema en el que fuera ejecutado. Curiosamente, aquella persona (que dicho sea de paso perdió su trabajo por su "hazaña") también distribuyó el código fuente, que se puede poner como ejemplo de un troyano.

Los cambios al código tenían lugar en el programa /etc/passwd), llamado suser después de comprobar que no existía. Posteriormente hace setuid el binario La segunda parte del troyano, dentro del código de El código de este troyano, comentado por ldoolit@cebaf.gov, está disponible en el CD de la revista, junto a la distribución de SATAN. QueSO, un programa que indica el SO

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, 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 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 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 , ha sido programado por un español y es capaz de reconocer entre más de ochenta implementaciones distintas en diversos sistemas operativos. Programas relacionados con la seguridad y dónde encontrarlos.

He aquí el listado de los programas que se comentan en este artículo y el servidor donde se puede obtener la fuente original: COPS, disponible en . TIGER, disponible en ISS, disponible en , más información en Tripwire, disponible en SATAN, la página original (de Wietse Venema) está situada en Los Paises Bajos y se puede acceder en , Dan Farmer mantiene otra página en Estados Unidos en . El programa puede obtenerse en , los avisos del CERT sobre SATAN están en y . Está en preparación un paquete Debian para SATAN. Courtney, programa para detectar escaners tipo SATAN, de CIAC. Se puede obtener en , más información en . Existe un paquete Debian para Courtney. Merlin, se trata de un programa desarrollado por CIAC que sirve de interfaz a otros programas de seguridad (COPS, CRACK, TAMU-tiger..) a través de un navegador de WWW. Se puede obtener en SAINT, actualmente se encuentra como paquete Debian en la sección non-free, pero puede obtenerse de NESSUS, puede obtenerse en . Está disponible en los siguientes paquetes Debian: nessusd, nessus-core, nessus-libraries, y nessus-plugins. Gate security, puede obtenerse en . Gabriel, se puede obtener en , más información en Crack, está disponible en

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: Los archivos del grupo de noticias El almacen de herramientas de seguridad del CERT: El almacén de herramientas de seguridad de CIAC: El almacen de herramientas de seguridad de Sunsite: "Unix security tools": "Security links": "Networking references - Security": Por qué no auditar TODOS los ordenadores

Los programas que se han visto 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." Dónde buscar información relativa a la seguridad

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 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:

El texto "Improving the Security of Your Site by Breaking Into It" ("Mejorar la seguridad de su servidor entrando a la fuerza en él"), se puede encontrar en la distribución de SATAN. El Centro de Coordinación CERT (Computer Emergency Response Team), que ahora celebra su décimo cumpleaños, estudia vulnerabilidades de Seguridad en Internet, dan servicios de respuesta de incidentes a servidores que han sido víctimas de un ataque y publican información relativa a seguridad como avisos, desarrollos o información general para mejorar la seguridad de los servidores : El índice común de vulnerabilidades del CERT (la "lista de la compra"): CIAC (US DOE's computer Incident Advisory Capability); establecido en 1989, poco después del Gusano de Internet, proporciona servicios relacionados con seguridad sin coste a empleados y contratistas del Departamento de Defensa (DOE) Estadounidense: Roothsell es un servidor que comenzó como base de datos de información sobre cómo podría un usuario convertirse en superusuario en una máquina. Actualmente cuenta con una base de datos inmensa sobre seguridad para muchos sistemas operativos y aplicaciones: Bugtrack, el repositorio general de problemas de seguridad de UNIX más grande del mundo: La revista "underground" . La revista "Computer Underground Digest". El servidor de los hackers: Ejemplos de agujeros de seguridad: El paquete de seguridad COPS, así como SATAN, viene acompañado con una buena cantidad de información relativa a seguridad, que, si bien un tanto antigua, en su mayoría sigue aún vigente. Capturas

Capturas incluidas con el articulo y sus pies de páginas: satan-cara.gif: CARA del personaje del programa SATAN (insertar en el listado 1) satan-main.gif: "Paso 1: Página inicial de SATAN." saint-main.gif: Página inicial de SAINT. satan-select.gif: "Paso 2: Selección de servidor sobre el que realizar los tests." satan-data.gif: "Paso 3: Recolección de datos realizada por SATAN" satan-result.gif: "Paso 4: Resultados de SATAN para un servidor." satan-result2.gif: "Paso 5: Resultados de SATAN ordenados por tipo de servicios." Capturas2

Las capturas incluidas con el artículo son las siguientes nessus-www.gif: "El servidor de Nessus: www.nessus.org" nessus-connect.gif: "Cliente de conexión de Nessus" nessus-plugins.gif: "Selección de pruebas a realizar en Nessus" rootshell.gif:"Rootshell es una base de datos con información relativa a seguridad". rootshell-2.gif:"En Rootshell se pueden encontrar y buscar agujeros de seguridad conocidos"