ASEGURANDO SERVICIOS DE RED, UTILIZANDO TCP WRAPPERS EN LINUX

Transcripción

1 Universidad Metropolitana Facultad de Ingeniería Escuela de Ingeniería de Sistemas ASEGURANDO SERVICIOS DE RED, UTILIZANDO TCP WRAPPERS EN LINUX Gianfranco Samuele Luigi Vellucci Tutor: Ing. Ricardo Strusberg Caracas, Marzo 2001

2 DERECHO DE AUTOR Cedo a la Universidad Metropolitana el derecho de reproducir y difundir el presente trabajo, con las únicas limitaciones que establece la legislación vigente en materia de autor. En la ciudad de Caracas, a los 28 días del mes de febrero de 2001 Gianfranco Samuele Luigi Vellucci

3 APROBACIÓN Considero que el Trabajo de Grado titulado Asegurando servicios de red con los TCP Wrappers en Linux Elaborado por los ciudadanos Gianfranco Samuele Luigi Vellucci Para optar por el título de INGENIERO DE SISTEMAS Reúne los requisitos exigidos por la Escuela de Ingeniería de Sistemas de la Universidad Metropolitana, y tiene meritos suficientes como para ser sometido a la presentación y evaluación exhaustiva por parte del jurado examinador que se designe. En la ciudad de Caracas, a los 28 días del mes de marzo de 2001 Ing. Ricardo Strusberg

4 ACTA DE VEREDICTO Nosotros, los abajo firmantes, constituidos como jurado examinador y reunidos en Caracas, el día de Marzo de 2001, con el propósito de evaluar el Trabajo de Grado titulado. Asegurando servicios de red, utilizando TCP Wrappers en Linux Presentado por los ciudadanos Para optar al título de Emitimos el siguiente veredicto: Gianfranco Samuele Luigi Vellucci INGENIERO DE SISTEMAS Reprobado Aprobado Notable Sobresaliente Sobresaliente con mención honorífica Observaciones: Ing. Ricardo Strusberg Ing. Vincenzo Mendillo Ing. Teodoro Lobo

5 ÍNDICE DE CONTENIDO ÍNDICE DE CONTENIDO...I LISTA DE FIGURAS...II LISTA DE TABLAS... V RESUMEN...VI INTRODUCCIÓN... 1 I. MARCO TEORICO... 3 I.1 Antecedentes de los TCP Wrappers... 4 I.2 El Demonio Central de Servicios de red (inetd)...18 I.3 El Demonio Manejador del Registro de logs (syslogd)...21 I.4 Definición de los TCP Wrappers (tcpd)...22 I.5 Funcionamiento de los TCP Wrappers...23 I.6 Entornos Gráficos KDE y GNOME...30 I.7 Webmin (Sistema de Administración a Distancia)...33 II. MARCO METODOLÓGICO...40 II.1 Fase de planeación y elaboración...46 II.2 Fase de análisis...54 II.3 Fase de diseño...61 II.4 Fase de construcción...65 III. DESARROLLO...66 III.1 Desarrollo de Kwrapper...66 III.2 Desarrollo del Módulo de TCP Wrappers para Webmin...73 IV. RESULTADOS...81 CONCLUSIONES RECOMENDACIONES GLOSARIO REFERENCIAS BIBLIOGRAFICAS APÉNDICE A.: Archivo de Configuración inetd.conf APÉNDICE B: Características de Linux APÉNDICE C. Qué es Código Abierto? I

