KERBEROS

La seguridad e integridad de sistemas dentro de una red puede ser complicada. Puede ocupar el tiempo de varios administradores de sistemas slo para mantener la pista de cules servicios se estan ejecutando en una red y la manera en que estos servicios son usados. Ms an, la autenticacin de los usuarios a los servicios de red puede mostrarse peligrosa cuando el mtodo utilizado por el protocolo es inherentemente inseguro, como se evidencia por la transferencia de contraseas sin encriptar sobre la red bajo los protocolos FTP y Telnet. Kerberos es una forma eliminar la necesidad deaquellos protocolos que permiten mtodos de autenticacin inseguros, y de esta forma mejorar la seguridad general de la red. QU ES KERBEROS? Kerberos es un protocolo de seguridad creado por MIT que usa una criptografa de claves simtricas para validar usuarios con los servicios de red evitando as tener que enviar contraseas a travs de la red. Al validar los usuarios para los servicios de la red por medio de Kerberos, se frustran los intentos de usuarios no autorizados que intentan interceptar contraseas en la red. ORIGEN Y DESARROLLO DE KERBEROS El Instituto Tecnolgico de Massachusetts (MIT) desarroll Kerberos para proteger los servicios de red proporcionados por el proyecto Athena. El proyecto recibi el nombre debido al personaje mitolgico griego Kerberos (o Can Cerberos), el perro guardin de tres cabezas de Hades. Existen varias versiones del protocolo. Las versiones 1 a 3 se desarrollaron slo dentro del ambiente del MIT. Steve Miller y Clifford Neuman, los principales diseadores de la versin 4 de Kerberos, publicaron esa versin al final de la dcada de 1980, aunque la haba orientado principalmente para el proyecto Athena. La versin 5, diseada por John Kohl y Clifford Neuman, apareci como la RFC 1510 en 1993 (que qued obsoleta por la RFC 4120 en 2005), con la intencin de eliminar las limitaciones y problemas de seguridad presentes en la versin 4. Actualmente, el MIT distribuye una implementacin de Kerberos libremente bajo una licencia similar a la de BSD. Autoridades de los Estados Unidos clasificaron a Kerberos como municin y prohibieron su exportacin porque usa el algoritmo de cifrado DES (con clave de 56 bits). Una implementacin no estadounidense de Kerberos 4, KTH-KRB, desarrollada en Suecia, puso el sistema a disposicin fuera de los Estados Unidos antes de que ste cambiara sus polticas de exportacin de criptografa (alrededor del ao 2000). La implementacin sueca se bas en una versin llamada eBones, la cual se basaba en la versin exportada MIT Bones (a la que se le haban quitado las funciones de cifrado y las llamadas a ellas), basada a su vez en Kerberos 4, nivel de correccin 9. El australiano Eric Young, autor de numerosas libreras criptogrficas, puso nuevamente las llamadas a funciones y us su librera de cifrado libdes. Esta versin algo limitada de Kerberos se llam versin eBones. Una implementacin de Kerberos en su versin 5, Heimdal, se

lanz por bsicamente el mismo grupo de gente que lanz KTH-KRB. Windows 2000, Windows XP y Windows Server 2003 usan una variante de Kerberos como su mtodo de autenticacin por defecto. Algunos agregadosde Microsoft al conjunto de protocolos de Kerberos estn documentados en la RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" (Protocolos de cambio y establecimiento de clave de tipo Kerberos en Microsoft Windows 2000). Mac OS X de Apple tambin usa Kerberos tanto en sus versiones de cliente y de servidor.

VENTAJAS DE KERBEROS Los servicios de redes ms convencionales usan esquemas de autenticacin basados en contraseas. Tales esquemas requieren que cuando un usuario necesita una autenticacin en un servidor de red, debe proporcionar un nombre de usuario y una contrasea. Lamentablemente, la informacin de autenticacin para muchos servicios se transmite sin estar encriptada. Para que un esquema de este tipo sea seguro, la red tiene que estar inaccequible a usuarios externos, y todos los usuarios de la red deben ser de confianza. An en este caso, una vez que la red se conecte a la Internet, ya no puede asumir que la red es segura. Cualquier intruso del sistema con acceso a la red y un analizador de paquetes puede interceptar cualquier contrasea enviada de este

