<!doctype linuxdoc system>

<article>

<title>Artículo para la revista Linux Actual número 6: Auditores de Seguridad en GNU/Linux.
<author>Javier Fernández-Sanguino Peña <url url="jfs@computer.org">
<date>15 dic 1998

<abstract> Se verán las distintas herramientas disponibles para
comprobar la seguridad de un sistema GNU/Linux, herramientas que no
son específicas de Linux y sí del mundo UNIX general, así como las
facilidades y problemas de migrar estas herramientas al mundo Linux.

<sect>Seguridad en GNU/Linux
<p>
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, <em/sendmail/ tiene el triste prestigio de ser un programa
en el que había problemas de seguridad frecuentes. Este gestor no era
específico 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 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
<em>stable-updates</em> 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 en este artículo 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, incidiendo en las facilidades (o problemas) de portabilidad
de estas herramientas a GNU/Linux. Se comentarán también herramientas
exclusivas, surgidas posteriormente, para GNU/Linux.


<sect>¿Qué son los programas auditores de seguridad?
<p>

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.

<sect>Los precursores: COPS, Tiger, Tripwire e ISS
<p>
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:
<itemize>
<item>chequeo de permisos de ficheros, directorios y dispositivos.
<item>cracker de passwords a dos niveles, que de hecho ha sido
realizado usando el notorio <em/Crack/ (ver más abajo).
<item>comprobación del contenido, formato y seguridad de los ficheros
de passwords y ge grupo.
<item>chequeo de programas que se ejecutan en /etc/rc* y en el cron.
<item>búsqueda de programas setuid root, con permiso de escritura y
avisa si son shell scripts.
<item>comprobación a través CRC de binarios y ficheros importantes para evitar
modificaciones.
<item>comprobación de permisos de escritura en los directorios de los
usuarios y de sus ficheros de configuración.
<item>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.
<item>un sistema experto llamado Kuang que en base a una serie de
reglas indica si el sistema ha sido o no comprometido.
<item>chequeos varios: directorios en el patg, hosts.equiv,
exportaciones por NFS...
</itemize>

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:
<itemize>
<item>aliases de mail.
<item>exportación por NFS.
<item>variables de inetd.
<item>variables del PATH.
<item>ficheros .rhosts y .netrc.
<item>permisos de ficheros y directorios.
<item>avisa de la existencia de parches de mantenimiento.
<item>paths que se encuentren en ficheros que den algún warning.
<item>ofrece ayuda sobre todos los temas.
<item>lanza automáticamente el CRACK.
</itemize>

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.  Este paquete está disponible para Debian GNU/Linux existe un
paquete <em>tripwire</em> en su última versión (slink) que está
disponible para instalar.

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.

<sect>SATAN
<p>
SATAN es el acrónimo de Security Administrator Tool for Analyzing
Networks (ver listado 2 
<!-- <ref id="satan-curiosidad"> -->
). 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  (para más información ver listado 6 <!-- <ref
id="mas-info">-->) 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
<!--<ref id="mas-info">-->)


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.

<sect>Ejecución de SATAN
<p>
SATAN debe ser ejecutado como usuario <em>root</em> (superusuario) ya
que algunos de los tests que realiza necesita los requisitos de este
usuario para funcionar. 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, para más navegadores ver el artículo
"Navegadores de WWW para GNU/Linux", aparecido en Linux Actual número
3). 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 SAINT o NESSUS, que
se comentarán más adelante, 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 <em>config/</em>. Estos ficheros
indican dónde se encuentran herramientas habituales en entornos UNIX
(como <em>finger</em> o <em>ping</em>) así como el navegador de WWW
que se utilizará (almacenado en la variable <em>$MOSAIC</em>). 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 <em>script</em> 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 telnnt, FTP, WWW, gopher y SMTP. Se utilizará para
establecer qué sistema operativo es (aunque para esto es mejor QueSO,
ver listado 4<!--<ref id="queso">-->). 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 <em>facts/</em>) 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.