6 LISTA DE FIGURAS Figura 1.- El demonio inetd atiende los puertos de red para los servicios ftp, telnet y finger... 6 Figura 2.- El demonio inetd ha dado inicio un proceso servidor telnet que conecta al usuario a un proceso denominado login Figura 3.- El programa servidor de telnet ha sido transferido a otro lugar, y el TCP Wrapper ha tomado su lugar Figura 4.- El programa TCP Wrapper ha iniciado el servidor telnet y no vuelve a participar en la conexión... 8 Figura 5.- Primeras conexiones del cracker observadas con el programa TCP Wrapper... 8 Figura 6.- Archivos útiles en el control de acceso Figura 7.- Un bosquejo de actividades en una red informática Figura 8.- Resultado al aplicarse un proceso de reverso del servicio finger Figura 9.- Ejemplo de una trampa de arena sobre el servicio tftp...15 Figura 10.- Muestra del contenido generado en el archivo de registro de logs, de conexiones rechazadas...15 Figura 11.- Reverso del servicio finger, de un usuario conectado Figura 12.- Intercepción y filtrado de los TCP Wrappers en solicitudes de servicio...24 Figura 13.- Modelo conceptual...55 Figura 14.- Diagrama de secuencia del sistema para el caso de uso proteger servicio Figura 15.- Diagrama de secuencia del sistema para el caso de uso definir política...57 Figura 16.- Diagrama de secuencia del sistema para el caso de uso configuración de reglas...57 II

7 Figura 17.- Diagrama de interacción: administrador sistema...62 Figura 18.- Diagrama de interacción: protección de los servicios con TCP Wrappers...62 Figura 19.- Diagrama de interacción: definición de las políticas de control...63 Figura 20.- Diagrama de interacción: definición de las reglas de control...63 Figura 21.- Diagrama de diseño de clases...64 Figura 22.- Menú principal del Kwrapper...82 Figura 23.- Listado de servicios manejados por el inetd...82 Figura 24.- Pantalla de control de acceso Figura 25.- Pantalla de servicios ofrecidos por webmin...84 Figura 26.- Página principal de los TCP Wrappers en webmin...85 Figura 27.- Detalles del servicio de red...86 Figura 28.- Página donde se añade una regla...87 Figura 29.- Página donde se modifica una regla...88 Figura 30.- Resultado de ejecutar telnet desde la IP en prueba 1-A...92 Figura 31.- Resultado de ejecutar ftp desde la IP en la prueba 1-A...93 Figura 32.- Resultado de ejecutar telnet desde la IP en la prueba 1-A...93 Figura 33.- Resultado de ejecutar ftp desde la IP en la prueba 1-A...94 Figura 34.- Resultado de ejecutar telnet desde la IP en la prueba 1-B Figura 35.- Resultado de ejecutar ftp desde la IP en la prueba 1-B III

8 Figura 36.- Resultado de ejecutar telnet desde la IP en la prueba 1-B...95 Figura 37.- Resultado de ejecutar ftp desde la IP en la prueba 1-B Figura 38.- Archivo /etc/security/banners/allow/in.telnetd...97 Figura 39.- Archivo /etc/security/banners/deny/in.telnetd...97 Figura 40.- Resultado de ejecutar telnet desde la IP en la prueba 2-A...98 Figura 41.- Resultado de ejecutar ftp desde la IP en la prueba 2-A...98 Figura 42.- Resultado de ejecutar telnet en la prueba 2-A, desde la IP Figura 43.- Resultado de ejecutar ftp en la prueba 2-A, desde la IP Figura 44.- Resultado de la ejecución del comando spawn enviando un IV

9 LISTA DE TABLAS Tabla 1.- Ejemplo de pares cliente-servidor bajo protocolo TCP/IP y sus aplicaciones... 6 Tabla 2.- Wildcards en los archivos de control de acceso...26 Tabla 3.- Sintaxis para definir clientes en los archivos de control de acceso...27 Tabla 4.- Comandos que extienden las capacidades de los archivos de control de acceso...28 Tabla 5.- Variables que recolectan información del cliente y del servidor Tabla 6.- Caso de uso proteger servicio...52 Tabla 7.- Caso de uso definir política de control de acceso a servicios Tabla 8.- Caso de uso configurar el control de acceso a servicios Tabla 9.- Contrato seleccionar servicio Tabla 10.- Contrato wrapp servicio...58 Tabla 11.- Contrato seleccionar política control...59 Tabla 12.- Contrato activar política de control...59 Tabla 13.- Contrato especificar cliente Tabla 14.- Contrato especificar comandos Tabla 15.- Contrato activar regla V

