"Reforzamiento de la Seguridad de un Sistema Mediante un Mecanismo de Autorización de Comandos" Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. CAMPUS SONORA NORTE. DIVISIÓN DE GRADUADOS E INVESTIGACIÓN. "REFORZAMIENTO DE LA SEGURIDAD DE UN SISTEMA MEDIANTE UN MECANISMO DE AUTORIZACIÓN DE COMANDOS". TESIS. ANTONIO VARELA LIZARDI. NOVIEMBRE DE 2004.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS SONORA NORTE. " R E F O R Z A M I E N T O DE LA S E G U R I D A D DE UN S I S T E M A MEDIANTE UN M E C A N I S M O D E AUTORIZACIÓN DE C O M A N D O S ". Los miembros del Comité de Tesis recomendamos que la presente Tesis del Ing. Antonio Varela Lizardi sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias Computacionales.. Comité de Tesis. Dr. Manuel Galaz Díaz ASESOR. M. en C. Abraham Aldaco Gastélum SINODAL. M. en C. Guadalupe Alexandres García SINODAL.

(3) "REFORZAMIENTO DE LA SEGURIDAD DE UN SISTEMA MEDIANTE UN MECANISMO DE AUTORIZACIÓN DE COMANDOS". ANTONIO V A R E L A LIZARDI. T E S I S P R E S E N T A D A A LA F A C U L T A D DEL ITESM. Este trabajo es requisito parcial para obtener el grado académico de Maestro en Ciencias Computacionales.

(4) Dedicatoria. El producto de este trabajo es resultado de un esfuerzo compartido. Primeramente mis padres y hermana, que son los pilares de mi familia. Finalmente mi esposa y mi hija, quienes hacen que cualquier esfuerzo y sacrificio, por grandes que éstos sean, tengan sentido.. iv.

(5) Reconocimientos. El autor de la presente tesis desea expresar su más sincero y profundo agradecimiento al Dr. Manuel Galaz Díaz, quien con paciencia supo orientarme objetivamente durante la elaboración del presente documento. Su apoyo y enseñanzas han sido incalculables para este trabajo.. De la misma manera, deseo externar el más profundo agradecimiento a mis sinodales, M. en C. Abraham Aldaco y M. en C. Guadalupe Alexandres, quienes formaron parte del Comité Evaluador de la tesis y compartieron con un servidor las experiencias de la investigación realizada en el presente documento.. Por último, pero no en importancia, al ITESM Campus Sonora Norte y especialmente a la Lic. Norma Tapia. Sin su apoyo este documento no hubiera sido posible.. v.

(6) Resumen Uno de los temas principales en seguridad de redes es el proteger a los sistemas contra la penetración de intrusos. La situación se torna más compleja cuando se tienen que tomar medidas contra penetradores internos. Los penetradores internos son aquellos intrusos que tienen acceso al sistema pero que intentan conseguir acceso a información que les está restringida; o bien, aquellos usuarios que utilizan privilegios de acceso concedidos para sus funciones normales en el sistema y hacen uso inapropiado de éstos. La construcción de un sistema 100% a prueba de intrusos no es técnicamente factible y, por lo tanto, deben tomarse medidas a ese respecto. Para prevenir daños por parte de penetradores internos se necesita un mecanismo que actué de manera proactiva también, desde adentro del sistema. El presente trabajo de investigación propone la utilización de un protocolo, parte de los estándares de Internet, con el fin de construir un mecanismo de autorice o niegue la ejecución de comandos iniciados por penetradores internos. Este mecanismo es efectivo incluso cuando se trata de usuarios con privilegios de acceso privilegiados. Además, este mecanismo genera, automáticamente, una bitácora donde se registran las solicitudes de comandos restringidos y los asocia a las claves de los usuarios que los iniciaron. Esta bitácora es pieza clave del éxito de los sistemas de auditoria de seguridad. La presente tesis aporta, como contribución original, la utilización del protocolo T A C A C S para el mejoramiento de la seguridad en servidores y no en equipos de redes, para lo cual fue concebido originalmente.. vi.

(7) Tabla de contenido 1. 2. 3 4. 5. 6. Introducción 1 1.1 Descripción del problema 1 1.2 Alcances 2 1.3 Solución propuesta 2 1.3.1 Objetivos de la solución propuesta 3 1.4 Descripción de la experimentación 3 1.5 Descripción de los capítulos siguientes 3 Revisión bibliográfica 5 2.1 Firewalls 5 2.2 Tipos de intrusos 6 2.3 La paradoja de la seguridad 7 2.4 Móvil de un intruso 8 2.5 Detección de Intrusos 9 2.6 Trampas 11 Metodología de investigación 12 Solución propuesta 14 4.1 El servidor de autorización 15 4.1.1 Declaración de usuarios y grupos de usuarios 16 4.1.2 Declaración de la autorización de comandos 17 4.2 El sistema de solicitud de autorización 18 4.3 Ventajas de la solución propuesta 21 Modelo de experimentación 22 5.1 Experimento #1: Prevenir la visualización de las variables de operación del servidor. 23 5.2 Experimento #2: Prevenir que el usuario modifique las variables de ejecución 29 5.3 Experimento #3: Restringir la ejecución de una instrucción SQL básica 32 5.4 Experimento #4: Restringir el acceso y modificación de una pieza específica de información 33 Conclusiones y recomendaciones 37 Glosario de acrónimos 39 Bibliografía y referencias de Internet 40 Vita 41. vii.

(8) Lista de Figuras Figura 1. Intentos fallidos de acceso a un sistema Figura 2. Declaración de usuarios y grupos de usuarios Figura 3. Seudo código para establecer comunicación con el servidor de autorización Figura 4. Ejecución de "show all" Figura 5. Registro en la bitácora del comando "show all" Figura 6. Ejecución de show server_version Figura 7. Ejecución de fallida del comando show max_connections Figura 8. Ejecución de exitosa del comando show max_connections Figura 9 Cambio de Identidad de Usuario Figura 10. Negación de la ejecución del comando S E T Figura 11. Cambio de password para el agente 300 Figura 12. Cambio de password para el agente 201 Figura 13. Mostrar el password para el agente 300. 7 16 20 24 24 26 26 28 30 31 34 35 35. Lista de Tablas Tabla 1. Descripción de la Tabla Filiales Tabla 2. Descripción de la Tabla Agentes. viii. 23 23.

(9) Lista de Figuras Figura 1. Intentos fallidos de acceso a un sistema Figura 2. Declaración de usuarios y grupos de usuarios Figura 3. Seudo código para establecer comunicación con el servidor de autorización Figura 4. Ejecución de "show all" Figura 5. Registro en la bitácora del comando "show all" Figura 6. Ejecución de show server_version Figura 7. Ejecución de fallida del comando show max_connections Figura 8. Ejecución de exitosa del comando show max_connections Figura 9 Cambio de Identidad de Usuario Figura 10. Negación de la ejecución del comando S E T Figura 11. Cambio de password para el agente 300 Figura 12. Cambio de password para el agente 201 Figura 13. Mostrar el password para el agente 300. 7 16 20 24 24 26 26 28 30 31 34 35 35. Lista de Tablas Tabla 1. Descripción de la Tabla Filiales Tabla 2. Descripción de la Tabla Agentes. viii. 23 23.

(10) 1. Introducción.. La segundad de los sistemas de cómputo está tomando más importancia día con día, tanto en el ámbito de hardware como en el software. La tecnología ha evolucionado a una velocidad impresionante, pero también ha ocurrido lo mismo con los usuarios. La tendencia actual es de sistematizar y ofrecer servicios y prestaciones "en línea" tanto de organizaciones privadas como instituciones de gobierno. Actividades como exhibición de productos, ventas, servicios bancarios y trámites gubernamentales entre otros, son comunes en la actualidad. Próximamente servicios como telefonía y video digitales se establecerán de manera permanente en las redes de datos. Ante estas situaciones, la seguridad en los sistemas computacionales es un aspecto cada vez más crítico en nuestros días debido a que el Internet se ha vuelto en un medio generalizado para realizar operaciones comerciales desde cualquier rincón del planeta, siempre y cuando se tenga una terminal con la conectividad necesaria. De ahí que los sistemas corporativos se hallen vulnerables a ataques de usuarios furtivos o "hackers" como comúnmente se les conoce en inglés. A estos usuarios furtivos se les atribuyen verdaderas catástrofes corporativas ya que son capaces de generar caos en los sistemas, dejando a su paso cuantiosas pérdidas económicas. Este trabajo de investigación trata el problema de la intrusión de usuarios furtivos y propone una manera de proteger los activos computacionales de una empresa mediante la utilización de un protocolo de autorización de comandos en los servidores de red.. 1.1 Descripción del problema. Un sistema de información corporativo ("Enterprise Information System" o EIS, por sus siglas en inglés) generalmente cuenta con las siguientes características. a. S e encuentra interconectado a alguna tecnología de transmisión de datos, típicamente redes de datos convencionales basadas en cables de cobre o fibra óptica utilizando algún protocolo de Internet como TCP/IP. b. Está diseñado para poder atender solicitudes de muchos usuarios de manera concurrente. c. Las solicitudes de los usuarios llegan y se despachan a través de los medios descritos en el punto a. d. Típicamente está interconectado a otros EIS a través de los medios descritos en el punto a.. 1.

