1 Seguridad en GNU/Linux#$+
KA 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, sendmail tiene el triste prestigio de ser un programa en el que haba problemas de seguridad frecuentes. Este gestor no era especfico de Linux, pero s de sistemas UNIX en general.
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 rapida, es posible que en un sistema no se tapen los agujeros de seguridad porque el administrador no ha tenido tiempo de actualizar a la ultima version, no conoce de la existencia de aquel, 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 informacion 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 vio obligada a sacar la version 5.1 de forma acelerada para tapar el gran numero de agujeros existentes en su version estrella, la 5.0. Debian tambien pone avisos de seguridad, cuando son recibidos, relacionados con los programas que se ofrecen dentro de la distribucion, aunque con su modelo de desarrollo mas abierto, vease 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 version final de su distribucion, crea una nueva seccion llamada stable-updates que contiene actualizaciones a paquetes de la version estable en su mayor parte relacionadas con problemas de seguridad.
Sin embargo los problemas que dan lugar a que una determinada maquina este "comprometida" no se limita exclusivamente a que se haya instalado la ultima version de un determinado programa, tambien es necesario cuidar la configuracion de ciertos programas, vigilar la informacion 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 ambitos, ya que este 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 especficamente para Linux. Es por lo primero que los problemas de seguridad de estos programas se pueden trasladar a una distribucion de GNU/Linux, pero tambien es por esto que existen gran cantidad de auditores de seguridad para Linux.
Se trataran primero en este artculo herramientas que no son especficas de GNU/Linux, sino del mundo UNIX en general, y tratando de comentar las particularidades de aquellos en cuanto a GNU/Linux se refiere. En el proximo artculo de la revista, en esta misma seccion, se comentaran tambien herramientas exclusivas, surgidas posteriormente, para GNU/Linux, y se incidira en las facilidades (o problemas) de portabilidad de estas herramientas a GNU/Linux.

2 ¿Que son los programas auditores de seguridad?#$+
K
Los programas auditores de seguridad son herramientas tremendamente utiles para la administracion 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 debera ser capaz de detectarlos sin vulnerar la integridad del sistema, es decir, no debera, 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 comun 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 comprobacion de la pertenencia de archivos a usuarios y grupos del sistema hasta pruebas sobre aplicaciones instaladas para verificar si estas tienen agujeros conocidos. Una forma sencilla de demonstrarlo sera, por ejemplo, mirar la version de esta ultima, y ver si se trata de una version que tuviera un problema especialmente grave.