modo, comprometiendo las cuentas de usuarios y la integridad de toda la infraestructura de seguridad. El primer objetivo de Kerberos es el de eliminar la transmisin a travs de la red de informacin de autenticacin. Un uso correcto de Kerberos erradica la amenaza de analizadores de paquetes que intercepten contraseas en su red. DESVENTAJAS DE KERBEROS A pesar de que Kerberos elimina una amenaza de seguridad comn, puede ser difcil de implementar por una variedad de razones:

La migracin de contraseas de usuarios desde una base de datos de contraseas estndar UNIX, tal como /etc/passwd o /etc/shadow, a una base de datos de contraseas Kerberos puede ser tediosa y no hay un mecanismo rpido para realizar esta tarea. Para ms informacin, refirase a la pregunta nmero 2.23 en el la seccin FAQ de Kerberos en: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html#pwconvert Kerberos es slo parcialmente compatible con los Pluggable Authentication Modules (PAM) usados por la mayora de los servidores Red Hat Enterprise Linux. Para ms informacin sobre ste tpico. Kerberos presupone que cada usuario es de confianza pero que est utilizando una mquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseas no encriptadas sean enviadas a travs de la red. Sin embargo, si cualquier otro usuario aparte del usuario adecuado, tiene acceso a la mquina que emite tickets usados para la autenticacin llamado Centro de distribucin de llaves (KDC) , el sistema de autenticacin de Kerberos completo est en riesgo. Para que una aplicacin use Kerberos, el cdigo debe ser modificado para hacer las llamadas apropiadas a las libreras de Kerberos. Las aplicaciones que son modificadas de esta forma son consideradas kerberizadas. Para algunas aplicaciones, esto puede suponer un esfuerzo excesivo de programacin, debido al tamao de la aplicacin o su diseo. Para otras aplicaciones incompatibles, los cambios se deben realizar en el modo en que el servidor de red y sus clientes se comunican; de nuevo, esto puede suponer bastante programacin. En general, las aplicaciones de cdigo cerrado que no tienen soporte de Kerberos son usualmente las ms problemticas. Finalmente, si decide usar Kerberos en su red, debe darse cuenta de que es una eleccin de todo o nada. Si decide usar Kerberos en su red, debe recordar que si se transmite cualquier contrasea a un servicio que no usa Kerberos para autenticar, se corre el riesgo de que el paquete pueda ser interceptado. As, su red no obtendr ningn beneficio de usar Kerberos. Para asegurar su red con Kerberos, solo debe utilizar las versiones kerberizadas (que funcionen con Kerberos) de todas las aplicaciones cliente/servidor que envien contraseas sin encriptar o no utilizar ninguna de estas aplicaciones en la red.

MODO EN QUE FUNCIONA KERBEROS Kerberos es diferente de los mtodos de autenticacin de nombre de usuario/contrasea. En vez de validar cada usuario para cada servicio de red, Kerberos usa encriptacin simtrica y un tercero, un KDC, para autentificar los usuarios a un conjunto de servicios de red. Una vez que el usuario se ha autentificado al KDC, se le enva un ticket especfico para esa sesin de vuelta a la mquina del usuario y cualquier servicio kerberizado buscar por el ticket en la mquina del usuario en vez de preguntarle al usuario que se autentifique usando una contrasea. Cuando un usuario en una red kerberizada se registra en su estacin de trabajo, su principal se enva al KDC en una peticin para un TGT desde el servidor de autenticacin (AS). Esta peticin puede ser enviada por el programa de conexin para que sea transparente al usuario o puede ser enviada por el programa kinit despus de que el usuario se registre. El KDC verifica el principal en su base de datos. Si lo encuentra, el KDC crea un TGT,el cual es encriptado usando las llaves del usuario y devuelto al usuario. El programa login en la mquina del cliente o kinit descifra el TGT usando la contrasea del usuario La contrasea del usuario es usada nicamente en la mquina del cliente y no es enviada sobre la red. El TGT, se configura para que caduque despus de un cierto perodo de tiempo (usualmente 10 horas) y es almacenado en la cach de credenciales de la mquina del cliente. Se coloca un tiempo de caducidad de manera que un TGT comprometido slo es de utilidad para un intruso por un perodo corto de tiempo. Una vez que el TGT es emitido, el usuario no tiene que reingresar la contrasea al KDC sino hasta que el TGT caduque o se desconecte y vuelva a conectarse. Cuando el usuario necesita acceder a un servicio de red, el software cliente usa el TGT para pedir un nuevo ticket para ese servicio en especfico al servidor de otorgamiento de tickets, TGS. El ticket para el servicio es usado para autentificar el usuario a ese servicio de forma transparente.