(11) 2. Tales características son sumamente importantes, porque permiten la integración de información con sistemas y usuarios remotos. Dicho en otras palabras, es una tecnología muy frecuentemente utilizada como apoyo a la toma de decisiones. Sin embargo, no todos los posibles usuarios remotos o locales de una organización necesitan tener acceso al EIS. Incluso, de entre de los usuarios que tienen permitido el acceso, sólo algunos tienen acceso a todos los componentes del EIS. Esta situación se torna mas complicada en ambientes donde el sistema tiene que operarse a través de Internet, donde además es difícil evitar el anonimato de los usuarios. Hay negocios muy rentables cuya operación depende totalmente de sistemas de cómputo que desempeñan sus funciones en un ambiente preponderantemente hostil, como lo es el Internet. Los usuarios que operan los EIS son de diferentes niveles, y tienen funciones y responsabilidades diferentes. Lamentablemente, intrínseco al ser humano están una serie de comportamientos no deseables que van desde la simple curiosidad hasta la ambición, los cuales se convierten en poderosa justificación necesaria para que un usuario intente accesar partes del sistema que no le conciernen y/o para las cuales no se le ha conferido la autorización debida. El problema lo identificamos como la necesidad de mantener confinado a un usuario dentro de las acciones que se le tengan permitidas realizar, así como dentro de la naturaleza de la información que tenga permitido accesar en un sistema EIS.. 1.2 Alcances. Durante la presente investigación, se desarrollará un software prototipo que ayudará a confinar a un usuario o proceso dentro de sus límites de acción y acceso a la información. El sistema será flexible en su configuración de restricciones, basado en expresiones regulares. Será posible adaptarlo a una gran variedad de situaciones con un mínimo de modificaciones. Además, se proporcionará un registro con información útil para un Sistema de Detección de Intrusiones.. 1.3 Solución propuesta. La presente investigación adaptará tecnología existente en el mercado, y se basa en un mecanismo de autorización de acciones o comandos que ayuda a incrementar la seguridad de un sistema. El valor agregado de la solución consiste en ofrecer un mecanismo sencillo y con un nivel más flexible que aquellos que regularmente se ofrecen en los sistemas convencionales..

(12) 3. 1.3.1. Objetivos de la solución propuesta.. El objetivo primordial del presente estudio es reforzar la seguridad de un sistema que sea capaz de: •. Proveer un mecanismo de defensa proactivo, capaz de regular y restringir la actividad de los usuarios del sistema en función de las acciones que se pretendan ejecutar, complementando los mecanismos de seguridad estándares de los sistemas.. •. Generar un registro de eventos, con la descripción de las actividades intentadas y/o autorizadas de los usuarios, que será útil para un sistema de Detección de Intrusos.. 1.4 Descripción de la experimentación. La verificación de la consecución del objetivo del presente trabajo de investigación se basa en una experimentación que consistirá en adaptar la solución propuesta a un programa de uso común, con el fin de incrementar la seguridad de acceso en el mismo. Se desarrollarán las bibliotecas de funciones en lenguaje Java y se modificará una aplicación de escritorio implementada en Java que accesa un servidor de bases de datos S Q L mediante J D B C . Se configurará el sistema para prevenir accesos a información contenida en el servidor de bases de datos de tal manera que, utilizando los medios normales del servidor para proteger la información, no sea posible conseguir el mismo resultado.. 1.5 Descripción de los capítulos siguientes. A continuación se presenta una lista de los capítulos adicionales que se incluyen en este trabajo de investigación. •. Capítulo 2, Revisión Bibliográfica: Definición de conceptos fundamentales de seguridad, riesgos de seguridad, intrusos y tipos de intrusos, así como la identificación del tipo de intruso que se está deseando contrarrestar con la solución propuesta.. •. Capítulo 3, Metodología: Incluye la lista de actividades necesarias para la realización de este trabajo de investigación.. •. Capítulo 4. Solución Propuesta: Presenta una descripción detallada de los componentes de la solución propuesta.. •. Capítulo 5. Modelo Experimental: Presenta una descripción de la experimentación necesaria para verificar que la solución propuesta cumple con el objetivo de reforzar la seguridad de un sistema.. •. Capítulo 6. Conclusiones y Recomendaciones: Presenta una lista de conclusiones derivadas del trabajo de investigación, así como una serie de.

(13) 4. recomendaciones encaminadas a generar ideas iniciales para la realización de trabajos de investigación posteriores..

(14) 5. 2. Revisión bibliográfica. Muchas Organizaciones dependen de la operación sistemas de cómputo desde sitios de Internet, manteniéndolos expuestos a diversos tipos de ataques. Internet representa actualmente el escaparate comercial de miles de empresas y, por lo mismo, no es factible ocultar esos servicios del público en una política de "Seguridad a través de la oscuridad". Los métodos convencionales utilizados para reforzar la seguridad de un sistema se describen a continuación.. 2.1 Firewalls. Es posible resguardar a un sistema construyendo barreras al rededor del mismo. Estas barreras usualmente están fuera del sistema que deseamos proteger, y uno de los casos es la configuración de un Firewall. Un Firewall se define como una colección de componentes colocados entre dos redes, y que conjuntamente cumplen con los siguientes requisitos [6]: •. Todo el tráfico que fluye por la red debe pasar forzosamente por el Firewall.. •. S e ¡mplementan políticas para filtrar el tráfico que entra y sale de la red.. •. El Firewall en sí debe ser invulnerable .. 1. Una parte del mecanismo se establece en los ruteadores que componen la configuración de una red. Se filtran paquetes de capa 4 basados en T C P y UDP, y otros protocolos de nivel 3 como ICMP. Los filtros son aplicados ya sea para paquetes entrantes o paquetes salientes en uno o varios criterios: •. Dirección IP origen y/o destino.. •. Puerto T C P / U D P origen y/o destino.. •. Banderas de estado de conexión (solamente T C P ). •. Interfaz de entrada o de salida.. Un Firewall correctamente configurado puede ser un filtro eficiente para conexiones iniciadas por usuarios remotos, como una medida preventiva. Sin embargo, esta medida no es suficiente porque no todos los usuarios potencialmente peligrosos provienen de conexiones remotas. En este punto es conveniente definir a los tipos de intrusos.. 1. A l menos en teoría. Durante el diseño de un firewall, también se toman en cuenta situaciones en donde se comprometen los componentes esenciales..

(15) 6. 2.2 Tipos de intrusos. La definición básica de intruso trata de perfilar a un usuario que ya se encuentra dentro del sistema. Por ejemplo podemos mencionar a usuarios curiosos que intentan conocer información de otras áreas, o bien un alumno que pretende "mejorar" su calificación, o lo que es peor aún: Un usuario administrador que hace mal uso de sus privilegios de acceso. Anderson plantea una clasificación general de los intrusos, la cual tomaremos como base [5]. 1. Penetradores externos. Usuarios no autorizados a utilizar un recurso computacional y que están buscando la manera de hacerlo. 2. Penetradores internos. Usuarios autorizados a utilizar una parte de un recurso computacional y que están buscando acceso a partes que no les corresponden. a. Intrusos enmascarados. Intrusos que penetran al sistema utilizando las credenciales de otro usuario. b. Usuarios clandestinos. Usuarios que logran accesar partes no autorizadas del recurso computacional esquivando los mecanismos de seguridad. 3. Usuarios desleales. Usuarios que tienen permitida la entrada al sistema, pero que hacen un mal uso de los privilegios de acceso que poseen. Para este estudio, nos es relevante el penetrador interno. Por otro lado, los ataques a sistemas mas comúnmente caracterizados consisten de un penetrador externo que, al conseguir algún tipo de acceso al sistema, se vuelve un penetrador interno. Anderson propone que los penetradores externos pueden ser detectados registros de intentos fallidos de entradas al sistema, y los penetradores internos pueden ser detectados mediante intentos de acceso fallidos a archivos, programas u otros recursos. Existen diversos programas que realizan análisis de bitácoras en servidores, como se ilustra en la figura 1..