10 RESUMEN Asegurando servicios de red utilizando TCP Wrappers en Linux Autores: Gianfranco Samuele Luigi Vellucci Caracas, Febrero 2001 El presente informe describe la investigación realizada para el diseño y desarrollo de dos aplicaciones que tienen como función específica, facilitar por medio de una interfaz visual el manejo y configuración de una herramienta de seguridad denominada TCP Wrappers. Esta herramienta tiene la capacidad de definir las restricciones de acceso a los diferentes servicios de red que provee un host específico. Los objetivos específicos de este trabajo fueron: proveer una interfaz visual, con capacidad de conexión interplataforma para la gestión de los TCP Wrappers, proveer los mecanismos para la administración y consulta de las listas de restricciones de control de acceso y bitácora de las conexiones UDP y TCP manejadas por el demonio inetd y desarrollar una herramienta independiente de la distribuciones Linux existentes. Con el propósito de cumplir dichos objetivos se realizó un estudio del funcionamiento de los TCP Wrappers utilizando la metodología UML y el uso como plataforma base para el desarrollo de este trabajo el sistema operativo Linux en conjunto con lenguajes de programación tales como: PERL, HTML, Python y GTK. El contenido del presente informe tiene como base fundamental el conocimiento para definir reglas de restricciones en los archivos de control de acceso de los TCP Wrappers; igualmente fue necesario comprender la estructura del sistema de administración a distancia (webmin), y el conocimiento básico acerca de los entornos gráficos más utilizados en Linux tales como: KDE y GNOME. VI

11 INTRODUCCIÓN Con el constante avance de la tecnología, la necesidad casi obligada de obtener y hacer uso de la información en forma instantánea, ha generado en la sociedad actual una necesidad de estar conectado en red bien sea para realizar actividades laborales, de entretenimiento, búsqueda de información o simplemente para estar actualizado con el mundo que nos rodea. Sin embargo, debido a la gran cantidad de personas que hoy en día pueden tener acceso a los diferentes sistemas de computación, en ocasiones se hace uso de este medio informático para ejercer acciones que violentan los diferentes sistemas computacionales existentes. Es por ello que surge la necesidad de incrementar y mejorar los sistemas de seguridad en el cual se ven involucradas peticiones de servicio de red emitidas por un cliente y la respuesta a los servicios solicitados por parte del sistema, de modo que no exista o sea casi nulo el riesgo de ataques informáticos. Debido a esta problemática, aparece la necesidad de establecer un esquema de seguridad para el control y acceso a los servicios dentro de un sistema. Entre los mecanismos existentes, uno de estos se denomina TCP Wrappers, el cual funciona en diferentes sistemas operativos basados en UNIX. El mismo representa la base fundamental para la elaboración del presente trabajo. Los TCP Wrappers tienen como función principal controlar el acceso a los diferentes servicios de red que ofrece un sistema específico, el cual utiliza ciertos mecanismos esenciales al momento de ocurrir una solicitud de un servicio de red para posteriormente prestar dicha petición. A partir de este

12 hecho surge otra necesidad, como es la de disponer de una interfaz gráfica la que funcione en forma local y a distancia, que tenga como finalidad permitir la configuración y manejo de los TCP Wrappers. Debido a esto, los objetivos planteados para el siguiente trabajo fueron: Desarrollar una interfaz sobre el sistema operativo Linux que funcione bajo los dos entornos gráficos de gran estabilidad y mayor crecimiento tales como: KDE y GNOME. Crear un módulo dentro de la aplicación de administración a distancia Webmin que permita el manejo y control de los TCP Wrappers a distancia. Facilitar las consultas a los archivos que registran la bitácora de acceso a los diferentes servicios que son protegidos por los TCP Wrappers. Es conveniente, para establecer un nivel de seguridad confiable en el área de redes, hacer uso de varios mecanismos de seguridad que se complementen entre sí para reducir los riesgos de ataque. 2