3 Los precursores: COPS, Tiger, Tripwire e ISS#$+
KLlamamos a estos programas precursores porque fueron los primeros que empezaron a desarrollarse en la lnea de automatizar las tareas del administrador para vigilar la seguridad de la maquina. Todos estos sugieron en el mundo UNIX al principio de la decada de los 90, aunque algunos se mantienen aun 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 publica. Estan 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 enva 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 documentacion para manejarlo e interpretar su salida. COPS requiere ser ejecutado en cada maquina a chequear y es multiplataforma. El programa inicialmente fue escrito en base a shell scripts (en el intento de asegurar la portabilidad de este) y en programas en C (para aquellas acciones que necesitan ejecutarse rapidamente), la ultima version de este paquete (1.0.4, 6 de marzo de 1992) esta realizada, ademas, en Perl.
COPS realiza un buen numero de comprobaciones, con la intencion 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 Crack (ver mas abajo).
· comprobacion 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.
· busqueda de programas setuid root, con permiso de escritura y avisa si son shell scripts.
· comprobacion a traves CRC de binarios y ficheros importantes para evitar modificaciones.
· comprobacion de permisos de escritura en los directorios de los usuarios y de sus ficheros de configuracion.
· comprobacion automatica de avisos del CERT, descargandolos previamente y comprobando si existe algun aviso nuevo para el tipo de maquina 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 modificacion, no necesita ser ejecutado con privilegios de superusuario (como "root") sino que lo puede ejecutar cualquier usuario. Eso s, para descubir parte de la informacion, 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 graficos en base a los resultados de COPS.
Tiger es similar a COPS, pues se dedica a conseguir informacion que pueda descubrir problemas de seguridad en maquinas UNIX pero esta mas actualizado que COPS y mas configurable. La ultima version 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 auditora de seguridad de sistemas UNIX. Es multiplataforma, entre ellas SunOS 4.x y 5.x.
Se desarrollo para escanear sistemas que se queran 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 hipotesis 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 maquina, excepto, por supuesto, por el superusuario.
Algunos de los chequeos que reliza Tiger son: 
· aliases de mail.
· exportacion 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 algun warning.
· ofrece ayuda sobre todos los temas.
· lanza automaticamente el CRACK.
Tiger esta disponible para Linux 2.x, gracias al trabajo realizado por Robert L. Ziegler, aunque la version distribuida originalmente tena soporte para Linux 0.99. Tiger tiene soporte para muchas arquitecturas, en funcion 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 informacion sobre estos 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 crticos que podran 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 codigo de redundancia cclica (CRC) con el que luego comprueba si ha sido modificado un determinado fichero.  Este paquete esta disponible para Debian GNU/Linux existe un paquete tripwire en su ultima version (slink) que esta disponible para instalar.
Finalmente dentro de este tipo de programas y en la misma epoca, se encuentra el ISS (Internet Security Scanner), de Christoper Klaus. En un principio el programa fue realizado por un interes, por parte del autor, de conocer los problemas de seguridad en Internet en 1993. Posteriormente, el autor creo una compaña alrededor de este producto, y distinguio la version comercial de la version de prueba, que carece de interfaz grafico 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 grafico que luego proveera 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 solo ven el sistema sobre el que se ejecutan y comprueban las vulnerabilidades en este. ISS es capaz de comprobar vulnerabilidades comunes en una o varias subrededes (en la lnea de comandos se le dara un rango de una red que indica las maquinas que debe comprobar)
ISS es un programa monoltico 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, observacion 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 venan de fabrica y no se modificaban).
ISS se convierte as en uno de los primeros programas que implementan estas bateras de pruebas, de forma que para un administrador resulta mas sencillo comprobar todas las maquinas a su cargo de un solo vistazo. Mas tarde, aunque muy cercano en el tiempo, llegara SATAN, causando una autentica revolucion.