(16) 7. Figura 1. Intentos fallidos de acceso a un sistema. sshd: Authentication Failures: r o o t ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 59 T i m e ( s ) r o o t (61.33.21.250): 5 Time(s) adm ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 2 T i m e ( s ) r o o t (61.142.19.13C): 2 Time(s) apache ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 1 Time(s) cyrus ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 1 Time(s) f t p (karp.ece.cmu.edu): 1 Time(s) m a i l (karp.ece.cmu.edu): 1 Time(s) mysql ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 1 Time(s) m y s q l (karp.ece.cmu.edu).: 1 Time(s) nobody ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 1 Time(s) nobody (61.142.19.130): 1 Time(s) o p e r a t o r ( 2 4 . 2 1 3 . 6 1 . 2 . s t a t i c . u p . m i . c h a r t e r m i . n e t ) : 1 Time(s). La figura 1 muestra una parte del resultado de un análisis de bitácoras automatizado de un servidor que está expuesto a Internet, en donde se muestran los intentos fallidos de acceso de diversos usuarios y desde direcciones de Internet desconocidas. El software se conoce como "LogWatch", y es de dominio público. Sin restarle importancia a la utilidad de este análisis, éste presenta un riesgo potencial, el que se puede olvidar que la información que presenta refiere hechos y acciones que ya ocurrieron. Un sistema que opera en Internet está propenso a ataques que intentarán explotar diversos problemas: Fallas en los sistemas operativos, en la configuración de los sistemas y fallas en los programas de aplicación. Anderson introdujo el concepto de "Detección de Intrusos", y definió como un intento de intromisión o amenaza a la posibilidad (incluso potencial) de un intento deliberado y no autorizado de: 2. •. A c c e s o a la información: Violación de la confidencialidad de la información.. •. Manipulación de la información: Violación de la integridad de la información.. •. Dejar a un sistema inestable o inutilizable: Negación de servicios.. 2.3 La paradoja de la seguridad. Implementar la seguridad de un sistema es una tarea compleja. Podemos comenzar estableciendo Firewalls que protejan al sistema operativo y sus programas de penetradores externos. Podemos instalar diferentes tipos de. 2. Un número importante de incidentes de seguridad son relacionados a sistemas mal configurados o sin las respectivas actualizaciones, resultado de una mala práctica en la administración de los mismos..

(17) 8. dispositivos identificadores. Es posible establecer mecanismos de protección de información mediante criptografía. Sin embargo, ésta es una tarea ardua [3]. 1. En la práctica es imposible construir un sistema completamente seguro. El software totalmente libre de errores es una tarea que en la mayoría de los casos es muy difícil de conseguir.. 2. El software actualmente en uso a nivel mundial es enorme. Una cruzada para elevar el nivel de seguridad requeriría un enorme esfuerzo.. 3. Los métodos criptográficos no son 100% seguros. La fortaleza de un algoritmo criptográfico está en la dificultad que presenta para obtener la respuesta mediante un análisis de fuerza bruta . Típicamente protegemos con criptografía las contraseñas de los usuarios, pero este es el eslabón más débil en la cadena, debido a los errores que cometen los seres humanos: Seleccionar contraseñas triviales, u omitirlas totalmente; anotar la contraseña en un lugar visible y dejar la terminal desatendida, por mencionar algunos. 3. 4. Aún con un sistema muy seguro, seríamos vulnerables a los usuarios desleales.. 5. Las restricciones impuestas al usuario afectan su rendimiento. Mientas mas restringido o confinado se sienta un usuario, menor será su productividad.. 2.4 Móvil de un intruso. Para que un usuario se convierta en intruso, necesita existir un motivo que lo impulse a buscar acceso no autorizado. Algunos de estos motivos pueden ser [7]: 1. Curiosidad. A diferencia de los usuarios con privilegios de administración, los usuarios regulares tienen acceso limitado al sistema. Inherente a la naturaleza humana está la curiosidad por conocer información ajena.. 2. Retos o ambición personal. Usuarios técnicos o con conocimientos avanzados suelen encontrar retador el burlar los mecanismos de seguridad de un sistema . Otros usuarios encontrarán aquí una manera de obtener cierto "estatus" o reconocimiento. 4. 3. Intento de enriquecimiento ilegal. Aquí las variantes son numerosas, pero todas van enfocadas a obtener dinero como resultado de la acción ilegal.. ' E l análisis de fuerza bruta consiste en sistemáticamente probar todas las posibles soluciones de un problema. Puede ser muy tardado, pero tarde o temprano daremos con la solución. En la jerga computacional se han acuñado los términos "Hacker de Sombrero Blanco" y "Hacker de Sombrero Negro". El de sombrero negro es el intruso que eventualmente resulta ser perjudicial, y el de sombrero blanco es un intruso que no realiza acciones ofensivas, y que una vez consumado el ataque presenta sugerencias a los administradores de sistemas para poder erradicar el problema. 4.

(18) 9. 4. Espionaje Industrial y Militar. Este es un tópico viejo, el cual se ha modernizado con el tiempo. A menudo implica elevados conocimientos de hardware, software y técnicas de criptografía.. En función del tipo de intruso y de sus motivos para cometer la intromisión serán las medidas de seguridad que se tomen para proteger los sistemas. Es muy diferente proteger las cantidades de dinero de un sistema bancario que evitar que un usuario coloque un mensaje divertido en una página web.. 2.5 Detección de Intrusos. En la mayoría de las situaciones es deseable contar con un sistema que recolecte y registre la información generada por las bitácoras. Como mencionamos anteriormente, la desventaja del análisis de bitácoras es que se identifican intentos de intrusión que ya sucedieron. Es posible que podamos identificar una intrusión que ya ha sido ejecutada, pero en otros casos dependiendo de la habilidad del intruso es posible que elimine sus rastros. Este campo de investigación del ambiente operativo del sistema se conoce como Detección de Intrusos. Anderson propone las siguientes definiciones [5]: 1. Riesgo. Exposición accidental o impredecible de la información, o violación de la integridad en la operación de un sistema debido a un mal funcionamiento del hardware o un mal diseño del software.. 2. Vulnerabilidad. Falla en la operación del hardware o software de un sistema, ya s e a conocida o sospechada, que expone al mismo a la penetración de intrusos o a su información.. 3. Ataque. Formulación o ejecución específica de un plan que constituye una amenaza al sistema.. 4. Penetración. Ataque exitoso. Obtención de acceso no autorizado o no detectado a archivos, programas o al control de un sistema computacional.. Un Sistema de Detección de Intrusos (SDI) tiene la tarea de detectar ataques al sistema, en el menor tiempo posible o en tiempo real de ser necesario, para poder tomar una acción preventiva o correctiva. El SDI no toma medidas preventivas por sí mismo, su función en más ser un agente reactivo que proactivo. Más que ser policía, es un informante. Las técnicas utilizadas por los sistemas de detección de intrusos pueden ser clasificadas en dos categorías [3]: 1. Detección de anomalías. Las técnicas de detección de anomalías asumen que todo comportamiento anormal es un intento de intrusión. Si es posible establecer un perfil de "comportamiento normal" de los recursos del sistema, teóricamente es posible señalar todas las actividades que se.

(19) 10. aparten de este perfil en cantidades estadísticamente significativas, a las cuales se llaman "Intentos de Intrusión". 2. Detección de mal uso. El concepto principal detrás de los esquemas de detección de mal uso es que hay manera de representar un ataque en forma de un patrón.. Dentro de los mecanismos utilizados exitosamente para la detección de intrusos está el análisis de los rastros dejados por los usuarios. La Auditoria de Rastros permite el análisis de los registros de las acciones de los usuarios. Incluso, este mecanismo puede ser útil para determinar la culpabilidad o inocencia de un usuario sospechoso, y en otros casos puede ser el único medio para determinar cuando un usuario está abusando de sus privilegios de acceso [2]. La mayoría de los sistemas computacionales cuentan con mecanismos para recolectar información de las acciones tomadas por los usuarios, pero éstos fueron diseñados para recolectar información del desempeño de los sistemas o para depuración de errores. Dentro de los principales inconvenientes tenemos: •. Generalmente consisten de una cantidad muy voluminosa y muy detallada de información, y frecuentemente es difícil de interpretar para un ser humano.. •. Dentro de la información encontrada, no se encuentran los indicios de los accesos de usuarios enmascarados.. •. S e omite información que puede ser relevante para la oportuna identificación de un intruso.. Un SDI es una herramienta automatizada que ayuda al encargado de la seguridad o al administrador del sistema. Reduce la cantidad de información que debe ser procesada. Existen implementaciones de SDI para detectar intrusos en tiempo real, que permite tomar acciones conforme van aconteciendo los hechos. El análisis que un SDI lleva a cabo sobre la información puede ser de los siguientes tipos: •. Análisis profundo y a conciencia, fuera de línea.. •. Evaluación de los datos auditables en tiempo real, para permitir una respuesta inmediata.. •. Análisis subsecuente de los datos auditables para determinación de la dimensión de algún daño.. El SDI puede detectar a los usuarios que están enmascarados y, en algunas situaciones, es posible detectar usuarios que abusan de sus privilegios observando su comportamiento, determinando si se aparta de un comportamiento definido a priori como "socialmente aceptable". El caso de los usuarios que abusan de sus privilegios es más complicado, porque en muchos casos las conductas habitualmente "anormales" pueden ser normales (tareas de un administrador), y Anderson ofrece poca esperanza para esta situación..