13 I. MARCO TEORICO En este capítulo se exponen los diferentes tópicos que sirvieron de base para la realización de este trabajo. Previo a describir el proceso de desarrollo de las herramientas que permiten el manejo de los TCP Wrappers, se expone la información necesaria a evaluar y de esta manera justificar las diferentes decisiones que se tomaron en el diseño e implementación de las aplicaciones que se presentan en este trabajo. Los tópicos que integran este capítulo son los siguientes: Antecedentes de los TCP Wrappers: En esta sección se describe la historia que fundamenta la elaboración del programa principal de los TCP Wrappers. Definiciones y funciones del demonio central de Servicios de red (inetd) y el demonio 1 manejador del registro de logs (syslogd): En esta sección se explican las definiciones de los demonios inetd y syslogd y sus respectivas funciones dentro de la ejecución de los TCP Wrappers. Definición de los TCP Wrappers (tcpd): Se explica el funcionamiento del demonio tcpd y los archivos que se utilizan para la configuración de los TCP Wrappers. Entornos gráficos KDE y GNOME: En esta sección se muestra una breve explicación acerca de los entornos gráficos que son los más utilizados 1 Programa que se ejecuta en background en sistemas UNIX 3

14 por su robustez y estabilidad. Sistema de Administración a Distancia (Webmin): En esta sección se especifican los pasos a seguir para la construcción de módulos para Webmin, así como las diversas funciones que pueden ser ejecutadas en esta aplicación. I.1 Antecedentes de los TCP Wrappers A mediados de 1991, Wietse Venema [V93] presenció en repetidas oportunidades una acción lesiva o ataque. Él relata que en la Universidad de Tecnología de Eindhoven en Holanda fue víctima de un fuerte ataque de un cracker informático quien había logrado adquirir permisos de root dentro del sistema en reiteradas ocasiones. Esta situación es considerada un problema grave en la seguridad de la universidad, ya que el cracker tenía ciertos conocimientos de comandos que utilizados por error o con malas intenciones pueden causar severos daños y/o pérdidas considerables al sistema operativo. Uno de los comandos preferidos ejecutados por el cracker fue el rm -rf /, el cual representa una ejecución tan destructiva como el comando format en MS-DOS. Usualmente el daño es reparable mediante la recuperación de los datos a través de los denominados backups o cintas y/o dispositivos de respaldo, pero aún así los afectados pierden gran parte del trabajo realizado hasta ese momento. 4

15 Estos incidentes provocaron un arduo proceso de investigación con el objetivo de conocer la procedencia del individuo autor de los daños ocasionados al sistema. La investigación se tornó compleja debido a que el cracker eliminaba todo tipo de trazas o huellas de forma efectiva. Fue uno de los hallazgos de la investigación fue que el cracker vigilaba el comportamiento de los usuarios en la red haciendo uso del servicio denominado finger. Este ofrece información acerca de los usuarios del sistema. Para la ejecución del servicio finger no es requerida una clave de acceso y no es común mantener una bitácora de las diferentes acciones del mismo, lo que explica el hecho de que sus operaciones con el servicio finger permanecieran sin ser detectadas por el administrador del sistema. La reacción natural ante este problema, normalmente, es la de eliminar o no proveer el servicio de finger dentro del sistema operativo y red de computadores en cuestión. Sin embargo, se decidió que sería mucho más productivo mantener el servicio e investigar la procedencia de las peticiones al servicio finger. Para ilustrar la situación del problema y su solución, se procederá a definir con ciertos detalles una típica implementación de los servicios de red bajo protocolo TCP/IP en sistemas operativos UNIX. La mayoría de las aplicaciones que hacen uso del protocolo TCP/IP se basan en el modelo denominado cliente-servidor. Por ejemplo, cuando alguien hace uso del comando telnet para conectarse a un host, se ejecuta un proceso interno que realiza las funciones de un servidor telnet, y a su vez este proceso servidor posteriormente conecta al usuario a un proceso de 5