<sect>Compilar SATAN para Linux
<p>
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
<em>lcompat.h</em> (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 <em>/usr/include/netinet/ip.h</em>) 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. En la versión que se
distribuye en el CD las cabeceras de las librerías proporcionadas por
los autores han sido modifcadas por las cabeceras de la libc6, aún así
también se entrega un fichero (satan-lib.diff.linux) con las
diferencias entre ambas.

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 <em>getopts</em> o <em>ctime</em>), es necesario cambiar
ligeramente el programa principal (<em>satan</em>) y algunos de los
tests, que están escritos en Perl.


También los autores asumen el comportamiento de la llamada al sistema
<em>select</em> (que sirve para quedarse a la espera de recibir datos
en diversos descriptores) y se ha de modificar el fichero
<em>tcp_scan.c</em> 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 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 <em>diff</em>) se podrían modificar las fuentes
originales (haciendo uso del programa <em>patch</em>, 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 <em>make
linux</em> seguido de <em>perl reconfig</em>. Posteriormente se puede
configurar los valores que ha obtenido automáticamente editando
directamente, como ya se ha dicho antes, los ficheros en el
subdirectorio <em>config/</em>.

<sect>SAINT
<p>
SAINT (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
distribución 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 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 (ver artículo sobre Samba en el número 1
de Linux Actual), 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.

<!-- cortar por aquí el artículo -->

<sect>NESSUS
<p>
Se han visto 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, y este es el caso
de NESSUS.

NESSUS da un paso más alla en el diseño de herramientas de este
estilo. Con SATAN (y SAINT) se ha visto que se podía introducir
una gran capacidad para detectar fallos comunes haciendo uso de un
sencillo interfaz. Sin embargo, quizás el lector no se haya dado
cuenta, 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) 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 <em>lynx</em> ya que puede seguir utilizando
un interfaz textual para la aplicación.

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 que se
usa en <em>https</em> (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 HTTP y las respuestas mediante páginas en HTML, no están
cifradas. Cualquier "espía" en el camino de estos datos podría sacar
fácilmente el número utilizado.

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, con poco esfuerzo pues no está así aún, podría
estar encriptado 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 se prevé para la próxima versión que
estará disponible a principios de Enero.

Actualmente, 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 <em/gtk/,
con la que se ha diseñado el famosos <em/Gimp/, 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 <em/gtk/ es
expléndida, con un buen aspecto y muy sencilla de manejar. Además de
todo esto, NESSUS está siendo desarrollado bajo la licencia GPL.


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 120 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 <em/nunca/
('N'). Por ejemplo la regla: "n:*; y:*.foo.org; N:ppp*.foo.org"
probaría sólo sobre las máquinas en el dominio foo.org (y:*.foo.org),
excepto todas las máquinas en este dominio cuyo nombre empezara por
ppp (N:ppp*.foo.org), otras máquinas que se puedan encontrar no serán
probadas (n:*).

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


<sect>Instalar NESSUS
<p>
Si la distribución que usa el lector provee el paquete NESSUS, la
instalación de éste se limitará a instalar dicho paquete y
configurarlo apropiadamente. Sin embargo, si éste no es el caso, será
necesario obtener las fuentes originales (ver listado 1 <!--<ref
id="programas">-->).

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

<itemize>
<item>ejecutar <em/configure/, que hará uso de la herramienta GNU
<em/autoconf/ 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.
<item>ejecutar <em/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
<em/gtk/, que incluye las cabeceras (ficheros .h) para compilar
programas que utilizen esta librería.
<item>ejecutar <em/make install/. Los programas (<em/nessus/ y
<em/nessusd/) así como las librerías y las páginas de manual serán
instaladas en el sistema.
</itemize>

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

NESSUS no es el único programa de este estilo diseñado para GNU/Linux,
también existe <em/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.

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

Este es el caso de <em/Courtney/ y <em/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 <em/port scanning/, consistente en probar todos (o un gran
número) de los puertos de una máquina (cada puerto está ligado a un
servicio, ver <em/inetd.conf(5)/). Los programas pueden así encontrar
servicios vulnerables o no usados para hacerse una idea más precisa de
los servicios ofrecidos por una máquina.

Se va a estudiar <em/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 <em/tcpdump/ junto con una reglas de filtro de paquetes. El
programa <em/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. <em/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
<em/logger/ y envía un mensaje de correo al administrador.

Así pues, si un ordenador accediera uno detrás de otro a todos los
puertos de una máquina que tuviera <em/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 <em/Gabriel/, diseñado
originalmente para Solaris 1 y 2. Éste hace algo similar pero
utilizando los filtros de paquetes de estas plataformas
(<em/etherfind/ y <em/snoop/ respectivamente), pero además incorpora
en su configuración otras formas de avisar al administrador (ver más
abajo)

<sect>Adaptar Gabriel a GNU/Linux
<p>

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

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

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

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

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

<!-- hacer lo de tcpdump??-->


<sect>CRACK, comprobar la seguridad de las passwords adivinándolas
<p>
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 <em/shadow/ ha hecho esto más difícil a posibles intrusos
dado que por un lado se almacena la información del usuario en el
fichero <em>/etc/passwd</em> y por otro las passwords de los usuarios
en el fichero <em>/etc/shadow</em>. 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 <em/Crack/ realizará esta función. Dado un fichero de
claves, intentará "adivinar" las claves de todos los usuarios que en
ella encuentre usando un diccionario de palabras comunes y un conjunto
de reglas que indican cambios frecuentes que se realizan sobre
ellas. Serían reglas, por ejemplo, el poner la primera y la última
letra en mayúsculas, o el cambiar todas las vocales por su número
correspondiente (la 'a' por '1', la 'e' por '2'...). Con estas reglas
<em/Crack/ realiza manipulaciones con las palabras: las invierte,
mezcla, cambia la capitalización, transpone letras.. según una serie
de reglas. El programa viene con unas 240 reglas de manipulación
aunque se pueden construir otras nuevas. Además, es posible conseguir
abundantes diccionarios por FTP, y no sólo de palabras comunes, sino
de hobbies, películas, argot...

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

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

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

<itemize>
<item>adiestrando a los usuarios en la búsqueda de palabras claves
fáciles de recordar pero díficiles de adivinar por estos métodos.
<item>entregando al usuario al principio una password del estilo
arriba mencionado.
<item>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.
<item>habilitar un mecanismo de "envejicimiento" de passwords, de
forma que el usuario se vea obligado a cambiar su password cada cierto
tiempo.
</itemize>


<sect>Otros auditores para de GNU/Linux
<p>
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ó <em/Tiger/ para que pudiera ser usado en
RedHat 5.2 el 14 de septiembre de este mismo año.

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

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

El cliente <em/gog/, es un script en shell que recoge información
sobre los directorios indicados en la configuración, que, por ejemplo,
pueden ser el directorio <em>/etc</em> 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 <em/md5/. Toda esta información es almacenada en
un directorio determinado. Se supone que esta información se recrea
cada cierto tiempo, la documentación sugiere que mediante una entrada
en el <em/cron/.

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

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

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

El interfaz añadido en la segunda versión del paquete (que fue
distribuida el 21 de diciembre de este año) llamado <em/gogview/, permite
configurar el programa servidor añadiendo y eliminando clientes a los
que debe acceder, y ver la integridad de cada uno de los clientes, que
puede estar en uno de cuatro estados: en buen estado, con una
alteración en el perfil, con varias alteraciones en el perfil o
inalcanzable. Los programas que lo forman deben ser instalados en el
directorio <em>/cgi-bin/</em> 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.

<sect>Resumen
<p>
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
la información recomendada y que "meta la cabeza" en las fuentes de
los programas ofrecidos, ya que éstos son la mejor muestra de cómo
funcionan este tipo de programas.


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

Con intención de hacer más accesible la instalación de estos paquetes,
el autor ha creado dos paquetes de para Debian GNU/Linux que permiten
instalar la última version de SATAN (1.1.1) y de NESSUS
(981016). Estos dos paquetes, ofrecidos en primicia para los lectores
de Linux Actual formaran, si es posible, parte de la distribución de
Debian en un futuro.


<sect>Sumarios
<p>


<sect>Listados
<p>


<!-- LISTADO x-


PIE LISTADO x: -->


LISTADO 1-

He aquí el listado de los programas que se comentan en este artículo y
dónde está la fuente original:

<itemize>
<item> COPS, disponible en <url url="ftp://info.cert.org/pub/tools/cops/">.


<item>TIGER, disponible en <url
url="ftp://net.tamu.edu/pub/security/TAMU/">

<item>ISS, disponible en <url
url="ftp://info.cert.org/pub/tools/iss/">, más información en <url
url="ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner">

<item>Tripwire, disponible en <url
url="ftp://info.cert.org/pub/tools/tripwire/">

<item>SATAN, la 
página original (de Wietse Venema) está situada en Los Paises Bajos y
se puede acceder en
<url url="http://wzv.win.tue.nl/satan/">, Dan Farmer mantiene otra
página en Estados Unidos en <url
url="http://www.fish.com/satan/">. El programa puede obtenerse en
<url url="ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.tar.Z">,
los avisos del CERT sobre SATAN están en <url
url="ftp://info.cert.org/pub/cert_advisories/CA-95:06.satan"> y 
<url
url="ftp://info.cert.org/pub/cert_advisories/CA-95:07a.REVISED.satan.vul">.
Está en preparación un paquete Debian para SATAN.

<item>Courtney, programa para detectar escaners tipo SATAN, de
CIAC. Se puede obtener en <url
url="ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney">, más
información en <url
url="http://www.alw.nih.gov/Security/CIAC-Notes/CIAC-Notes-08.html">.
Existe un paquete Debian para Courtney.

<item>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 
<url url="ftp://ciac.llnl.gov/pub/ciac/sectools/unix/merlin/">

<item>SAINT, lamentablemente no puede distribuirse libremente (por
ello no se incluye en el CD) pero puede obtenerse de <url
url="http://www.wwwdsi.com/saint">

<item>NESSUS, puede obtenerse en <url url="http://www.nessus.org">
Está en preparación un paquete Debian, el CD se incluye éste, aunque
no se asegura su buen funcionamiento.

<item>Gate security, puede obtenerse en <url
url="http://tishina.home.ml.org /products/gate">.

<item>Gabriel, se puede obtener en <url url="http://www.lat.com">,
más información en <url url="http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html">

<item>Crack, está disponible en <url url="ftp://info.cert.org/tools/crack">
</itemize>

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:

<itemize>

<item>Los archivos del grupo de noticias <em/comp.source.misc/ en
<url url="ftp://ftp.uu.net">

<item>El almacen de herramientas de seguridad del CERT: <url url="ftp://info.cert.org/pub/tools">
<item>El almacén de herramientas de seguridad de CIAC: <url url="ftp://ciac.llnl.gov/pub/ciac/sectools/unix">

<item>El almacen de herramientas de seguridad de Sunsite: <url
url="ftp://sunsite.unc.edu/pub/linux/system/security">

<item>"Unix security tools":<url url="http://www.aenigma.net/resources/tools/index.htm">

<item>"Security links":<url url="http://www.txdirect.net/~wall/seclinks.htm">
<item>"Networking references - Security": <url url="http://www.dc.net/ilazar/security.htm">

</itemize>


PIE LISTADO 1: Programas relacionados con la seguridad y dónde encontrarlos.<label id="programas">





LISTADO 2-

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.


************* INSERTAR IMAGEN 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 <em/repent/ (arrepentir) que, si se ejecuta,
cambia todas las menciones del angel caído a SANTA (Security Analysis
Network Tool for Administrators).

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 <em/.pl/ esto puede causar problemas en navegadores que
tengan configurado esta extensión como un tipo MIME determinado
(application/x-perl). El navegador de Netscape, por ejemplo, por no
saber qué hacer con este tipo de documentos pedirá al usuario un lugar
donde guardarlos. Desde luego éste 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 menú de
Preferencias/Aplicaciones, eliminar el tipo MIME asociado a la
extensión <em/pl/ y añadir dentro de los documentos del tipo
<em>text/html</em> (que son interpretados por el navegador) la
extensión <em/pl/. En el Communicator se ha de modificar esto en el
menú Preferencias/Avanzadas/Aplicaciones.

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.


PIE LISTADO 2: Curiosidades de SATAN <label id="satan-curiosidad">


LISTADO 3-

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 <em/svgalib/, ya que para el manejo a
bajo nivel del hardware (indispensable en muchos juegos) hace falta
ejecutar el juego como root (o poner éste <em/setuid/).

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 <em/fping/, al que
añadía una nueva función llamada <em/backdoor()/ que era ejecutada por
<em/main()/ después de comprobar que había sido ejecutada por el
superusuario. Esta función tenía como tarea añadir un nuevo usuario a
la base de datos de usuarios (el fichero <em>/etc/passwd</em>), llamado
suser después de comprobar que no existía. Posteriormente hace
setuid el binario <em/fping/, y abre una conexión remota a un servidor
cuyos ficheros de registro eran accesibles por todo el mundo. Se
conecta a un puerto abierto por el demonio <em/inetd/, que no está
conectado a ninguna aplicación, pero que sin embargo se registra como
acceso. Esto posiblemente lo hacía para poder ver quienes ejecutaban
esta versión "modificada" de SATAN, y poder acceder a ellos como
usuario 'suser' y con la password conocida. 

La segunda parte del troyano, dentro del código de <em/fping/ en la
función main, hacía que, si éste era ejecutado por el usuario 'suser'
y fijaba una determinada variable de entorno, el programa
inmediatamente arrancaba una shell. Dado que el programa ahora tenía
setuid del superusuario (si era el propietario del fichero) lo que
se obtenía al ejectuar <em/fping/ con esta modificación que era una shell
de root.

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.

PIE LISTADO 3: El problema de la ejecución de binarios como root

LISTADO 4-

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 <em/wu-ftp/,
es el más utilizado en el mundo UNIX). Mirando en el puerto de telnet
busca determinadas cadenas de caracteres para adivinar si es un Linux,
IRIX, FreeBSD, etc.. Esto está implementado como un "plugin" llamado <em/guess_os/.

SATAN implementa algo parecido en su lista de reglas
<em>rules/hosttype</em>, 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 <em/tft/ de Lamont Granquist (enviado a
rootshell el 7 de julio de 1998), que realiza pruebas sobre la
respuesta de una máquina a las 64 "banderas" del protocolo TCP. 

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

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

PIE LISTADO 4: QueSO, un programa que indica el SO <label id="queso">


LISTADO 5-

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

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

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

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

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

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


LISTADO 6-

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

<itemize>

<item>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.

<item>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 : <url
url="http://www.cert.org">

<item>El índice común de vulnerabilidades del CERT (la "lista de la compra"):
<url url="ftp://info.cert.org/pub/tech_tips/AUSCERT_checklist1.1">

<item> 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: <url
url="http://ciac.llnl.gov/ciac/">

<item>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: <url url="http://www.rootshell.com">

<item>Bugtrack, el repositorio general de problemas de seguridad de UNIX más grande del mundo:
<url url="http://www.geek-girl.com/bugtraq/index.html">

<item>La revista "underground" Phrak.

<item>La revista "Computer Underground Digest".

<item>El servidor de los hackers: <url url="http://www.hackers.com">

<item>Ejemplos de agujeros de seguridad:
<url url="http://oliver.efri.hr/~crv/security/">

<item>El paquete de seguridad COPS 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.

</itemize>

PIE LISTADO 6: Dónde buscar información relativa a la seguridad<label
id="mas-info">


<sect>Capturas
<p>
Poner captura de SAINT, poner captura de Nessus y de SATAN: de la cara
y de cada una las fases de prueba.

Poner captura de las páginas de WWW Rootshell y bugtrack.

?Poner captura de ejecución del Crack.

<sect>Notas de maquetación
<p>

<sect>Notas de coordinación
<p>
<!-- Una posible continuación de este artículo sería sobre trinux
www.trinux.org -->
</article>