(20) 11. En caso que un usuario opere clandestinamente e intente evadir el monitoreo ya s e a evadiendo los mecanismos de la auditoría u operando a un nivel menor que la auditoría puede ser evitado analizando las funciones que administran la auditoría, o bien auditando a bajo nivel los servicios del sistema o llamadas a nivel de kernel. Anderson sugiere el monitoreo de indicadores del sistema como el C P U , actividad de la memoria, en discos duros y compararlos contra perfiles de actividad normal del sistema.. 2.6 Trampas. Cheswick describe un experimento realizado cuando un intento de intrusión fue detectado en un sistema [8], Desde el momento del descubrimiento se realizó un monitoreo de la actividad del intruso y se le construyó una trampa especial, de tal manera que éste tuvo éxito al penetrar la seguridad de un sistema. El experimento es arriesgado, y se obtuvieron resultados interesantes: •. Un penetrador experto cuenta con una lista de vulnerabilidades y fallas en sistemas y programas, las cuales intentará explotar sistemáticamente.. •. Si el intruso consigue penetrar un sistema, el riesgo de que eventualmente consiga acceso con privilegios de administrador el alto.. El éxito de Cheswick se debió principalmente a su amplia experiencia como administrador de sistemas y de un profundo conocimiento del sistema que administraba. El mismo indica que este tipo de trampas no son un mecanismo recomendable, un descuido por mínimo que sea provocará que la trampa falle, exponiendo el sistema al intruso. El juguetear con un intruso no es una actividad que se desee o se debe hacer, incluso por un administrador de sistemas experto..

(21) 12. 3. Metodología de investigación.. El objetivo del presente trabajo es primordialmente reforzar la seguridad de un sistema en contra de penetradores internos. El sistema deberá contar con un algún tipo de mecanismo ejecutor de comandos de usuario. Este reforzamiento en la seguridad se conseguirá mediante un proceso de autorización de los comandos del usuario, permitiendo restringir las acciones que puede realizar un usuario dentro de éste ambiente de una manera específica y con un nivel de resolución mayor al proporcionado de manera estándar por el sistema que se pretende proteger. Las actividades que se realizaron para cumplir el objetivo del presente trabajo de investigación son los siguientes. 1. Selección de los elementos técnicos. a. Selección del software para Autentificación y Autorización de comandos apropiado para la solución del problema. Deberá ser un protocolo ligero y flexible. Para fines de este trabajo no se requiere compatibilidad con muchos equipos, no se contempla interacción con diversos dispositivos. b. Selección de un ambiente operativo en donde un usuario pueda intentar obtener información no autorizada o bien que presente un riesgo para la seguridad de un sistema. Este ambiente deberá contener algún tipo de ejecutor de comandos por parte del usuario, de tal manera que las instrucciones emitidas por el usuario deberán pasar por el proceso de autorización. c. Selección de las herramientas de desarrollo de software. Definición del lenguaje de programación, seleccionado por su relevancia.. 2. Configuración y puesta en marcha de un servidor para Autentificación y Autorización de comandos. a. Selección de un equipo de trabajo, preferentemente un sistema operativo apto para prestar servicios de Internet como Linux, Unix o Windows 2003 Server. Realizar todos los pasos y ajustes técnicos necesarios para que el software de Autentificación y Autorización quede funcionando óptimamente en el sistema. b. Configuración del software de Autentificación y Autorización para aplicar las restricciones que implican riesgos en el escenario propuesto.. 3. Desarrollar una biblioteca de funciones para interactuar con el software de Autentificación y Autorización. a. Obtención del documento con la especificación del protocolo de comunicaciones empleado por el software de Autentificación y Autorización..

(22) 13. b. Desarrollo de la biblioteca de funciones para Autentificación y Autorización remota. 4. Adaptación del componente necesario para el escenario descrito en el punto 1 para utilizar la biblioteca de funciones de Autentificación y Autorización.. 5. Ejecución de pruebas operativas..

(23) 14. 4. Solución propuesta.. C o m o se puso de manifiesto en los capítulos anteriores, existe un riesgo significativamente alto de que la seguridad en los servidores sea quebrantada por penetradores internos y externos, sin que los administradores de dichos servidores se enteren de ello, ya que: 5. •. Un intruso puede conseguir acceso a un sistema de una manera relativamente fácil.. •. Con las herramientas e información básica que proporcionan los sistemas (bitácoras) puede tomarnos tiempo detectar intentos de intrusión o accesos no autorizados exitosos.. •. Un intruso con suficiente interés en nuestra información puede invertir una gran cantidad de tiempo y recursos para conseguir lo que s e propone.. •. No es posible ni recomendable eliminar las facilidades de un sistema que son potencialmente peligrosas, como lo son mecanismos de administración de acceso, de configuración de red, etc., para intentar prevenir una modificación no autorizada en la configuración de seguridad del sistema.. •. No existe un sistema perfecto o 100% seguro.. La solución propuesta contempla el desarrollo de un software prototipo que implementará un mecanismo de autentificación y autorización de comandos de usuario. Este software será un mecanismo de defensa proactivo, capaz de restringir la actividad de un usuario en función de las instrucciones o acciones que se desee tomar, y con la capacidad adicional de proporcionar información relevante para un sistema de Detección de Intrusiones. El principio básico para el funcionamiento del sistema de Autorización de Comandos consiste en la autorización explícita de los comandos y llamadas al sistema del usuario, incluido en caso de ser necesario a el (los) usuario(s) administradores, de una manera transparente y hasta donde sea posible imperceptible para el intruso potencial. La primera línea de defensa del sistema de Autorización de Comandos (SAC) será detener al intruso, incluso en situaciones en donde se ha conseguido acceso privilegiado al sistema. Los pasos en el proceso de defensa se describen a continuación. 1. 5. El Mecanismo Ejecutor de Comandos (MEC) de un sistema determinado obtiene el comando o instrucción que el usuario desea realizar. Esta instrucción típicamente consiste de un comando, acompañado de argumentos. Un ejemplo podría ser la instrucción S Q L " S E L E C T * F R O M. Acceso de cualquier tipo, no se refiere específicamente a un acceso con privilegios de administración..

(24) 15. tabla", en donde el comando es " S E L E C T " y los argumentos son "*", " F R O M " , y "tabla". 2. Antes de proceder con la instrucción, el M E C realiza una consulta a un servidor de autorización (SA). Al servidor de autorización se le proporciona información relevante al usuario que está solicitando la ejecución de una instrucción, así como la instrucción que se intenta realizar.. 3. El servidor de autorización determina si el usuario proporcionado tiene permitido ejecutar la instrucción deseada, ya sea por: a. Negación o autorización explícita de un comando solicitado. b. Negación o autorización de un argumento específico o generalizado por expresiones regulares. c.. Negación o autorización explícitamente de un usuario determinado.. d. Combinaciones de los puntos anteriores. El servidor de autorización contesta la solicitud del M E C ya sea de manera positiva o negativa. El evento cualesquiera que sea queda registrado en una bitácora. 4. En función de la respuesta del servidor de autorización, el M E C realiza o no la instrucción solicitada por el usuario. El M E C opcionalmente tiene la opción de registrar a su vez el suceso ya sea de autorización o de negación. La solución propuesta consiste de dos partes.. •. Un servidor de Autorización, que será responsable de negar o autorizar las instrucciones de los usuarios pasadas por el M E C , cuya configuración será flexible.. •. Un sistema de Solicitud de Autorización (SSA), que se incorporará a un sistema que se desea tenga restricciones para los usuarios, y que se encargará de solicitar las autorizaciones de los comandos proporcionados por el M E C al Servidor de Autorizaciones.. 4.1 El servidor de autorización. Para la función del servidor de autorización se seleccionó al servidor tac_plus.F4.0.11 de Cisco Systems. El software implementa el protocolo T A C A C S + , que constituye la parte principal de un mecanismo de Autentificación, Autorización y Registro de Eventos (AAA, que son las siglas en inglés de "Authentication", "Authorízation" y "Accounting') utilizado ampliamente en routers y Network A c c e s s Servers de esta compañía y de otras. Además de cumplir con los requisitos funcionales, se cuenta con las siguientes ventajas: •. El software es de tamaño pequeño, no consume muchos recursos de cómputo..