NIVELES DE PROTECCIN DE KERBEROS Autenticacin Prueba que el usuario es quien dice ser. Puede ser que la autenticidad se establezca al inicio de la conexin de red y luego se asuma que los siguientes mensajes de una direccin de red determinada se originan desde la parte autenticada. Integridad de datos Asegura que los datos no se modifican en trnsito. Se requiere autenticacin de cada mensaje, sin importar el contenido del mismo. Esto se denominamensaje seguros. Privacidad de datos Asegura que los datos no son ledos en trnsito. En este caso, no slo se autentica cada mensaje, sino que tambin se cifra. stos mensajes son privados. Toda la informacion de Kerberos en: http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-kerberos-works.html Videos relacionados: http://www.youtube.com/watch?v=YeHRY_QFSaA http://www.youtube.com/watch?v=C8kY2SHJYcs http://www.youtube.com/watch?v=7-LjpO2nTJo

SATAN
SATAN es el acrnimo de Security Administrator Tool for Analyzing Networks (ver listado 1 ). Se trata, ms que de un programa, de un conjunto de programas unidos en un interfaz comn. Cuando ste 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 grfica 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 tcnico, pero caus una autntica revolucin. Las herramientas de este tipo, pueden convertirse, como todas las herramientas, en utensilios tiles o en armas mortferas. Los autores tuvieron la "osada", entonces, de poner el resultado de su trabajo en Internet y permitiendo la distribucin libre de binarios y fuentes. Haba otros programas disponibles libremente como COPS, para probar vulnerabilidades en un slo sistema, o el ISS, para probarlas en sistemas remotos, pero este ltimo, por ejemplo, careca de suficiente funcionalidad y de un interfaz grfico en la versin pblica, aunque s en la versin comercial. Los autores decidieron distribuirlo de forma libre ya que su experiencia les indicaba que los esfuerzos de limitar la

distribucin de informacin 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 polmica, por la cual incluso uno de los creadores fue despedido de su trabajo. SATAN fue concebida como una herramienta para admininistradores, pero tambin poda ser usada como un arma por crackers. Incluso se disearon programas para detectar "ataques" de SATAN, como por ejemplo Courtney (desarollado por CIAC) o Gabriel. El problema entonces, y tambin 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 an no resueltas), para atacar a sistemas que an no se haban actualizado a una versin 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, exportacin de discos via NFS, etc... Estar al tanto de actualizaciones de todos estos y de la forma en que pueden ser usados para obtener informacin 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 distribucin como bugtrack, los avisos del CERT no es fcil y, adems, si no se hace de forma contnua se puede dejar un "agujero" que un intruso puede intentar aprovechar. SATAN abri la polmica al poner en manos de todo el mundo un programa, de fcil uso, que descubriera todas estas vulnerabilidades a un tiempo, a la vez que pona al descubierto informacin sobre las relaciones entre mquinas, lo que los autores denominaron "relacin de Confianza". SATAN obtiene tanta informacin como le es posible de servicios de red como finger, NFS, NIS, ftp y tftp, rexd, y otros. La informacin extrada no slo indica las fuentes por las que un intruso podra ganar informacin del sistema, sino tambin fallos potenciales de seguridad generalmente debidos a una mala configuracin 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 informacin inicial y con un conjunto de reglas configurables por el usuario, las relaciones de dependencia entre mquinas o servicios dados de una a otra. Esto hace posible el anlisis 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 permitarn 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 autorizacin debida. Si el sistema X confa en el Y, un intruso que pueda poner en peligro Y podr tambin poner en peligro X. Los autores indican que cualquier tipo de confianza puede ser subvertida, no slo 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 mquina y se subvierte el servidor de nombres (el DNS), o si se hace uso de la tcnica de IP spoofing para hacerle creer a X que otra mquina 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 Hay que decir que SATAN es una herramienta que podra considerarse ya obsoleta, las vulnerabilidades que intenta descubrir, eran comunes (y conocidas) cuando fue diseada, 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 mquina. Sin embargo, donde an s resulta til SATAN es en la funcin de recopilacin de informacin y en la aplicabilidad del concepto de confianza. EJECUCIN DE SATAN SATAN debe ser ejecutado como usuario root (superusuario) ya que algunos de los tests que realiza necesita los requisitos de este usuario para funcionar (ver listado 2 . Hace uso, por ejemplo, de sockets abrindolos 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 funcionarn en absoluto. Han existido algunos problemas a este respecto en la distribucin de SATAN, ya que si el programa se ejecuta como superusuario, y el cdigo fuente est disponible, es posible que algn desaprensivo distribuya una versin de SATAN "modificada" de forma que, al ejecutarla, se introducira un troyano en el sistema, es decir, la copia modificada realiza ms de lo que debera, enviando informacin, 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 estn programados los scripts que generan las pginas automticamente y algunos de los tests) y un navegador de WWW, bien sea textual (Lynx) o grfico (Netscape Navigator o similares, para ms navegadores ver el artculo "Navegadores de WWW para GNU/Linux", aparecido en Linux Actual nmero 3). Los programas que realizan las tareas de prueba sobre los diversos sistemas se escribieron en C, perl o lenguaje de la shell, utilizando cdigo disponible en los grupos de noticias (comp.sources.misc.*), y de hecho es posible aadir nuevos programas a todo el conjunto de la herramienta. Otras herramientas posteriores, como SAINT, que se comentarn ms adelante, o NESSUS, que se comentar en un artculo en el