16 login. Algunos ejemplos de parejas cliente-servidor se muestran en la tabla 1. Cliente Servicio Aplicación Telnet telnetd Login remoto. Ftp ftpd Transferencia de archivos. Finger fingerd Información de los usuarios Systat systatd Información de los usuarios. Tabla 1.- Ejemplo de pares cliente-servidor bajo protocolo TCP/IP y sus aplicaciones. El camino usual para la ejecución es el de ejecutar un proceso denominado demonio el cual espera por todo tipo de conexiones entrantes a la red de computadores. Al momento en el cual se establece una conexión, este demonio (usualmente llamado inetd) ejecuta la aplicación que responde a la petición emitida por el cliente y posteriormente regresa a su estado inicial, a la espera de otras peticiones de servicios por parte de otras conexiones (véase figura 1 y figura 2). ftp user telnet client telnet inetd finger Figura 1.- El demonio inetd atiende los puertos de red para los servicios ftp, telnet y finger. 6

17 user telnet client telnet server login Figura 2.- El demonio inetd ha dado inicio un proceso servidor telnet que conecta al usuario a un proceso denominado login. Volviendo al relato anterior, cómo se podía obtener el nombre del host desde el cual el cracker realiza todas sus operaciones de espionaje?, a primera vista esto requeriría de cambios en los software de red existentes, sin embargo, existían algunos problemas para realizar estos cambios: No se tenía la licencia sobre el código fuente para los sistemas Ultrix, SunOS, y otras implementaciones de UNIX. Aunado a esto, tampoco se tenía el código fuente. El código fuente de la red de computadores de Berkeley (sobre el cual la mayoría de las implementaciones de redes comerciales UNIX TCP/IP son derivadas) estaba disponible, pero adaptarlo a este ambiente de trabajo requería de un esfuerzo considerable horas hombre de trabajo. Se requería una solución que resultara eficaz y que no implicara cambios en el software existente y que, eventualmente podría aplicarse en todos los sistemas UNIX. Se realizó un intercambio entre programas, se instalarían en otro computador ubicado en otro sitio los programas servidores de red ofrecidos por el fabricante y se instala un programa trivial en el lugar original en los cuales éstos residían. Al momento de ocurrir una conexión, este programa trivial sólo registraría el nombre del remote host (véase figura 3) y luego ejecutaría el programa servidor de red original que ha sido 7

18 solicitado (véase figura 4). user telnet client tcp wrapper logfile Figura 3.- El programa servidor de telnet ha sido transferido a otro lugar, y el TCP Wrapper ha tomado su lugar. user telnet client telnet server login Figura 4.- El programa TCP Wrapper ha iniciado el servidor telnet y no vuelve a participar en la conexión. Wrappers. Esta herramienta resultaría ser la primera versión de los TCP May 21 14:06:53 tuegate: systatd: connect from monk.rutgers.edu May 21 16:08:45 tuegate: systatd: connect from monk.rutgers.edu May 21 16:13:58 trf.urc: systatd: connect from monk.rutgers.edu May 21 18:38:17 tuegate: systatd: connect from ap1.eeb.ele.tue.nl May 21 23:41:12 tuegate: systatd: connect from mcl2.utcs.utoronto.ca May 21 23:48:14 tuegate: systatd: connect from monk.rutgers.edu May 22 01:08:28 tuegate: systatd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:14:46 tuewsd: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:15:32 tuewso: fingerd: connect from HAWAII-EMH1.PACOM.MIL May 22 01:55:46 tuegate: systatd: connect from monk.rutgers.edu May 22 01:58:33 tuegate: systatd: connect from monk.rutgers.edu May 22 02:00:14 tuewsd: fingerd: connect from monk.rutgers.edu May 22 02:14:51 tuegate: systatd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 02:19:45 tuewsd: fingerd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 02:20:24 tuewso: fingerd: connect from RICHARKF.TCASSIS.ARMY.MIL May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu May 22 15:08:30 tuegate: systatd: connect from monk.rutgers.edu May 22 15:09:19 tuewse: fingerd: connect from monk.rutgers.edu May 22 15:14:27 tuegate: telnetd: connect from cumbic.bmb.columbia.edu May 22 15:23:06 tuegate: systatd: connect from cumbic.bmb.columbia.edu May 22 15:23:56 tuewse: fingerd: connect from cumbic.bmb.columbia.edu Figura 5.- Primeras conexiones del cracker observadas con el programa TCP Wrapper. 8