(25) 16. •. El protocolo de autorización es de fácil implementación.. •. S e cuenta con la especificación técnica del protocolo, disponible directamente con el fabricante, Cisco Systems.. •. E s de configuración flexible. S e pueden definir usuarios y grupos de usuarios. Es posible utilizar expresiones regulares en la configuración de la autorización.. •. El software se de dominio público. S e obtiene gratuitamente en forma de código fuente directamente desde el fabricante.. La configuración de la autorización en servidor T A C A C S + requiere la definición de usuarios y/o grupos de usuarios, para seguidamente configurar la autorización en sí en estas entidades. La configuración del servidor se encuentra en un archivo de texto plano generalmente llamado tac_plus.conf. 6. 4.1.1. Declaración de usuarios y grupos de usuarios.. La configuración de la autorización se realiza directamente sobre los usuarios o sobre la declaración de un grupo de usuarios. Un grupo puede pertenecer a otro grupo (solamente uno), ese grupo puede pertenecer a otro grupo y así sucesivamente. Un usuario a su vez puede pertenecer a un grupo. El formato para declaración de usuarios y grupos es como se indica a continuación. Figura 2. Declaración de usuarios y grupos de usuarios. g r o u p = <nombre d e l g r u p o > { # E s t e e s un c o m e n t a r i o } g r o u p = < o t r o g r u p o > •; raember = <nombre d e l g r u p o > } u s e r = <nombre de u s u a r i o { member = < o t r o g r u p o > }. En donde: •. <nombre del grupo> y <otro grupo> son cadenas alfanuméricas, que no contienen espacios y no comienzan con un dígito.. •. <nombre de usuario> es una cadena alfanumérica, que no contiene espacios y no comienza con un dígito.. En el formato de configuración se indica la manera en cómo se declara la inclusión en otros grupos tanto de un grupo como de un usuario. Para fines de la solución propuesta, para los usuarios que no se encuentren explícitamente. 6. La ubicación física del archivo dependerá de la manera en como se configure e instale el software. Algunos sistemas operativos ya lo incluyen, pero la ubicación de los programas y archivos es diferente entre ellos..

(26) 17. declarados en la configuración serán siempre negadas por omisión cualquier solicitud de autorización proveniente del sistema de solicitud de autorización. 4.1.2 Declaración de la autorización de comandos. Seguida a la declaración de usuarios y su organización en grupos, corresponde la configuración de la autorización de comandos. Como hemos mencionado anteriormente, los comandos que se autorizarán son recolectados por el M E C , que está en contacto interactuando con el usuario. Cuando se solicita autorización, es necesario que el sistema de solicitud de autorización envíe el comando completo, eliminando cualquier tipo de carácter comodín que sea permitido en el sistema que se está protegiendo. 7. La autorización de comandos se configura con una serie de expresiones regulares, que sean aceptables para egrep, para representar a los argumentos de un comando, y adicionalmente una acción que será tomada, que puede ser deny (negar) o permit (permitir). Los comandos que no estén explícitamente autorizados, por omisión serán negados. El siguiente ejemplo permite al usuario "antonio" la ejecución de:. telnet telnet delete. 6 3 . 1 7 0 . < c u a l q u i e r número>.l 6 3 . < c u a l q u i e r numero>.25.249 *.txt. y cualquier otro comando será negado por omisión:. user = antonio { cmd = t e l n e t { p e r m i t 63\.170\.[0-9]+\.1 p e r m i t 63. [ 0-9]+\.25\.249. } cmd = d e l e t e { permit *.txt. } } El comando y los argumentos proporcionados por el M E C son cotejados contra la configuración del usuario en cuestión. Si un comando no se encuentra definido, se niega por omisión.. 7. Por ejemplo, en un shell de UNIX, los caracteres * y ? son tratados como comodines (wildcards, en inglés), porque tienen un significado especial para el intérprete de comandos..

(27) 18. La configuración puede utilizarse de una manera menos restrictiva. En este ejemplo, se prohibe la ejecución del comando r m d i r C: \WINDOWS para el usuario pedro: user = pedro { default service = permit cmd = r m d i r { d e n y C:\\WINDOWS p e r m i t .*. } }. El elemento nuevo es el estatuto default service = permit. El estatuto indica que los comandos no declarados explícitamente serán autorizados por omisión. Así mismo, es necesario agregar un permit .* (permitir cualquier argumento) al final de la declaración del comando permit. De otra manera, a pesar de la declaración de default. service. = p e r m i t , dentro de la declaración del comando r m d i r la. acción por omisión sigue siendo negar la autorización. El servidor T A C A C S + espera por la red peticiones en forma de tupias atributo=valor. Por ejemplo, una solicitud del sistema de solicitud de autorización puede ser de la forma que sigue:. user = antonio command = SELECT totalargs = 2 arg = password a r g = FROM u s u a r i o s a r g = WHERE u s u a r i o =. pedro. Este conjunto de tupias viajan por la red encapsulada en un paquete del protocolo T A C A C S + .. 4.2 El sistema de solicitud de autorización. El sistema de solicitud de autorización es una parte crítica de la ¡mplementación. El sistema de solicitud de autorización se encuentra en contacto directo con el usuario, en el sistema que se desea proteger. El sistema de solicitud de autorización implementa la parte del cliente en la interacción mediante el protocolo T A C A C S + . El modelo T A C A C S + ofrece la funcionalidad de autentificación, que para fines de la solución propuesta no implementaremos..

(28) 19. El protocolo T A C A C S + incluye de manera separada funciones de autentificación, autorización y registro de eventos. Es extensible, permite realizar adaptaciones especiales y permite agregar nuevas características. Utiliza T C P como medio de transporte, basados en que es un protocolo confiable. El protocolo permite al cliente especificar control de acceso con un nivel de granularidad muy fino [12]. La separación de las 3 funciones es fundamental en el diseño del protocolo T A C A C S + . La especificación del protocolo no exige que las tres sean implementadas. Cada una por separado tiene un objetivo particular, aunque utilizadas en combinación ofrece una herramienta poderosa [12], cosa que es particularmente atractivo para la solución propuesta. El sistema de solicitud de autorización se implementará en forma de una API en lenguaje Java. Java es un lenguaje atractivo para este estudio por las siguientes razones: •. Es un lenguaje multiplataforma. El compilador de Java de una plataforma específica compila el código fuente a código intermedio {"bytecode'). Este código intermedio es independiente de la plataforma, y puede ser ejecutado por el J R E específico de cualquier otra plataforma. Actualmente se encuentran disponibles J R E y J D K para las plataformas Solaris (Intel, S P A R C ) , Linux (Intel, IA64), Windows (Intel, IA64) como productos de Sun Microsystems. IBM tiene disponibles versiones de Java para sus plataformas Power. 8. 9. •. Cuenta con la funcionalidad de comunicación por red requerida para esta implementación.. •. E s un lenguaje orientado a objetos, tiene las características deseables para poder realizar ingeniería de software de alta calidad.. •. Es un lenguaje muy utilizado en ambientes de empresariales, de alta disponibilidad. Utilizado en aplicaciones de misión crítica.. •. Está disponible de manera gratuita por la red.. La API implementada expondrá al usuario 3 funciones requeridas para el funcionamiento de la solución. public. •. init(). La función i n i t () inicializa la comunicación con el servidor de autorización. Es necesario llamar a esta función antes de cualquier otra. Regresa f a i s e en caso de no conseguir una conexión exitosa, t r u e de caso contrario.. public. 9. boolean. boolean. sendCmd(String. argv[]). Java Run-time Environment Java Development Kit, que son las herramientas para compilación..

(29) 20. •. La función s e n d c m d construye un paquete T A C A C S + apto para ser transmitido por la red, a partir del comando y sus argumentos especificados en el array argv[]. La función envía el paquete TACACS+ con servicio A U T H O R I Z A T I O N R E Q U E S T y espera por una respuesta. El array a r g v n es similar al que Se pasa a la función p u b l i c s t a t i c v o i d m a i n ( S t r i n g a r g v [ ] ) . La función regresa t r u e si el servidor de autorización permite la ejecución del comando y argumentos. De caso contrario regresa f a i s e .. public. •. void. cióse (). La función cióse () termina la comunicación con el servidor de autorización. No toma argumentos, y no tiene un valor de retorno. Es importante llamar explícitamente a esta función, porque de otro caso se puede inundar al servidor de autorización con conexiones que no se están utilizando. Un ejemplo muy general del uso de las funciones se ilustra a continuación.. Figura 3. Seudo código para establecer comunicación con el servidor de autorización. 1 t a c a c s C l i e n t . i n i t () ; 2 b o o l e a n done = f a l s e ; 3 w h i l e (done == f a l s e ) { 4 S t r i n g cmdLine = i n . r e a d L i n e ( ) ; 5 i f (cmdLine.equals("")) { 6 done = t r u e ; 7 } else { 8 S t r i n g [ ] argv = construyeArgs(cmdLine); 9 i f ( t a c a c s C l i e n t . s e n d C m d ( a r g v ) == t r u e ) { 10 executeCommand(argv); 11 } else { 12 System.out.println("No autorizado."); 13 } 14 } 15 }. En la figura 3 se inicializa la comunicación en (1), y entra en un ciclo en (3). Durante ese ciclo, se estará aceptando una línea proporcionada por el usuario, hasta que el usuario proporcione una línea vacía. Si la línea está vacía, provoca que se rompa el ciclo en (6), de otra forma la pseudo función construyeArgs divide una línea en su comando y argumentos, el resultado se coloca en el arreglo argv. La función sendCmd se invoca con los parámetros respectivos, y en caso que el servidor de autorización responda con true, se ejecuta el comando en cuestión..

(30) 21. El servidor de autorización podrá atender a varias solicitudes de diferentes sistemas de solicitud de autorización de manera concurrente.. 4.3 Ventajas de la solución propuesta. •. El sistema de solicitud de autorización es de perfil genérico. Esto significa que puede ser adaptado a una diversidad de situaciones. El caso más fácil de tomar sería incorporarlo a un shell de UNIX.. •. Las instrucciones que pueden ser ejecutadas en el sistema quedan restringidas, quedando restringidas incluso para el mismo superusuario. Por ejemplo, si tenemos un sistema en donde no habrá usuarios (solamente servicios de red), podría ser posible configurar el mecanismo para permitir las tareas requeridas del superusuario al arrancar el equipo (inicializar hardware y componentes, inicializar software, etc), y una vez completada la tarea se aplica el mecanismo de seguridad. En caso de una intrusión con el superusuario, no le será posible al intruso causar un daño considerable.. •. Es posible evitar que se borren o eliminen los archivos con la bitácora del sistema, incluso para el mismo súper usuario. Por ejemplo, el Sistema se configuraría para evitar que sean borrado el archivo / v a r / i o g / w t m p . E s posible evitar problemas mayores causados por errores del operador. Por ejemplo, se puede configurar el Sistema para negar la ejecución del comando UNIX m -rf *, que ejecutado como el súper usuario y bajo las condiciones apropiadas, sería catastrófico.. •. •. Facilita el rastreo de intrusos, al registrar los eventos de intento de utilizar alguna vulnerabilidad conocida en los programas.. •. Es posible complementar otros mecanismos de seguridad existentes. Por ejemplo, se puede complementar los permisos de acceso de un sistema de archivos.. •. La configuración del servidor de autorización es muy flexible. Es posible cubrir muchas posibilidades y combinaciones de comandos y argumentos.. •. La API puede extenderse, para ofrecer los servicios de autorización de comandos a funciones de nivel mas bajo, como llamadas al sistema operativo, o de comunicación entre procesos..

(31) 22. 5. Modelo de experimentación.. La experimentación consistió en adaptar el sistema de solicitud de autorización a un programa de uso común. S e demostró que el sistema de autorización de comandos ofrece una protección que no es posible encontrar en la versión normal del software en cuestión. Para la experimentación se seleccionó el ambiente cliente-servidor de una base de datos. Las bases de datos son componentes de software esenciales en la actualidad, si es posible mejorar la seguridad en este escenario, resultará atractivo para los administradores de sistemas. El sistema de solicitud de autorización (API) se adaptó a un software para administración de bases de datos. El software se llama "Datábase Java Consolé" [15], el cual permite ejecutar consultas predefinidas contra cualquier base de datos que cuente con un "driver" J D B C . Tales consultas predefinidas se guardan en un archivo de configuración, y esto permite en algunas bases de datos ejecutar comandos de mantenimiento de una manera sencilla, como regeneración de índices o de optimización de tablas. Se realizó una modificación al software para permitir que el usuario proporcione una consulta de manera interactiva, seleccionando la opción "99". El software está implementado en Java, y es de dominio público. Dentro del software se adaptó una función para identificar los comandos S Q L proporcionados por el usuario, los cuales se autorizan contra el servidor de autorización antes de ser pasados al servidor de Bases de Datos para su ejecución. C o m o software de apoyo se utilizará el servidor de bases de datos PostgreSQL versión 7.4.3. Este software no requirió ser modificado para la correcta ejecución del modelo. El conjunto de instrucciones sobre las cuales se realizó la experimentación provienen del lenguaje S Q L . S Q L es un lenguaje de consulta, modelado a partir del álgebra relacional e implementado por los manejadores de bases de datos relaciónales y que permite extraer, insertar y modificar la información que es almacenada. Existe actualmente un estándar definido por el Instituto Americano de Estándares (ANSI, por sus siglas en inglés), llamado ANSI/ISO SQL99, el cual lamentablemente no es implementado al 100% por los manejadores de bases de datos comerciales o de fuente abierta. Los experimentos se realizaron contra una base de datos de ejemplo, que simula un conjunto de filiales de una empresa, y los agentes de ventas que pertenecen a cada una de ellas. La descripción de las tablas se muestra a continuación..

(32) 23. Tabla 1. Descripción de la Tabla Filiales. Nombre de la Columna. Tipo de Dato. Descripción. idjilial. SERIAL. Llave privada e identificador único.. nombre. VARCHAR(32). Nombre de la filial.. Tabla 2. Descripción de la Tabla Agentes. Nombre de la Columna. Tipo de Dato. Descripción. id_agente. SERIAL. Identificador único y llave primaria.. idjilial. INTEGER. Llave foránea, relación con la tabla de Filiales.. numero. VARCHAR(16). Número de agente.. passwd. VARCHAR(16). Password del agente.. 5.1 Experimento #1: Prevenir la visualización de las variables de operación del servidor. Las variables de operación ("run time environment variables') proporcionan información acerca de los recursos y configuración del servidor PostgreSQL. Tales variables se activan en el archivo de configuración del sistema, que es leído y procesado en el momento que software arranca. Algunas de éstas variables pueden ser modificadas mediante el comando S Q L SET. El comando que permite ver las variables de operación del servidor es S H O W . El formato de la instrucción S H O W es: SHOW [ A L L ]. El objetivo se puede cumplir negando la ejecución del comando. La configuración correspondiente en el servidor de autorización es la siguiente: user = antoniovl { default service = permit cmd = show { d e n y .* } }. La ejecución del programa se ilustra en la figura 4..

(33) 24. Figura 4. Ejecución de "show all". 31 C:\WINDOWSVSys1em32kiiKl.<?*•• - lun. _ C3 X. ):sTenpNdbjcNsrc>run ):\Te»»p\dbj c \ s r c >d:\sun\AppSeruer\jdk\bin\java con.nioto.dbjc.Main cora\nioto\dbj ¡Nsample.properties ?hoose a query: 1: Quit prograni l: Seleccionar Todos los Agentes !: Uer e l password un agente I: Modificar e l password de un agente >9: Specify custon query ínter your cholee: 99 ?ustont Query:show a l l ktthorization F a i l e d SQL Instruction ftuthorization F a i l e d . Ihoose a query: i : Quit progran L: Seleccionar Todos los Agentes í: Uer e l password un agente t: Modificar e l password de un agente 19 i Specify custom query ínter your cholee: «.. El programa tiene 3 consultas predefinidas, además que ser posible especificar una consulta arbitraria si se selecciona la opción 99. En este caso, seguidamente del mensaje "Custom Query" podemos observar el texto del comando que se intentó ejecutar. El servidor de autorización negó la petición por estar explícitamente configurado para hacerlo. El registro en la bitácora de este evento se muestra en la figura 5.. Figura 5. Registro en la bitácora del comando "show all". 1 Thu Nov 11 0 2 : 2 8 : 2 5 2004 [ 1 7 2 5 ] : s e s s i o n r e q u e s t f r o m 1 7 2 . 1 7 . 1 . 1 9 8 sock=l 2 Thu Nov 11 0 2 : 2 8 : 2 5 2004 [ 1 8 4 1 ] : W a i t i n g f o r p a c k e t 3 Thu Nov 11 0 2 : 2 8 : 2 5 2004 [ 1 8 4 1 ] : H e a d e r Read OK, l e n = 12 4 Thu Nov 11 0 2 : 2 8 : 2 5 2004 [ 1 8 4 1 ] : v e r s i o n = 1 9 2 , t y p e = 2 , s e c _ n o = l , e n c = l , s e s = 1 1 2 8 1 6 5 8 34, d a t a l e n = 1 1 2 8 1 6 5 8341u l e n = 83 5 Thu Nov 11 02 28 25 2 0 0 4 [1841] R e a d AUTHOR s i z e = 8 3 6 Thu Nov 11 02 28 25 2 0 0 4 [1841] v a l i d a t i o n r e q u e s t from 172.17.1.198 7 Thu Nov 11 02 28 25 20 0 4 [1841] PACKET: key=<NULL> 8 Thu Nov 11 02 28 25 2 0 0 4 [1841] versión 192 (OxcO), t y p e 2, s e q no 1, 9 Thu Nov 11 02 28 25 2004 [1841] encryption 1 s e s s i o n i d 3396419139 (0xca713e43), 10 Thu Nov 11 02 28 25 2 0 04 [1841] D a t a l e n g t h 71 (0x47) End h e a d e r 11 Thu Nov 11 02 28 25 2 00 4 [1841] 12 Thu Nov 11 02 28 25 2004 [18 41] type=AUTHOR, p r i v l v l = 1 5 , a u t h e n = l 13 Thu Nov 11 02 28 : 25 2004 [1841] • m e t h o d = t a c a c s + 14 Thu Nov 11 02 28 : 25 200 4 [1841] : s v c = l u s e r l e n = 9 p o r t l e n = 7 rem a d d r l e n = 1 2.