prximo nmero de la revista, hacen ms fcil el introducir nuevos programas mediante la descripcin de reglas. Cuando se arranca el programa, ste obtiene la configuracin de los ficheros localizados en el directorio config/. Estos ficheros indican dnde se encuentran herramientas habituales en entornos UNIX (como finger o ping) as como el navegador de WWW que se utilizar (almacenado en la variable $MOSAIC). Estas herramientas sern utilizados por los diversos programas de los que est compuesto SATAN, y se pueden configurar a mano o bien utilizando el script proporcionado por los autores (reconfig), que busca la localizacin 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 pgina 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 escner 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 slo uso que SATAN genera para cada ejecucin. Dado que esta llave se guarda en los ficheros HTML generados por SATAN, es importante que estos ficheros tengan permisos de lectura slo 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 informacin disponible sobre los escners realizados por el superusuario mientras SATAN est siendo ejecutado. En la seleccin de Objetivos el usuario puede seleccionar el nivel de ataque: Ligero, Normal o Duro. Un ataque "Ligero" slo 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 3 ). 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 nmero de servidores a probar. Adems muestra de forma grfica 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 ms grfica (quizs a travs de un grafo) las interrelaciones entre los servidores. Existen adems tutoriales que dan informacin ms en detalle de los problemas concretos de algunas de las vulnerabilidades, que son tiles para que el administrador busque ms informacin antes de tomar una decisin sobre cmo arreglar el problema. Toda la informacin recopilada sobre las distintas mquinas se almacena en una base de datos (se puede tener ms de una base de datos sobre mquinas), que se mantiene entre ejecuciones del programa, y es til para inferir relaciones entre

mquinas

que

las

pueda

hacer

vulnerables.

Adems SATAN es configurable con reglas (en el directorio facts/) que le permiten inferir nueva informacin y detonar nuevos tests en funcin de los servicios que se ofrezcan. Estas reglas estn escritas en Perl y, a travs de ellas se puede extender el programa con nuevos tests. De hecho la decisin de qu test realizar en funcin de la informacin recibida se encuentra en estas reglas. COMPILAR SATAN PARA LINUX SATAN no fue desarrollado originalmente para GNU/Linux, sino que su documentacin 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 cdigo fuente para hacerlo funcionar con la versin de la librera de C de GNU/Linux. Aunque los cambios difieren para libc5 y para libc6, bsicamente debido a la redefinicin de la implementacin de los formatos de paquete de IP e ICMP en la librera estndar. Esto se puede arreglar modificando el fichero lcompat.h (que funciona para libc5) y comentando toda la definicin 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 cdigo 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 versin que se distribuye en el CD las cabeceras de las libreras proporcionadas por los autores han sido modifcadas por las cabeceras de la libc6, an as tambin se entrega un fichero (satanlib.diff.linux) con las diferencias entre ambas. Finalmente, para adaptarse a los "nuevos tiempos" y usar los mdulos de Perl instalados en el sistema en lugar de los proporcionados por el programa (como es el caso del mdulo que proporciona en Perl la funcin getopts o ctime), es necesario cambiar ligeramente el programa principal (satan) y algunos de los tests, que estn escritos en Perl. Tambin 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 versin 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 pgina de manual). En general, un usuario que instale SATAN dentro de una distribucin de GNU/Linux no tendr que resolver estos problemas, dado que los responsables de la distribucin, presumiblemente, los habrn resuelto para que se integre dentro de sta. Sin embargo no est de ms 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 mximos 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 raz, ejecutar make linux seguido de perl reconfig. Posteriormente se puede configurar los valores que ha obtenido automticamente editando directamente, como ya se ha dicho antes, los ficheros en el subdirectorio config/. Toda la informacion de SATAN en: http://www.porcupine.org/satan/