19 La primera versión de los TCP Wrappers incluía una cantidad mínima de código. Dado que este programa no intercambiaba ningún tipo de información con el cliente o con los procesos del servicio, esa misma versión pudo ser usada para muchos otros tipos de servicios de red. Como se muestra en la figura 5, cada conexión es registrada con los siguientes campos: fecha y hora de conexión, el nombre del localhost, el nombre del servicio solicitado y el nombre del remote host. Los ejemplos muestran que el cracker no sólo hace uso de terminales servidores por discado (dial-up terminal servers) tales como monk.rutgers.edu, sino que también ha penetrado en sistemas informáticos militares (.MIL) y universitarios (.EDU). El cracker realizó una serie de peticiones a los servicios de finger y systat, con el fin de conocer que usuarios se encontraban activos en los sistemas. Continuamente el cracker realizaba conexiones a través del servicio telnet, presumiblemente para realizar un único intento de conexión mediante un login para luego desconectarse inmediatamente y así evitar que el sistema generase un reporte por repetidos intentos fallidos de acceso. De esta forma, únicamente se podía detectar el lugar donde el cracker realizaba sus acciones delictivas, lo que representó un gran avance sobre el pasado, cuando solamente se sabía que algo había ocurrido. Uno de los problemas de esa solución es que al registrar toda la información de las conexiones y peticiones de servicios de red, se genera una gran cantidad de información dentro del archivo de registro y esto dificultaría la identificación del cracker. 9

20 motivos: Afortunadamente, el cracker fue fácil de rastrear por los siguientes Con frecuencia trabajaba de noche, momento en el cual existe poco movimiento en cuanto a otro tipo de actividades. Continuas conexiones a un número determinado de sistemas. El esparcir sus pruebas, lo ayudaría a esconder sus actividades. Sin embargo, reuniendo los archivos de registro de varios de los sistemas atacados, fue sumamente fácil observar cuándo se encontraba activo el cracker. Ningún otro individuo hacía uso del servicio systat. Por lo tanto se adoptó la siguiente medida: negar todas las conexiones provenientes de terminales de servicios ya abiertos, de tal manera que el cracker podía únicamente atacar o alcanzar un sistema específico a través del ataque a la cuenta de un usuario registrado. El objetivo perseguido era el de lograr que el atacante dejara la mayor cantidad de trazas útiles con el fin de poder conocerlo con mayor detalle. Para llevar a cabo la medida elegida, se generó un mecanismo simple de control de acceso dentro de los TCP Wrappers, de manera que, al momento de ocurrir una conexión proveniente de un terminal la misma era mostrada en los archivos de registro y todo el tráfico proveniente de ese sistema sería bloqueado por el host que estaba siendo objeto de ataque, además se aplicaría la misma medida en los diferentes servidores. Para que esta nueva versión de los TCP Wrappers utilizara las restricciones de acceso 10