(34) 25. Figura 5. Registro en la bitácora del comando "show atí". 15 T h u Nov 11 02 : 28 : 25 2 0 0 4 [1841] : 16 Thu Nov 11 02 : 28 : 25 2 0 0 4 [1841] : 17 T h u Nov 11 02 : 28 : 25 2C04 [1841] : 18 T h u Nov 11 02 : 28 : 25 2 0 0 4 [1841] : 19 Thu Nov 11 02 : 28 : 25 2 00 4 [1841] : 2 0 Thu Nov 11 02 28 : 25 2004 [1841] : 21 Thu Nov 11 02 28 : 25 2C04 [1841] : 2 2 Thu Nov 11 02 28 : 25 2 00 4 [1841] : 23 Thu Nov 11 02 28 : 25 2C04 [1841] : 2 4 T h u Nov 11 02 28 : 25 2 C 0 4 [1841] 25 Thu Nov 11 02 28 : 25 2 0 0 4 [1841] 2 6 Thu Nov 11 02 28 : 25 2C04 [1841] 27 Thu Nov 11 02 28 : 25 2 0 0 4 [1841] 2 8 Thu Nov 11 02 28 : 25 2 0 0 4 [1841] 2 9 Thu Nov 11 02 28 25 2004 [1841] 30 T h u Nov 11 02 28 25 2 00 4 [1841] 31 Thu Nov 11 02 28 25 2004 [1841] match 32 T h u Nov 11 02 28 25 2004 [1841] 33 Thu Nov 11 02 28 25 2 0 0 4 [1841] 3 4 T h u Nov 11 02 28 25 2 0 04 [1841] 35 T h u Nov 11 02 28 25 2004 [1841] encryption 1 3 6 Thu Nov 11 02 : 28 25 200 4 [1841] D a t a l e n g t h 6 (0x6) 37 Thu Nov 11 02 : 28 25 2004 [1841] 38 T h u Nov 11 02 : 28 25 2004 [1841] (AUTHOR/FAIL) 3 9 Thu Nov 11 02 : 28 25 2 0 0 4 [1841] 4 0 Thu Nov 11 02 :28 25 2004 [1841] 41 T h u Nov 11 02 :28 25 2004 [1841] 4 2 T h u Nov 11 02 : 28 25 2004 [1841] 4 3 T h u Nov 11 02 : 28 25 2004 [1841] consolé f r o m 172 . 17 1 . 198 r e j e c t e d. a r g cnt=3 User: antoniovl port: consolé rem a d d r : 172717.1.198 a r g [0] : s i z e = 1 3 service=shell a r g [ 1 ] : s i ze=8 cmd=show arg[2] : s i ze=l1 cmd-arg=all End p a c k e t Start authorization request user ' a n t o n i o v l ' found l i n e 5 compare show d e n y. &. ' a l l. show a l Writing PACKET: versión. l d e n i e d by l i n e 5 AUTHOR/FAIL s i z e = 1 8 key=<NULL> 192 (OxcO), t y p e 2, s e q no 2. session. i d 3396419139. ( 0xca713e43),. End h e a d e r type=AUTHOR/REPLY s t a t u s = 1 6 msg l e n = 0 , d a t a l e n = 0 a r g c n t = 0 msg: data : End p a c k e t a u t h o r i z a t i o n query f o r ' a n t o n i o v l '. Como podemos observar, la bitácora contiene la información importante para un sistema de autoría. •. S e tiene la dirección IP del cliente (renglón 1). •. La llave de encripción (renglón 8). •. El usuario (renglón 17). •. El comando (renglones 24 al 27). •. La regla que impide la ejecución del comando (renglones 31 y 32). •. El estatus final de la solicitud (renglón 43).. El comando S H O W es una extensión que PostgreSQL realizó al lenguaje, y en el sistema no hay manera de prevenir que un usuario ejecute el comando..