4 SATAN#$+
KSATAN es el acronimo de Security Administrator Tool for Analyzing Networks (ver listado 1  ). Se trata, mas que de un programa, de un conjunto de programas unidos en un interfaz comun. Cuando este fue escrito por Dan Farmen (programador de COPS) y Wietse Venema de la Universidad de Tecnologa de Eindhoven, lo que se hizo fue poner una interfaz grafica que ya se prevea 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 tecnico, pero causo una autentica revolucion. Las herramientas de este tipo, pueden convertirse, como todas las herramientas, en utensilios utiles o en armas mortferas. Los autores tuvieron la "osada", entonces, de poner el resultado de su trabajo en Internet y permitiendo la distribucion libre de binarios y fuentes. Haba otros programas disponibles libremente como COPS, para probar vulnerabilidades en un solo sistema, o el ISS, para probarlas en sistemas remotos, pero este ultimo, por ejemplo, careca de suficiente funcionalidad y de un interfaz grafico en la version publica, aunque s en la version comercial. Los autores decidieron distribuirlo de forma libre ya que su experiencia les indicaba que los esfuerzos de limitar la distribucion de informacion de seguridad y herramientas para este fin no haba mejorado las cosas, dado que los elementos "no deseables" los conseguan de todas formas y las personas que deberan haber tenido acceso a ellas no lo haban tenido debido a limitaciones arbitrarias o injustas.
Esto tuvo como consecuencia una grave polemica, por la cual incluso uno de los creadores fue despedido de su trabajo. SATAN fue concebida como una herramienta para admininistradores, pero tambien poda 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 tambien 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 salan en programas de uso frecuente en muchos sistemas UNIX. Un cracker, bien informado, poda hacer uso de estas vulnerabilidades reconocidas (pero aun no resueltas), para atacar a sistemas que aun no se haban actualizado a una version 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, exportacion de discos via NFS, etc... Estar al tanto de actualizaciones de todos estos y de la forma en que pueden ser usados para obtener informacion de un servidor que puede servir e intentar acceder a este puede ocupar gran parte del tiempo de un administrador de sistemas.
Estar al tanto de listas de distribucion como bugtrack, los avisos del CERT  no es facil y, ademas, si no se hace de forma contnua se puede dejar un "agujero" que un intruso puede intentar aprovechar.
SATAN abrio la polemica al poner en manos de todo el mundo un programa, de facil uso, que descubriera todas estas vulnerabilidades a un tiempo, a la vez que pona al descubierto informacion sobre las relaciones entre maquinas, lo que los autores denominaron "relacion de Confianza".
SATAN obtiene tanta informacion como le es posible de servicios de red como finger, NFS, NIS, ftp y tftp, rexd, y otros. La informacion extrada no solo indica las fuentes por las que un intruso podra ganar informacion del sistema, sino tambien fallos potenciales de seguridad generalmente debidos a una mala configuracion de estos servicios, problemas conocidos en herramientas de red o malas polticas de seguridad.
Pero el concepto novedoso de SATAN es el extraer, de la informacion inicial y con un conjunto de reglas configurables por el usuario, las relaciones de dependencia entre maquinas o  servicios dados de una a otra. Esto hace posible el analisis de todos los servidores de una red para analizar las implicaciones de la poltica de confianza y servicios ofrecidos que, en palabras de los autores "les permitaran 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 autorizacion debida. Si el sistema X confa en el Y, un intruso que pueda poner en peligro Y podra tambien poner en peligro X. Los autores indican que cualquier tipo de confianza puede ser subvertida, no solo 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 maquina y se subvierte el servidor de nombres (el DNS), o si se hace uso de la tecnica de IP spoofing para hacerle creer a X que otra maquina 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 el"), lectura recomendable para todos aquellos interesados en seguridad 
Hay que decir que SATAN es una herramienta que podra 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, deberan estar "tapados", si se detecta algunos de estos es debido a una incompetencia por parte del administrador de la maquina. Sin embargo, donde aun s resulta util SATAN es en la funcion de recopilacion de informacion y en la aplicabilidad del concepto de confianza.