ABACUS PORTSENTRY
Algunas herramientas pueden detectar "portscans" o intrusiones. Un administrador "standard" (es decir, paranoico!) NO puede trabajar sin sta categora de herramientas. La primera serie de herramientas viene del Proyecto Abacus, y pueden obtenerlas desde http://www.psionic.com. Tres herramientas estn disponibles: logcheck, portsentry y hostsentry. Logcheck est en versin 1.1.1, portsentry es 1.0 y hostsentry es la versin 0.0.2 alpha. Portsentry es una herramienta de deteccin de "portscan". Como dice su nombre, cuando un puerto es "scanned" desde alguna parte, portsentry bloquea el host en seguida, ya sea "cerrando" la ruta con el firewall (o una direccin IP no utilizada), ya sea escribiendo la direccin IP del atacante en el fichero /etc/hosts.deny si tienen TCPWrapper en su mquina. El resultado es eficaz de verdad! Portsentry se basa en un fichero de configuracin principal y en unos ficheros especficos. Estos ltimos se usan para ignorar unos "hosts" (es decir para no bloquearlos) o para bloquear unos puertos de unos "hosts". Desde el fichero de configuracin, pueden definir la manera de trabajar de portsentry. Tienen que elegir los puertos que quieren atar a portsentry, puertos TCP o UDP (o ambos). Cuidado con atar el puerto 6000 si usan X11! Segn el sistema Unix que usan, pueden tener dos modos de operacin para vigilar los puertos. El modo avanzado slo funciona en Linux (por el momento). Despus tienen que decidir de la opcin de bloqueo: no bloquean los "scans", los bloquean, o ejecutan un comando externo. Siguen eligiendo la manera de "echar" la ruta, sea redirigiendo el atacante hacia una direccin IP no utilizida en la red, sea hacia un filtro de paquetes (firewall). La etapa siguiente concierne TCPWrappers. Es decir, deciden (o no) escribir un texto DENY en el fichero /etc/hosts.deny. Por fin, pueden definir un comando externo para ejecutar y pueden elegir un valor por el scan (por defecto es 0; 1 o 2 permiten reducir alarmas falsas). Es todo lo que tienen que hacer! Suponemos que ya saben todo sobre logging, puesto que, claro, todas las alarmas se escriban en los logs. Significa que pueden modificar el fichero syslog.conf si quieren que las alarmas sean dirigidas hacia otro lugar que /var/log/messages o /var/log/syslog o /var/adm/messages... Ahora pueden arrancar portsentry en tarea de fondo con la opcin preferida. Las opciones

disponibles depienden del sistema: podrn usar -tcp, -udp en la mayora de los Unixes y -atcp, -audp bajo Linux ("a" por avanzado).

Si eres un sysadmin que mira los logs una vez a la semana (mejor sera probar otro empleo) el proyecto Abacus te propone otra herramienta llamada logcheck. Se arranca desde una tarea cron y manda un correo al administrador si encuentra algo extrao en los logs. Informacion encontrada en: http://www.linuxfocus.org/Castellano/January2001/article180.shtml

INSTALACIN Y CONFIGURACIN DE PORTSENTRY (LINUX) Ir al directorio donde ha descargado portsentry portsentry mv * / tmp tar-zxvf portsentry * cd portsentry-1.0 (directorio instalado) Usted debe leer README.install, porque tienes que configurar algunos archivos antes de compilarlo. Si intenta este proceso, y an as no parece funcionar, o no est haciendo lo que quiere, o lo que desea es ver lo que tengo en la ma, te invitamos a ver a mi archivo de configuracin: portsentry.conf (deberan estar en / usr / local / baco / portsentry) make linux make install Se recomienda la edicin portsentry.ignore y aadiendo la siguiente lnea: 192.168.0.0:24 Esto no har caso de su red domstica y todo funcionar mucho mejor. EJECUCIN DE PORTSENTRY Para empezar a portsentry, escriba: portsentry-stcp portsentry-sudp