(35) 26. Es posible prevenir la visualización de ciertas variables de ambiente. Por ejemplo, suponiendo que se desea que el usuario no pueda consultar la variable server_version, implementamos los siguientes cambios en la configuración del servidor de autorización. user = antoniovl { default service = permit cmd = show { deny a l l d e n y s e r v e r versión p e r m i t .*. La prevención de una sola variable se consigue con 3 instrucciones. El primer d e n y a l l evita que la variable s e r v e r _ v e r s i o n sea visualizada en el listado general. La segunda instrucción d e n y s e r v e r _ v e r s i o n explícitamente prohibe que esta cadena forme parte de los argumentos de la instrucción show. La tercera instrucción permite al resto de los parámetros. La ejecución de show s e r v e r _ v e r s i o n se muestra a continuación. Figura 6. Ejecución de show server_version. M C:\WIHDOWS\System32knul e«- mu. _• x. :\Tenp\dbjc\src>d:\suii\AppServer\jdk\bin\java com.nioto. dbjc.Hain cor»\niotoSdbj Nsanple.propert ies hoose a query: : Quit progran : Seleccionar Todos los Agentes : Uer e l password un agente : Hodif i c a r e l password de un agente 9: Specify custon query nter your cholee: 99 uston Query:show «erver_uersion uthorization F a i l e d QL Instruction Authorization F a i l e d . hoose a query: : Quit program : Seleccionar Todos los Agentes : Uer e l password un agente : Hodif icar e l password de un agente 9: Specify custon query nter your choice: 99 ustom Query:«how nax_connections ax_connectlons » 1824 entei>> f o r next» or. En la figura 6 podemos observar que no se tuvo éxito con la consulta de la variable s e r v e r _ v e r s i o n . S e ilustra además la consulta de la variable m a x c o n n e c t i o n s , que muestra la capacidad de mostrar otras variables de ejecución. La bitácora generada por el intento de ejecución de este comando se muestra en la figura 7. Figura 7. Ejecución de fallida del comando show max_connections. Thu. N o v 11 0 3 : 0 9 : 0 1 2004 [ 1 8 9 4 ] :. session request. f r o m 172.17.1.198. sock=l.

(36) 27. Figura 7. Ejecución de fallida del comando show max_connections. 1943]: W a i t i n g f o r packet Thu Nov 11 03 : 09: 01 2004 1 9 4 3 ] : H e a d e r R e a d OK, l e n = 12 Thu Nov 11 03: 09: 01 2004 v e r s i o n = 1 9 2 , t y p e = 2 , s e c n o = l , enc= 1 1943] Thu Nov 11 03: 09: 01 2004 s e s ==3098509974, d a t a l e n = 3 l 9 8 5 0 9 9 7 4 1 u 1943] • l e n = 94 Thu Nov 11 03 : 09: 01 2004 R e a d AUTHOR s i z e = 9 4 1943] Thu Nov 11 03: 09 : 01 2004 v a l i d a t i o n r e q u e s t from 172.17.1.198 1943] Thu Nov 11 03 : 09: 01 2004 PACKET: key=<NULL> 1943] Thu Nov 11 03: 09: 01 2004 versión 192 (OxcO), t y p e 2, s e q no 1 1943] Thu Nov 11 03: 09: 01 2004 encryption 1 s e s s i o n i d 2525147064 ( 0 x 9 6 8 2 a f b 8 ) , D a t a 1943] Thu Nov 11 03 : 09: 01 2004 l e n g t h 82 (0x52) 1943] End h e a d e r Thu Nov 11 03: 09: 01 2004 1943] type=AUTHOR, p r i v l v l = 15, authen=.l Thu Nov 11 03 : 09 01 2004 method=tacacs+ Thu Nov 11 03 : 09: 01 2004 [1943] s v c = l u s e r len=9 p o r t len=7 Thu Nov 11 03 : 09- 01 2004 [1943] rem a d d r l e n = 1 2 Thu Nov 11 0 3 : 09 01 2004 [1943] a r g cnt=3 User: Thu Nov 11 03 : 09 01 2004 [1943] antoniovl Thu Nov 11 03 : 09 01 2004 [1943] port: Thu Nov 11 03: 09 01 2004 [1943] Thu Nov 11 03 : 09 01 2004 [1943] consolé Thu Nov 11 03: 09 01 2004 [1943] rem a d d r : 172.17.1.198 Thu Nov 11 03: 09 01 2004 [1943] Thu Nov 11 03 09 01 2004 [1943] arg[0]: size=13 Thu Nov 11 03 09 01 2004 [1943] service=shell Thu Nov 11 03 09 01 2004 [1943] a r g [ 1 ] : size=8 Thu Nov 11 03 09 01 2004 [1943] cmd=show Thu Nov 11 03 09 01 2004 [1943] a r g [ 2 ] : s i ze=22 Thu Nov 11 03 09 01 2004 [1943] c m d - a r g = s e r v e r versión Thu Nov 11 03 09 01 2004 [1943] End p a c k e t Thu Nov 11 03 09 01 2004 [1943] . S t a r t a u t h o r i z a t i o n r e q u e s t Thu Nov 11 03 09 01 2004 [19 4 3] u s e r ' a n t o n i o v l ' f o u n d Thu Nov 11 03 09 01 2004 [1943] l i n e 5 c o m p a r e show d e n y ' a l l ' & ' s e r v e r versión' no m a t c h Thu Nov 11 03 09 01 2004 [1943] : l i n e 6 c o m p a r e show d e n y ' s e r v e r v e r s i o n ' & s e r v e r versión' m a t c h Thu Nov 11 03 09 01 2004 [1943] : show s e r v e r versión d e n i e d b y l i n e 6 Thu Nov 11 03 09 01 2004 [1943] : W r i t i n g AUTHOR/FAIL s i z e = 1 8 Thu Nov 11 03 09 01 2004 [1943] : PACKET: key=<NULL> Thu Nov 11 03 09 01 2004 [1943] : versión 192 (OxcO), t y p e 2, s e q no 2 encryption 1 Thu Nov 11 03 09 01 2004 [1943] : s e s s i o n i d 2 5 2 5 1 4 7 0 6 4 ( 0 x 9 6 8 2 a f b 8 ) , Dat£ l e n g t h 5 (0x6) Thu Nov 11 03 09 01 2004 [1943] : E n d h e a d e r Thu Nov 11 03 09 : 01 2004 [1943] : type=AUTHOR/REPLY s t a t u s = 1 6 (AUTHOR/FAIL) Thu Nov 11 03 09 : 01 2004 [1943] : msg l e n = 0 , d a t a l e n = 0 a r g c n t = 0 Thu Nov 11 03 09 : 01 2004 [1943] : msg: Thu Nov 11 03 09 : 01 2004 Thu Nov 11 03 09 : 01 2004 Thu Nov 11 03 09 : 01 2004. [1943] : d a t a : [1943] : End p a c k e t [1943] : a u t h o r i z a t i o n. query f o r 'antoniovl.