5 Ejecucion de SATAN#$+
KSATAN 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 2 . Hace uso, por ejemplo, de sockets abriendolos como SOCK_RAW, para hacer accesos a bajo nivel de estos. Es posible ejecutar SATAN como cualquier otro usuario, pero algunos de los tests, no funcionaran en absoluto.
Han existido algunos problemas a este respecto en la distribucion de SATAN, ya que si el programa se ejecuta como superusuario, y el codigo fuente esta disponible, es posible que algun desaprensivo distribuya una version de SATAN "modificada" de forma que, al ejecutarla, se introducira un troyano en el sistema, es decir, la copia modificada realiza mas de lo que debera, enviando informacion, 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 estan programados los scripts que generan las paginas automaticamente y algunos de los tests) y un navegador de WWW, bien sea textual (Lynx) o grafico (Netscape Navigator o similares, para mas navegadores ver el artculo "Navegadores de WWW para GNU/Linux", aparecido en Linux Actual numero 3). Los programas que realizan las tareas de prueba sobre los diversos sistemas se escribieron en C, perl o lenguaje de la shell, utilizando codigo 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 SAINT, que se comentaran mas adelante, o NESSUS, que se comentara en un artculo en el proximo numero de la revista, hacen mas facil el introducir nuevos programas mediante la descripcion de reglas.
Cuando se arranca el programa, este obtiene la configuracion de los ficheros localizados en el directorio config/. Estos ficheros indican donde se encuentran herramientas habituales en entornos UNIX (como finger o ping) as como el navegador de WWW que se utilizara (almacenado en la variable $MOSAIC). Estas herramientas seran utilizados por los diversos programas de los que esta compuesto SATAN, y se pueden configurar a mano o bien utilizando el script proporcionado por los autores (reconfig), que busca la localizacion de estas utilidades en el servidor en el que se instale SATAN.
Seguidamente, lanzara un servidor de WWW y el navegador de WWW que se haya configurado para acceder directamente a la pagina principal de SATAN. Desde esta se seleccionara 'Run SATAN', posteriormente el servidor al que va a acceder, se podra limitar si se va a probar sobre el servidor o sobre su subred, el nivel del escaner 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 solo uso que SATAN genera para cada ejecucion. Dado que esta llave se guarda en los ficheros HTML generados por SATAN, es importante que estos ficheros tengan permisos de lectura solo para el superusuario y no para otros. Si no fuera as, cualquier usuario podra acceder al servidor de WWW con la clave proporcionada en ellos y acceder a toda la informacion disponible sobre los escaners realizados por el superusuario mientras SATAN esta siendo ejecutado.
En la seleccion de Objetivos el usuario puede seleccionar el nivel de ataque: Ligero, Normal o Duro. Un ataque "Ligero" solo indicara los servidores que existen y que servicios de RPC (llamada remota a procedimiento) ofrecen. Un ataque "Normal" escaneara los objetivos probando conexiones telnnt, FTP, WWW, gopher y SMTP. Se utilizara para establecer que sistema operativo es (aunque para esto es mejor QueSO, ver listado 3 ). Un ataque "Duro" buscara 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 que servidor/es probar y el nivel de ataque a utilizar, as como limitaciones en el numero de servidores a probar. Ademas muestra de forma grafica 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 sera mostrar de forma mas grafica (quizas a traves de un grafo) las interrelaciones entre los servidores.  Existen ademas tutoriales que dan informacion mas en detalle de los problemas concretos de algunas de las vulnerabilidades, que son utiles para que el administrador busque mas informacion antes de tomar una decision sobre como arreglar el problema.
Toda la informacion recopilada sobre las distintas maquinas se almacena en una base de datos (se puede tener mas de una base de datos sobre maquinas), que se mantiene entre ejecuciones del programa, y es util para inferir relaciones entre maquinas que las pueda hacer vulnerables.
Ademas SATAN es configurable con reglas (en el directorio facts/) que le permiten inferir nueva informacion y detonar nuevos tests en funcion de los servicios que se ofrezcan. Estas reglas estan escritas en Perl y, a traves de ellas se puede extender el programa con nuevos tests. De hecho la decision de que test realizar en funcion de la informacion recibida se encuentra en estas reglas.

6 Compilar SATAN para Linux#$+
KSATAN no fue desarrollado originalmente para GNU/Linux, sino que su documentacion 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 codigo fuente para hacerlo funcionar con la version de la librera de C de GNU/Linux. Aunque los cambios difieren para libc5 y para libc6, basicamente debido a la redefinicion de la implementacion de los formatos de paquete de IP e ICMP en la librera estandar. Esto se puede arreglar modificando el fichero lcompat.h (que funciona para libc5) y comentando toda la definicion del paquete ip e icmp, para dejar que sea la librera de C (viene definido en el fichero /usr/include/netinet/ip.h) la que los defina. Asimismo se puede eliminar las referencias en el codigo fuente a la librera proporcionada en el paquete, si se dispone de las cabeceras de la librera de C (en Debian las proporciona el paquete libc6-dev) para compilar el programa. En la version que se distribuye en el CD las cabeceras de las libreras proporcionadas por los autores han sido modifcadas por las cabeceras de la libc6, aun as tambien se entrega un fichero (satan-lib.diff.linux) con las diferencias entre ambas.
Finalmente, para adaptarse a los "nuevos tiempos" y usar los modulos de Perl instalados en el sistema en lugar de los proporcionados por el programa (como es el caso del modulo que proporciona en Perl la funcion getopts o ctime), es necesario cambiar ligeramente el programa principal (satan) y algunos de los tests, que estan escritos en Perl.
Tambien 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 version de SATAN distribuida en el CD, aunque para beneficio de los lectores se ha incluido un fichero que indica todas estas diferencias (satan-1.1.1.diff.linux). Haciendo uso de estos ficheros (realizados con el programa diff) se podran modificar las fuentes originales (haciendo uso del programa patch, ver pagina de manual).
En general, un usuario que instale SATAN dentro de una distribucion de GNU/Linux no tendra que resolver estos problemas, dado que los responsables de la distribucion, presumiblemente, los habran resuelto para que se integre dentro de esta. Sin embargo no esta de mas 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 maximos privilegios el que va a hacer uso de este.
Para compilar SATAN para Linux, una vez realizados los cambios arriba indicados, es necesario, desde el directorio raz, ejecutar make linux seguido de perl reconfig. Posteriormente se puede configurar los valores que ha obtenido automaticamente editando directamente, como ya se ha dicho antes, los ficheros en el subdirectorio config/.

