PUBLICACIÓN DE TRABAJOS DE GRADO
Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de
grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como
parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en
versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor
(LFDA).
Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de
comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.
Cabe mencionar, que la Colección de
Documentos Tec,
donde se encuentran las tesis, tesinas y
disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del
Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,
para asegurar el uso restringido de dicha comunidad.
El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna
inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de
"Reforzamiento de la Seguridad de un Sistema Mediante un
Mecanismo de Autorización de Comandos"-Edición Única
Title
"Reforzamiento de la Seguridad de un Sistema Mediante
un Mecanismo de Autorización de Comandos"-Edición
Única
Authors
Antonio Varela Lizardi
Affiliation
Tecnológico de Monterrey, Universidad Virtual
Issue Date
2004-11-01
Item type
Tesis
Rights
Open Access
Downloaded
18-Jan-2017 22:15:12
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
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 SEGURIDAD DE UN SISTEMA MEDIANTE UN M E C A N I S M O DE 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 A S E S O R
M. en C. Abraham Aldaco
Gastélum SINODAL
M. en C. Guadalupe Alexandres García
ANTONIO V A R E L A LIZARDI
TESIS P R E S E N T A D A A LA FACULTAD DEL ITESM
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.
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.
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.
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
2 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 3 Metodología de investigación 12
4 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 5 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 6 Conclusiones y recomendaciones 37
Glosario de acrónimos 39 Bibliografía y referencias de Internet 40
Vita 41
[image:9.612.61.509.103.530.2]Lista de Figuras
Figura 1. Intentos fallidos de acceso a un sistema 7 Figura 2. Declaración de usuarios y grupos de usuarios 16
Figura 3. Seudo código para establecer comunicación con el servidor de
autorización 20 Figura 4. Ejecución de "show all" 24
Figura 5. Registro en la bitácora del comando "show all" 24
Figura 6. Ejecución de show server_version 26 Figura 7. Ejecución de fallida del comando show max_connections 26
Figura 8. Ejecución de exitosa del comando show max_connections 28
Figura 9 Cambio de Identidad de Usuario 30 Figura 10. Negación de la ejecución del comando S E T 31
Figura 11. Cambio de password para el agente 300 34 Figura 12. Cambio de password para el agente 201 35 Figura 13. Mostrar el password para el agente 300 35
Lista de Tablas
Tabla 1. Descripción de la Tabla Filiales 23 Tabla 2. Descripción de la Tabla Agentes 23
Figura 2. Declaración de usuarios y grupos de usuarios 16 Figura 3. Seudo código para establecer comunicación con el servidor de
autorización 20 Figura 4. Ejecución de "show all" 24
Figura 5. Registro en la bitácora del comando "show all" 24
Figura 6. Ejecución de show server_version 26 Figura 7. Ejecución de fallida del comando show max_connections 26
Figura 8. Ejecución de exitosa del comando show max_connections 28
Figura 9 Cambio de Identidad de Usuario 30 Figura 10. Negación de la ejecución del comando S E T 31
Figura 11. Cambio de password para el agente 300 34 Figura 12. Cambio de password para el agente 201 35 Figura 13. Mostrar el password para el agente 300 35
Lista de Tablas
Tabla 1. Descripción de la Tabla Filiales 23 Tabla 2. Descripción de la Tabla Agentes 23
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. Se 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.
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.
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
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 invulnerable1
.
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
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.
7
Figura 1. Intentos fallidos de acceso a un sistema.
s s h d :
A u t h e n t i c a t i o n F a i l u r e s :
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 ( 6 1 . 3 3 . 2 1 . 2 5 0 ) : 5 T i m e ( 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 ( 6 1 . 1 4 2 . 1 9 . 1 3 C ) : 2 T i m e ( s )
a p a c h e ( 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 T i m e ( s ) c y r u s ( 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 T i m e ( s ) f t p ( k a r p . e c e . c m u . e d u ) : 1 T i m e ( s )
m a i l ( k a r p . e c e . c m u . e d u ) : 1 T i m e ( s )
m y s q l ( 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 T i m e ( s ) m y s q l ( k a r p . e c e . c m u . e d u ) . : 1 T i m e ( s )
n o b o d y ( 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 T i m e ( s ) n o b o d y ( 6 1 . 1 4 2 . 1 9 . 1 3 0 ) : 1 T i m e ( 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 T i m e ( 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 sistemas2
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:
• Acceso 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
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 bruta3
. 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.
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 sistema4
. Otros usuarios encontrarán aquí una manera de obtener cierto "estatus" o reconocimiento.
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.
4
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
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
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.
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.
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.
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 s e a quebrantada por penetradores internos y externos, sin que los administradores de dichos servidores se enteren de ello, ya que:
• Un intruso puede conseguir a c c e s o5
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 e s 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 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
5
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 protocolo de autorización es de fácil implementación.
• Se cuenta con la especificación técnica del protocolo, disponible directamente con el fabricante, Cisco Systems.
• Es de configuración flexible. Se 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. Se 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
archivo6 de texto plano generalmente llamado tac_plus.conf.
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 u n 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
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ín7
que sea permitido en el sistema que se está protegiendo.
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:
t e l n e t 6 3 . 1 7 0 . < c u a l q u i e r número>.l t e l n e t 6 3 . < c u a l q u i e r n u m e r o > . 2 5 . 2 4 9
d e l e t e * . t x t
y cualquier otro comando será negado por omisión:
u s e r = a n t o n i o { c m d = t e l n e t {
p e r m i t 6 3 \. 1 7 0 \ . [ 0 - 9 ] + \ . 1
p e r m i t 6 3 . [ 0 - 9 ] + \ . 2 5 \ . 2 4 9
}
c m d = d e l e t e { p e r m i t * . t x t
} }
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
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:
u s e r = p e d r o {
d e f a u l t s e r v i c e = p e r m i t 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
d e f a u l t s e r v i c e = 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:
u s e r = a n t o n i o c o m m a n d = S E L E C T t o t a l a r g s = 2 a r g = p a s s w o r d
a r g = FROM u s u a r i o s
a r g = WHERE u s u a r i o = p e d r o
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
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. C a d a 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 E8
específico de cualquier otra plataforma. Actualmente se encuentran disponibles J R E y J D K9
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.
• 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.
p u b l i c b o o l e a n i n i t ( )
• 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.
p u b l i c b o o l e a n s e n d C m d ( S t r i n g a r g v [ ] )
Java Run-time Environment
9
• La función s e n d c m d construye un paquete TACACS+ apto para ser transmitido
por la red, a partir del comando y sus argumentos especificados en el array
a r g v [ ] . La función envía el paquete T A C A C S + 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 .
p u b l i c v o i d 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 d o n e = f a l s e ; 3 w h i l e ( d o n e == f a l s e ) {
4 S t r i n g c m d L i n e = i n . r e a d L i n e ( ) ; 5 i f ( c m d L i n e . e q u a l s ( " " ) ) {
6 d o n e = t r u e ; 7 } e l s e {
8 S t r i n g [ ] a r g v = c o n s t r u y e A r g s ( c m d L i n e ) ; 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 e x e c u t e C o m m a n d ( a r g v ) ; 11 } e l s e {
12 S y s t e m . o u t . p r i n t l n ( " N o a u t o r i z a d o . " ) ; 13 }
14 } 15 }
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
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 clienteservidor 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.
23
Tabla 1. Descripción de la Tabla Filiales.
Nombre de la Columna Tipo de Dato Descripción
i d j i l i a l S E R I A L Llave privada e identificador único.
nombre V A R C H A R ( 3 2 ) Nombre de la filial.
Tabla 2. Descripción de la Tabla Agentes.
Nombre de la Columna Tipo de Dato Descripción
id_agente S E R I A L Identificador único y llave
primaria.
i d j i l i a l I N T E G E R Llave foránea, relación con la tabla de Filiales.
numero V A R C H A R ( 1 6 ) Número de agente.
passwd V A R C H A R ( 1 6 ) 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:
u s e r = a n t o n i o v l {
d e f a u l t s e r v i c e = p e r m i t cmd = show {
d e n y .* }
}
[image:34.612.73.531.124.195.2] [image:34.612.68.531.231.358.2]Figura 4. Ejecución de "show all".
31 C:\WINDOWSVSys1em32kiiKl.<?*•• - lun _ C3 X
):sTenpNdbjcNsrc>run
):\Te»»p\db j 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 l o s 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 T h u 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 s o c k = l
2 T h u 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 T h u Nov 11 0 2 : 2 8 : 2 5 2004 [ 1 8 4 1 ] : H e a d e r R e a d 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 8 3 4 1 u
5 T h u Nov 11 02 28 25 2 0 0 4 [ 1 8 4 1 ] l e n = 83
6 Thu Nov 11 02 28 25 2 0 0 4 [ 1 8 4 1 ] R e a d AUTHOR s i z e = 8 3
7 Thu Nov 11 02 28 25 20 0 4 [1841] v a l i d a t i o n r e q u e s t f r o m 1 7 2 . 1 7 . 1 . 1 9 8 8 T h u Nov 11 02 28 25 2 0 0 4 [ 1 8 4 1 ] PACKET: key=<NULL>
9 Thu Nov 11 02 28 25 2004 [ 1 8 4 1 ] versión 192 ( O x c O ) , t y p e 2, s e q no 1, e n c r y p t i o n 1
10 T h u N o v 11 02 28 25 2 0 04 [ 1 8 4 1 ] s e s s i o n i d 3 3 9 6 4 1 9 1 3 9 ( 0 x c a 7 1 3 e 4 3 ) , D a t a l e n g t h 71 ( 0 x 4 7 )
11 T h u N o v 11 02 28 25 2 00 4 [ 1 8 4 1 ] End h e a d e r
12 T h u N o v 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 T h u Nov 11 02 28 : 25 2004 [ 1 8 4 1 ] • m e t h o d = t a c a c s +
[image:35.612.73.519.118.344.2] [image:35.612.73.515.513.727.2]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 [ 1 8 4 1 ] : a r g c n t = 3 16 T h u Nov 11 02 : 28 : 25 2 0 0 4 [ 1 8 4 1 ] : U s e r : 17 T h u Nov 11 02 : 28 : 25 2C04 [ 1 8 4 1 ] : a n t o n i o v l 18 T h u Nov 11 02 : 28 : 25 2 0 0 4 [ 1 8 4 1 ] : p o r t : 19 T h u Nov 11 02 : 28 : 25 2 00 4 [ 1 8 4 1 ] : consolé 2 0 T h u Nov 11 02 28 : 25 2004 [ 1 8 4 1 ] : rem a d d r : 21 T h u Nov 11 02 28 : 25 2C04 [ 1 8 4 1 ] : 1 7 2 7 1 7 . 1 . 1 9 8 2 2 T h u Nov 11 02 28 : 25 2 00 4 [ 1 8 4 1 ] : a r g [0] : s i z e = 1 3 23 T h u Nov 11 02 28 : 25 2C04 [ 1 8 4 1 ] : s e r v i c e = s h e l l 2 4 T h u Nov 11 02 28 : 25 2 C 0 4 [ 1 8 4 1 ] a r g [ 1 ] : s i ze=8 25 T h u Nov 11 02 28 : 25 2 0 0 4 [ 1 8 4 1 ] cmd=show
2 6 T h u Nov 11 02 28 : 25 2C04 [ 1 8 4 1 ] a r g [ 2 ] : s i z e = l 1 27 T h u Nov 11 02 28 : 25 2 0 0 4 [ 1 8 4 1 ] c m d - a r g = a l l 2 8 T h u Nov 11 02 28 : 25 2 0 0 4 [ 1 8 4 1 ] E n d p a c k e t
2 9 T h u Nov 11 02 28 25 2004 [ 1 8 4 1 ] 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 T h u Nov 11 02 28 25 2 00 4 [ 1 8 4 1 ] u s e r ' a n t o n i o v l ' f o u n d
31 T h u Nov 11 02 28 25 2004 [ 1 8 4 1 ] l i n e 5 c o m p a r e show d e n y & ' a l l m a t c h
32 T h u Nov 11 02 28 25 2004 [1841] show a l l d e n i e d b y l i n e 5 33 Thu Nov 11 02 28 25 2 0 0 4 [ 1 8 4 1 ] W r i t i n g AUTHOR/FAIL s i z e = 1 8 3 4 T h u Nov 11 02 28 25 2 0 04 [ 1 8 4 1 ] PACKET: key=<NULL>
35 T h u Nov 11 02 28 25 2004 [ 1 8 4 1 ] versión 192 ( O x c O ) , t y p e 2, s e q no 2 e n c r y p t i o n 1
3 6 T h u Nov 11 02 : 28 25 200 4 [ 1 8 4 1 ] s e s s i o n i d 3 3 9 6 4 1 9 1 3 9 ( 0 x c a 7 1 3 e 4 3 ) , D a t a l e n g t h 6 (0x6)
37 T h u Nov 11 02 : 28 25 2004 [ 1 8 4 1 ] E n d h e a d e r
38 T h u Nov 11 02 : 28 25 2004 [ 1 8 4 1 ] type=AUTHOR/REPLY s t a t u s = 1 6 (AUTHOR/FAIL)
3 9 T h u Nov 11 02 : 28 25 2 0 0 4 [ 1 8 4 1 ] msg l e n = 0 , d a t a l e n = 0 a r g c n t = 0 4 0 T h u Nov 11 02 :28 25 2004 [ 1 8 4 1 ] msg:
41 T h u Nov 11 02 :28 25 2004 [1841] d a t a :
4 2 T h u Nov 11 02 : 28 25 2004 [ 1 8 4 1 ] E n d p a c k e t
4 3 T h u Nov 11 02 : 28 25 2004 [ 1 8 4 1 ] 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 ' consolé f r o m 172 . 17 1 . 198 r e j e c t e d
Como podemos observar, la bitácora contiene la información importante para un sistema de autoría.
• Se 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).
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.
u s e r = a n t o n i o v l {
d e f a u l t s e r v i c e = p e r m i t cmd = show {
d e n y 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 s h o w
[image:37.612.76.522.376.596.2]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. 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 i c a r e l password de un agente 9: Specify custon query
nter your choice: 99
ustom Query:«how nax_connections
dbjc.Hain cor»\niotoSdbj
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.
27
Figura 7. Ejecución de fallida del comando show max_connections.
T h u N o v 11 03 : 0 9 : 01 2004 1 9 4 3 ] : W a i t i n g f o r p a c k e t
T h u N o v 11 0 3 : 09: 01 2004 1 9 4 3 ] : H e a d e r R e a d OK, l e n = 12
T h u Nov 11 0 3 : 0 9 : 01 2004 1943] v e r s i o n = 1 9 2 , t y p e = 2 , s e c n o = l , enc= 1 s e s = =3098509974, d a t a l e n = 3 l 9 8 5 0 9 9 7 4 1 u
T h u Nov 11 03 : 0 9 : 01 2004 1943] • l e n = 94
T h u Nov 11 0 3 : 09 : 01 2004 1943] R e a d AUTHOR s i z e = 9 4
Thu Nov 11 03 : 0 9 : 01 2004 1943] v a l i d a t i o n r e q u e s t f r o m 1 7 2 . 1 7 . 1 . 1 9 8 T h u Nov 11 0 3 : 09: 01 2004 1943] PACKET: key=<NULL>
T h u Nov 11 0 3 : 0 9 : 01 2004 1943] versión 192 ( O x c O ) , t y p e 2, s e q no 1 e n c r y p t i o n 1
T h u 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 ) , l e n g t h 82 ( 0 x 5 2 )
T h u N o v 11 0 3 : 0 9 : 01 2004 1943] E n d 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
T h u Nov 11 03 : 0 9 : 01 2004 [1943] m e t h o d = t a c a c s +
T h u Nov 11 03 : 09- 01 2004 [1943] 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
Thu Nov 11 0 3 : 09 01 2004 [ 1 9 4 3 ] a r g c n t = 3 T h u Nov 11 03 : 09 01 2004 [1943] U s e r : T h u N o v 11 03 : 09 01 2004 [1943] a n t o n i o v l T h u Nov 11 0 3 : 09 01 2004 [1943] p o r t : T h u Nov 11 03 : 09 01 2004 [1943] consolé T h u Nov 11 0 3 : 09 01 2004 [1943] rem a d d r : T h u Nov 11 0 3 : 09 01 2004 [1943] 1 7 2 . 1 7 . 1 . 1 9 8 Thu N o v 11 03 09 01 2004 [1943] a r g [ 0 ] : s i z e = 1 3 T h u N o v 11 03 09 01 2004 [1943] s e r v i c e = s h e l l T h u N o v 11 03 09 01 2004 [1943] a r g [ 1 ] : s i z e = 8
T h u 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
T h u Nov 11 03 09 01 2004 [1943] c m d - a r g = s e r v e r versión T h u N o v 11 03 09 01 2004 [1943] E n d p a c k e t
T h u N o v 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 T h u 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
T h u 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
T h u N o v 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
T h u 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 T h u 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>
T h u Nov 11 03 09 01 2004 [1943] : versión 192 ( O x c O ) , t y p e 2, s e q no 2 e n c r y p t i o n 1
T h u 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 ) , l e n g t h 5 ( 0 x 6 )
T h u Nov 11 03 09 01 2004 [1943] : E n d h e a d e r
T h u Nov 11 03 09 : 01 2004 [1943] : type=AUTHOR/REPLY s t a t u s = 1 6 (AUTHOR/FAIL)
T h u 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 T h u Nov 11 03 09 : 01 2004 [1943] : msg:
T h u N o v 11 03 09 : 01 2004 [1943] : d a t a : T h u Nov 11 03 09 : 01 2004 [1943] : E n d p a c k e t
T h u Nov 11 03 09 : 01 2004 [1943] : 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 D a t a
[image:38.612.72.507.118.714.2]