(37) 28. Figura 7. Ejecución de fallida del comando show max_connections. consolé f r o m 1 7 2 . 1 7 . 1 . 1 9 8 r e j e c t e d. En contraste, la bitácora generada por la ejecución exitosa del comando show m a x _ c o n n e c t i o n s se muestra en la figura 8. Figura 8. Ejecución de exitosa del comando show max_connections. s e s s i o n r e q u e s t f r o m 172.17.1.198 1 Thu Nov 11 03 : 09: 20 20 04 [1894] sock=l Waiting f o r packet 2 Thu Nov 11 03 : 09: 20 2004 [1944] 3 Thu Nov 11 03: 09: 20 2004 [1944] H e a d e r R e a d OK, l e n = 12 4 Thu Nov 11 03 : 09: 20 2C04 [1944] v e r s i o n = 1 9 2 , t y p e = 2 , s e c n o = l , ene ses=672084364, d a t a l e n = 6720843641u 5 Thu Nov 11 03 : 09: 20 2004 [1944] l e n = 95 6 Thu Nov 11 03 : 09: 20 2004 [1944] R e a d AUTHOR s i z e = 9 5 7 Thu Nov 11 03: 09: 20 2004 [1944] v a l i d a t i o n r e q u e s t from 172.17.1.1 8 Thu Nov 11 03 : 09: 20 2004 [1944] PACKET: key=<NULL> 9 Thu Nov 11 03: 09: 20 2004 [1944] versión 192 (OxcO), t y p e 2, s e q no encryption 1 10 Thu Nov 11 03: 09: 20 2004 [1944] s e s s i o n i d 2352025384 (0x8c310f28) D a t a l e n g t h 82 (0x53) 11 Thu Nov 11 03 : 09: 20 2004 [19 4 4] End h e a d e r 12 Thu Nov 11 03: 09: 20 2004 [1944] type=AUTHOR, p r i v l v l = 1 5 , a u t h e n = l 13 Thu Nov 11 03: 09: 20 2004 [1944] method=tacacs+ 14 Thu Nov 11 03 : 09: 20 2004 [1944] s v c = l u s e r len=9 p o r t len=7 rem a d d r l e n = 1 2 15 Thu Nov 11 03 : 09: 20 2004 [1944] arg cnt=3 16 Thu Nov 11 03 : 09: 20 2004 [1944] User: 17 Thu Nov 11 03: 09: 20 2004 [1944] antoniovl 18 Thu Nov 11 03: 09: 20 2004 [ 1944 ] p o r t : 19 Thu Nov 11 03: 09: 20 2004 [1944] consolé 2 0 Thu Nov 11 03: 09: 20 2004 [1944] rem a d d r : 21 Thu Nov 11 03 : 09: 20 2004 [ 1944] 1 7 2 ? 1 7 . 1 . 1 9 8 22 Thu Nov 11 03 : 09 : 20 2004 [1944] arg[0]: size=13 23 Thu Nov 11 03 : 09: 20 2004 [1944] service=shell 2 4 Thu Nov 11 03 : 09: 20 2004 [1944] a r g [ 1 ] : s i ze=8 25 Thu Nov 11 03: 09: 20 2004 [1944] cmd=show 2 6 Thu Nov 11 03: 09: 20 2C04 [1944] arg[2]: size=23 27 Thu Nov 11 03: 09: 20 2004 [1944] cmd-arg=max c o n n e c t i o n s 2 8 Thu Nov 11 03: 09: 20 2004 [1944] End p a c k e t 2 9 Thu Nov 11 03: 09: 20 2 00 4 [19 4 4] S t a r t a u t h o r i z a t i o n r e q u e s t 30 Thu Nov 11 03 : 09: 20 2 0 0 4 [1944] user ' a n t o n i o v l ' found 31 Thu Nov 11 03 : 09: 20 2004 [1944] l i n e 5 c o m p a r e show d e n y ' a l l ' & 'max c o n n e c t i o n s ' no m a t c h 32 Thu Nov 11 03 : 09: 20 2004 [1944] l i n e 6 c o m p a r e show d e n y ' s e r v e r versión' & 'max c o n n e c t i o n s ' no m a t c h 33 Thu Nov 11 03 : 09: 20 2004 [1944] l i n e 7 compare show p e r m i t '.*' & 'max c o n n e c t i o n s ' m a t c h 34 Thu Nov 11 03: 09: 20 2004 line 7 35 Thu Nov 11 03: 09: 20 2004. [1944]. show max. c o n n e c t i o n s p e r m i t t e d by. [1944] : W r i t i n g AUTHOR/PASS ADD. size=18.

(38) 29. Figura 8. Ejecución de exitosa del comando show max_connections. 36 Thu Nov 11 03. 09 37 T h u Nov 11 03 09 encryption 1 38 Thu Nov 11 03 09 D a t a l e n g t h 6 (0x6) 3 9 Thu Nov 11 03 09 40 Thu Nov 11 03 09 (AUTHOR/PASS ADD) 41 Thu Nov 11 03 09 42 T h u Nov 11 03 09 4 3 Thu Nov 11 03 09 4 4 Thu Nov 11 03 09 4 5 Thu Nov 11 03 09 consolé f r o m 172 17. 20 2 0 0 4 [1944] : PACKET: key=<NULL> 20 20 0 4 [ 1944 ] :versión 192 (OxcO), t y p e 2, s e q no 20 2 0 04 [1 944 ] :s e s s i o n _ i d. 2352025384 ( 0 x 8 c 3 1 0 f 2 8 ) ,. 20 2004 [1944] : End h e a d e r 20 2 0 04 [1944 ] :type=AUTHOR/REPLY 20 2004 [ 1 9 4 4 ] : 20 2 0 0 4 [ 1944 ] 20 2004 [1944] : 20 2004 [1944] 20 2 0 0 4 [1944 ] 1. 198 a c c e p t e d. status=l. msg_len=0, d a t a _ l e n = 0 a r g _ c n t = 0 :msg: data : End p a c k e t :a u t h o r i z a t i o n q u e r y f o r ' a n t o n i o v l. A diferencia de los registros anteriores, en el listado se muestra la línea de la configuración en el servidor que permite la ejecución del comando formulado.. 5.2 Experimento #2: Prevenir que el usuario modifique las variables de ejecución. La modificación de una variable de ambiente se realiza mediante la instrucción S E T . El formato de la instrucción S E T es:. SET. [SESSION. | LOCAL] v a r i a b l e. {TO | = } {VALOR. | 'VALOR'. | DEFAULT}. No es posible alterar todas las variables de operación. Existen parámetros que de ser modificados afectarían demasiado al funcionamiento del software, como lo puede ser en número de puerto para comunicaciones TCP/IP, o la capacidad para recibir comunicaciones encriptadas. Una modificación importante que resulta útil poder controlar es el cambio de usuario que está operando sobre la base de datos. El formato del comando es:. SET. [SESSION. | LOCAL] SESSION AUTHORIZATION. usuario. La configuración en el servidor de autorización necesaria para esto se muestra a continuación..

(39) 30. user = antoniovl { d e f a u l t service = permit cmd = show { deny a l l d e n y s e r v e r versión p e r m i t .* }. cmd = s e t { deny s e s s i o n deny a u t h o r i z a t i o n p e r m i t .* }. La configuración complementa el ejemplo anterior. En un segundo bloque de instrucciones, se incluye el comando S E T con los argumentos requeridos. Figura 9 Cambio de Identidad de Usuario. La bitácora de la negación de ejecución de este comando se muestra a continuación, en la figura 10..

Figure

Actualización...

Referencias

Actualización...