7 SAINT#$+
KSAINT (Security Administrator's Integrated Network Tool) es un producto de World Wide Digital Solutions Inc. (WWDSI) derivado de SATAN, realizado en 1998, no se distribuye bajo la misma licencia sino bajo una realizada por la compaña. Esta nueva licencia no permite su distribucion por parte de aquellos que lo obtienen ni modificaciones fuera del uso interno de una compaña que haga uso de este.
Las diferencias con SATAN en cuanto a interfaz son mnimas, 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 este ahora mismo no tiene y es actualidad. El programa no solo prueba las vulnerabilidades que contemplaba SATAN, sino que añade comprobaciones de las vulnerabilidades conocidas hasta la fecha de su creacion. Los tests incluyen comprobaciones sobre servidores de WWW, POP o SMB (ver artculo sobre Samba en el numero 1 de Linux Actual), y nuevas reglas para dirigir el funcionamiento de este. Ademas, la compaña que lo diseño 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 dandole mas informacion sobre el peligro de esta y sobre como eliminarlo. Las vulnerabilidades estan clasificadas en tres categoras: Peligrosas (rojo), Proceder con Cautela (amarillo) o de Categora 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.

8 Resumen#$+
K
En este artculo se han visto algunas herramientas de seguridad utiles para los sistemas GNU/Linux, si bien algunas de ellas primitivas. As como algunos de los problemas de utilizar estar herramientas bajo GNU/Linux, en el proximo artculo se estudiaran con mas detenimiento algunas herramientas similares, nacidas para GNU/Linux, como es el caso de NESSUS (ver ) y otras herramientas relacionadas con auditoras de seguridad disponibles en el mundo UNIX.

9 Sumarios#$+
K
Es posible que existan agujeros de seguridad debido a la mala administracion.
Las distribuciones basadas en GNU/Linux dan mucha informacion relativa a seguridad.
Los programas auditores de seguridad ayudan a detectar vulnerabilidades.
COPS y Tiger comprueban la integridad del sistema haciendo chequeos sobre este.
SATAN es un conjunto de programas para comprobar la seguridad de servidores remotos.
SATAN causo una autentica revolucion por poner a disposicion de todos una herramienta poderosa.
Existen programas para detectar ataques de SATAN.
Es difcil mantenerse al tanto de todos los problemas de seguridad de los programas.
SATAN debe ser ejecutado como superusuario.
Para ejecutar SATAN en Linux es necesario adaptarlo adecuadamente.
SAINT es un desarrollo comercial realizado sobre SATAN.
En un proximo artculo se estudiaran otros programas de seguridad.

10 Listados#$+
K
LISTADO 1-
Existen ciertas curiosidades relacionadas con SATAN, que se reflejan aqu para informacion de los lectores.
La imagen de SATAN, un personaje humanoide con una cara caotica y extraña, no ha sido fruto de la imaginacion de sus programadores. Se trata de una aportacion del dibujante Neil Gaiman, autor del comic Sandman, al proyecto. El boceto original, firmado por este, forma parte de la distribucion de SATAN.
************* INSERTAR IMAGEN DE SATAN ****************
El nombre SATAN tambien 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 este. Existe un programa en la distribucion de SANTA repent (arrepentir) que, si se ejecuta, cambia todas las menciones del angel cado a SANTA (Security Analysis Network Tool for Administrators).
Otra curiosidad algo mas molesta es que debido al modelo de diseño de SATAN, las paginas de WWW vistas en el navegador son en realidad scripts en Perl que ejecuta este. Por ello la extension de todas estas paginas es .pl esto puede causar problemas en navegadores que tengan configurado esta extension como un tipo MIME determinado (application/x-perl). El navegador de Netscape, por ejemplo, por no saber que hacer con este tipo de documentos pedira al usuario un lugar donde guardarlos. Desde luego este no es el comportamiento deseado, ya que uno quiere ver el resultado directamente sobre el navegador. Para conseguir esto, es necesario ir (en el Navigator) al menu de Preferencias/Aplicaciones, eliminar el tipo MIME asociado a la extension pl y añadir dentro de los documentos del tipo text/html (que son interpretados por el navegador) la extension pl. En el Communicator se ha de modificar esto en el menu Preferencias/Avanzadas/Aplicaciones.
Esto se debe a que cuando Dan Farmer y Wietse Venema diseñaron SATAN, aun no estaba extendido el uso de tipos MIME para todo y tampoco, desde luego, estaba asignado esta extension al lenguaje Perl ya que por entonces andaba en sus orgenes y no se haba extendido tanto como hasta ahora.
PIE LISTADO 1: Curiosidades de SATAN #K
LISTADO 2-
Es un riesgo indudable ejecutar binarios como superusuario, aunque es algo de lo mas comun 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 librera svgalib, ya que para el manejo a bajo nivel del hardware (indispensable en muchos juegos) hace falta ejecutar el juego como root (o poner este setuid).
En el caso de SATAN se conoce una distribucion de binarios de la version de este para Linux que era en realidad un troyano. Realizaba todas las funciones de SATAN perfectamente pero el que la distribuyo añadio codigo que pona en compromiso el sistema en el que fuera ejecutado. Curiosamente, aquella persona (que dicho sea de paso perdio su trabajo por su "hazaña") tambien distribuyo el codigo fuente, que se puede poner como ejemplo de un troyano.
Los cambios al codigo tenan lugar en el programa fping, al que añada una nueva funcion llamada backdoor() que era ejecutada por main() despues de comprobar que haba sido ejecutada por el superusuario. Esta funcion tena como tarea añadir un nuevo usuario a la base de datos de usuarios (el fichero /etc/passwd), llamado suser despues de comprobar que no exista. Posteriormente hace setuid el binario fping, y abre una conexion remota a un servidor cuyos ficheros de registro eran accesibles por todo el mundo. Se conecta a un puerto abierto por el demonio inetd, que no esta conectado a ninguna aplicacion, pero que sin embargo se registra como acceso. Esto posiblemente lo haca para poder ver quienes ejecutaban esta version "modificada" de SATAN, y poder acceder a ellos como usuario 'suser' y con la password conocida. 
La segunda parte del troyano, dentro del codigo de fping en la funcion main, haca que, si este era ejecutado por el usuario 'suser' y fijaba una determinada variable de entorno, el programa inmediatamente arrancaba una shell. Dado que el programa ahora tena setuid del superusuario (si era el propietario del fichero) lo que se obtena al ejectuar fping con esta modificacion que era una shell de root.
El codigo de este troyano, comentado por ldoolit@cebaf.gov, esta disponible en el CD de la revista, junto a la distribucion de SATAN.
PIE LISTADO 2: El problema de la ejecucion de binarios como root
LISTADO 3-
Los programas auditores de seguridad vistos utilizan metodos rudimentarios para "adivinar" el sistema operativo que utiliza la maquina sobre la que se estan haciendo los tests. NESSUS (como se vera en el proximo artculo), por ejemplo, lo hace en base a dos conexiones: una conexion 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, basandose 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 mas 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 esta 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 funcion de estas decide si es un SGI, SUN, APOLLO, VMS, Linux..
Ambos metodos pueden ser engañados por un administrador que cambie las cabeceras de sus servicios para indentificarse de forma distinta, y ademas fallaran si no existe ningun servicio que proporcione esta informacion textual.
Un metodo tecnicamente mas avanzado, y con mas 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 maquina a las 64 "banderas" del protocolo TCP. 
QueSO (tambien llamado WathOS) identifica el sistema operativo en funcion de la implementacion TCP/IP; en particular en funcion de la respuesta a paquetes "extraños" cuyo comportamiento no esta definido en ningun RFC y por tanto cuya respuesta depende de la programacion de la pila de protocolos en el sistema operativo concreto. En total enva siete paquetes, y compara la respuesta con una base de datos de respuestas tpicas por sistemas operativos entregada con el programa.
El programa esta disponible en codigo fuente, bajo la licencia GNU en , ha sido programado por un español y es capaz de reconocer entre mas de ochenta implementaciones distintas en diversos sistemas operativos.
PIE LISTADO 3: QueSO, un programa que indica el SO #K
LISTADO 4
En el CD se han incluido todas las herramientas comentadas en el artculo y las que se veran el siguiente, al menos aquellas cuya licencia permite su distribucion en dicho CD. Estan en el subdirectorio la6/security. Asimismo, y por considerarlo de interes para los lectores, se han incluido tambien otras herramientas de seguridad de sistemas UNIX en general y GNU/Linux en particular, haciendo una replica de los servidores de sunsite (ahora metalab.unc.edu) y de CIAC.
Con intencion de hacer mas accesible la instalacion de estos paquetes, el autor ha creado, un paquete para Debian GNU/Linux que permite instalar la ultima version de SATAN (1.1.1). Este paquete, ofrecido en primicia para los lectores de Linux Actual, formara, si es posible, parte de la distribucion de Debian en un futuro. Esta localizado en el directorio debian/.
PIE LISTADO 4: Contenido del CD

11 Capturas#$+
K
Capturas incluidas con el articulo y sus pies de paginas:
- satan-cara.gif: CARA del personaje del programa SATAN (insertar en el listado 1) - satan-main.gif: "Paso 1: Pagina inicial de SATAN."
- saint-main.gif: Pagina inicial de SAINT.
- satan-select.gif: "Paso 2: Seleccion de servidor sobre el que realizar los tests."
- satan-data.gif: "Paso 3: Recoleccion 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."

12 Notas de maquetacion#$+
K
Las capturas de SATAN conviene que esten alineadas en la misma posicion de la paginas, porque son consecutivas es decir, primero va satan-main, luego satan-select, despues satan-data y luego satan-result y satan-result2.
La captura de la "cara" de SATAN debe ir dentro del listado en el que se indica.
AVISO!: Si las capturas se reducen mucho es posible que no se pueda leer (no lo se), si es as contactar con el autor y pedir capturas nuevas relacionadas con el artculo. Sustituire las capturas del funcionamiento del Programa por otras.

13 Notas de coordinacion#$+
K
Este artculo ira seguido de otro contando nuevas cosas al respecto, ya que el artculo original era demasiado largo (11 paginas). As que el siguiente que sera entregado mas tarde tendra las cosas a las que se alude en este (NESSUS y mas cosas), aun as los contenidos en el CD son del total de los dos artculos (salvo una sorpresa que me reservo para el siguiente)
En resumen, para LA7 reservar 5 paginas para la continuacion.
No hay problema en eliminar listados si la maquetacion lo precisa (se incluiran en el siguiente), pero se DEBEN mirar las referencias que haya a estos en el artculo. En cualquier caso NUNCA quitar el listado 4, y si es posible, el 1. El orden de preferencia para la inclusion de listados es: 4, 1, 2, y 3.