21 se hizo uso de dos archivos donde se definen ciertas reglas de bloqueo de servicios de red los cuales son: /etc/hosts.allow y el /etc/hosts.deny /etc/hosts.allow: in.ftpd:all /etc/hosts.deny: ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu ALL: comserv.princeton.edu lewis-sri-gw.army.mil ALL: ruut.cc.ruu.nl ALL: tip-gsbi.stanford.edu ALL: tip-quada.stanford.edu ALL: s101-x25.stanford.edu ALL: tip-cdr.stanford.edu ALL: tip-cromemaa.stanford.edu ALL: tip-cromembb.stanford.edu Figura 6.- Archivos útiles en el control de acceso. El primer archivo (/etc/hosts.allow) mostrado en la figura 6, describe cuál combinación (servicio, host) están permitidas. En este ejemplo, el servicio de transferencia de archivos ftp está garantizado para todos los sistemas. El segundo archivo (/etc/hosts.deny) describe las combinaciones (servicio, host) que están prohibidas. En el caso de los pares (servicio, host) que no concuerden con alguna de las reglas de control de acceso todos los accesos son permitidos. Una vez puesto en funcionamiento la nueva versión de los TCP Wrappers, el cracker no podía atacar haciendo uso de un terminal de servidores de acceso público, lo cual indujo al atacante a utilizar la cuenta de un usuario registrado en el sistema y proceder desde ese punto. 11

22 El siguiente paso fue investigar cuáles cuentas de usuarios se encontraban envueltas en el caso y esto generó la creación de un proceso que consultaría una tabla de sitios "malos" para así enviar el resultado de la ejecución del servicio finger y systat en el momento que alguien realice algún tipo de conexión, lo que daría como consecuencia la posibilidad de observar el cracker de la misma forma que él lo había estado haciendo. Los ejemplos en la figura 7 muestran actividades de un único usuario quien se encontraba conectado al sistema guzzle.stanford.edu. El resultado de ejecutar el servicio finger arrojaría como respuesta que el nombre de la cuenta utilizada es adrian (véase figura 8), y el acceso provino desde el terminal de servidor tip-forsythe.stanford.edu, por lo que el cracker estaba utilizando una cuenta con clave de acceso débil perteneciente al usuario adrian. Jan 30 04:55:09 tuegate: telnetd: connect from guzzle.stanford.edu Jan 30 05:10:02 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:17:57 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:18:24 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:18:34 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:18:38 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:18:44 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:21:03 svin01: fingerd: connect from guzzle.stanford.edu Jan 30 05:24:46 tuegate: systad: connect from guzzle.stanford.edu Jan 30 05:27:20 svin01: fingerd: connect from gloworm.stanford.edu Jan 30 05:33:33 svin01: telnetd: connect from guzzle.stanford.edu Jan 30 05:33:38 svin01: telnetd: connect from guzzle.stanford.edu Jan 30 05:33:41 svin01: telnetd: connect from guzzle.stanford.edu Jan 30 05:33:50 svin01: ftpd: connect from guzzle.stanford.edu Jan 30 05:33:58 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:08 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:34:54 svin01: fingerd: connect from math.uchicago.edu Jan 30 05:35:36 svin01: fingerd: connect from guzzle.stanford.edu Figura 7.- Un bosquejo de actividades en una red informática. 12

23 Wed Jan 30 05:10:08 MET 1991 [guzzle.stanford.edu] Login name: adrian In real life: Adrian Cooper Shell: /phys/bin/tcsh Directory: /u0/adrian On since Jan 29 19:30:18 on ttyp0 from tip-forsythe.stanford.edu No plan. Figura 8.- Resultado al aplicarse un proceso de reverso del servicio finger. Durante algunos meses se identificaron serios ataques realizados a cuentas de usuarios registrados, por lo que continuamente se enviaban avisos a los administradores del sistema y una copia a CERT para mantenerlos informados en cuanto a progresos se refería. CERT sugirió que se contactara a Stephen Hansen de la Universidad de Stanford. Esta persona ya estaba al tanto de la situación, por lo que seguía los pasos del cracker desde hacía algún tiempo, y sus archivos de registro proporcionaron un excelente punto de vista acerca de cómo operaba el cracker. El cracker tenía la ventaja de estar al tanto de muchos de los defectos del software de los sistemas y fue muy persistente en sus intentos de obtener privilegios de root, donde el conseguir el acceso al sistema fue sólo cuestión de encontrar una cuenta con una clave de acceso débil. Por varios meses el cracker hacía uso de la Universidad de Stanford como base para el ataque de un gran número de sitios. Uno de sus objetivos fue research.att.com, los laboratorios de investigación de la compañía AT&T Bell. Al conocer estos ataques, el grupo de sistemas de AT&T le tendieron una trampa de arena, donde le permitieron el acceso a un ambiente altamente protegido por el cual pudieran vigilar todos sus movimientos. 13

24 Los reversos automáticos resultantes del servicio finger ( véase figura 8) han pasado a ser de gran utilidad y en consecuencia se decidió agregar la herramienta finger con los TCP Wrappers. Con este fin, el lenguaje para el control de acceso fue extendido de modo que se le añadieron varios comandos arbitrarios propios de una consola. Una vez concretada la nueva versión del programa, para ejecutar un comando era necesario especificarlo en cada regla luego de definir el servicio y el cliente, esto hizo posible detectar en forma automática algunos tipos de tráfico sospechosos. A lo largo de los meses transcurridos se detectaron constantes peticiones tftp (trivial file transfer protocol) desde sitios muy lejanos. Este tipo de protocolos no requiere de ningún tipo de clave, y es comúnmente usado para descargar software del sistema en estaciones de trabajos que no disponen de unidades de disco o por hardware dedicado a la red de computadores. El uso de este protocolo es muy común en la comunidad cracker ya que el mismo tiene la capacidad de lectura de cualquier archivo del sistema. Basándose en la ejecución constante de peticiones tftp y la nueva versión de los TCP Wrappers, se lograron generar nuevas reglas de acceso con un poco más de complejidad (véase figura 9) y éstas fueron configuradas de tal forma que las peticiones locales al servicio tftp serían administradas de la forma usual, sin embargo las peticiones restantes serían negadas y en ese momento se ejecutaría una instrucción que mandaría por correo electrónico el resultado de haber ejecutado un finger a la persona que intentó la conexión. 14

25 /etc/hosts.allow: in.tftpd:local,.win.tue.nl /etc/hosts.deny: in.tftp: ALL: /usr/ucb/finger 2>&1 /usr/ucb/mail wswietse Figura 9.- Ejemplo de una trampa de arena sobre el servicio tftp. En la figura 9 se muestra, un ejemplo claro de una trampa de arena 2, ya que en el momento en que cualquier usuario intente efectuar el servicio tftp, en el servidor se ejecutara un comando que le aplica el finger al usuario conectado y envía los resultados por correo electrónico a W. Venema Jan 4 18:58:28 svin02 tftpd: refused connect from E MIT.EDU Jan 4 18:59:45 svin02 tftpd: refused connect from E MIT.EDU Jan 4 19:01:02 svin02 tftpd: refused connect from E MIT.EDU Jan 4 19:02:19 svin02 tftpd: refused connect from E MIT.EDU Jan 4 19:03:36 svin02 tftpd: refused connect from E MIT.EDU Jan 4 19:04:53 svin02 tftpd: refused connect from E MIT.EDU Figura 10.- Muestra del contenido generado en el archivo de registro de logs, de conexiones rechazadas. En la figura 10, se muestra un ejemplo de las actividades recientes del servicio tftp. Las peticiones negadas se repetían cada 77 segundos. El intervalo para el reintento depende de la implementación y puede aportar algunos conocimientos o sugerencias acerca del tipo de sistema remoto involucrado. De acuerdo a los resultados obtenidos por el reverso del servicio finger (véase figura 11), sólo una persona se encontraba activa en ese instante: aparentemente, el acceso login provenía de un sistema ubicado en Francia. 2 Procesos o programas que simulan el funcionamiento del servicio que esta siendo comprometido y que permite hacer el seguimiento de las actividades del presunto atacante. 15