T E S I Stesis.ipn.mx/jspui/bitstream/123456789/3693/1/DIRECTORIODEADMON.pdf · trajiste la...

187
Instituto Politécnico Nacional Centro de Investigación en Computación DIRECTORIO DE ADMINISTRACION DE APLICACIONES, LLAMADAS DE SISTEMA Y UTILITARIOS DEL SISTEMA OPERATIVO LINUX T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN P R E S E N T A EL ING. MANUEL ALEJANDRO SOTO RAMOS DIRECTOR DE TESIS: DR. FELIPE ROLANDO MENCHACA GARCIA MÉXICO, D.F. Junio 2008

Transcript of T E S I Stesis.ipn.mx/jspui/bitstream/123456789/3693/1/DIRECTORIODEADMON.pdf · trajiste la...

Instituto Politécnico Nacional

Centro de Investigación en Computación

DIRECTORIO DE ADMINISTRACION DE APLICACIONES, LLAMADAS DE SISTEMA

Y UTILITARIOS DEL SISTEMA OPERATIVO LINUX

T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACIÓN

P R E S E N T A

EL ING. MANUEL ALEJANDRO SOTO RAMOS

DIRECTOR DE TESIS: DR. FELIPE ROLANDO MENCHACA GARCIA

MÉXICO, D.F. Junio 2008

RESUMEN Los sistemas informáticos se han convertido en parte fundamental de nuestro método de vida, cada día incrementa el número de actividades relacionadas con el almacenamiento e intercambio de información en formato electrónico. De la misma forma, también han incrementado el número de amenazas informáticas orientadas a obtener, manipular, negar o destruir la información almacenada en los sistemas electrónicos. Como consecuencia, la seguridad informática en la actualidad es un aspecto al que se le presta mucha atención, la mayoría de las acciones se enfocan en la prevención, pero no es algo que se pueda garantizar debido a que depende de múltiples factores, los cuales abarcan desde el mismo código del programa, pasando por los mecanismos y las políticas de seguridad del lugar hasta llegar a la actuación del usuario del equipo. De modo tal, que la detección y el tiempo de respuesta ante intrusiones toma relevancia. Con base a lo descrito anteriormente surge esta investigación, orientada al conocimiento de las amenazas informáticas, las metodologías de los sistemas de prevención y detección de intrusos, con las cuales se propone una metodología de detecciones basada en la integridad de la información para los sistemas operativos Linux. Se implementa esta metodología en un entorno de red con un elemento de análisis en cada cliente y un servidor que recopila, procesa y almacena la información de manera automática en intervalos de tiempo previamente establecidos, utilizando como referencia un directorio constituido por la información sensible para el funcionamiento de cada uno de los sistemas. Algunas de las contribuciones de este trabajo son la reducción del tiempo de detección de intrusiones en los directorios del sistema operativo y la generación de reportes en un elemento centralizado, lo que permite el análisis de varios equipos de cómputo. Las pruebas realizadas permiten determinar la capacidad de detección de intrusiones de la herramienta propuesta, determinar la cantidad de recursos utilizados y el tiempo requerido para el análisis de los equipos de cómputo.

ABSTRACT The computer systems have become an essential part of our method of life, every day increases the number of activities related to the storage and exchange of information in electronic format. In the same way, also they have increased the number of cyber threats aimed at obtaining, handling, deny or destroy the data stored in electronic systems. As a result, computer security at present is an aspect to which have much attention, most actions are focused on prevention, but is not something that can be guaranteed because it depends on many factors, which include from the same program code, through the mechanisms and security policies of the place until it reaches the user's performance of the computer. So, that the detection and the response time before intrusions take relevance With base to the described thing previously, this research oriented to the knowledge of cyber threats, methods of prevention systems and intrusion detection, which proposes a methodology based on detections integrity of information for Linux operating systems. This methodology is implemented in a networked environment with an element of analysis in each client and a server that collects, processes and stores information automatically at intervals of time previously established, using as references a directory consisting of sensitive information for operation of each of the system. Some of the contributions of this work are the reduction of intrusion detection time of intrusions in the directories operating system and the generating reports in a centralized element, allowing the analysis of several computers counting. The realised tests conducted to determine the ability of intrusion detection tool of the proposal, determine amount of used resources and the time required for analysis of the computers.

A mis padres que me regalaron lo mas maravilloso que existe en este mundo....... La vida y su amor.

Por ser mi maestro, guía, ejemplo, cómplice, motivador y todas las cosas que es imposible describir; Por ser mi amigo y confiar en mi, por los momentos que me regalas de tu tiempo aun cuando ya es de madrugada, por todo el cariño que me has dado, espero darte muchos momentos de satisfacción como este, es la única forma en que puedo devolver lo que tu haces por mi Papá

Por preocuparte siempre, por tus regaños y caricias, por alentarme y brindarme un hogar lleno de amor, por darme consejos y ser una persona triunfadora que trabaja cada día por su familia, por los días que nos hacías falta y no te teníamos cerca; gracias Mamá. A Faby por ser mi hermanita y compartir muchos años de travesuras y juegos, a Dany por su buen humor en cualquier momento (aun en los peores), a Giovanni por su ejemplo de esfuerzo y actitud, a Luis Antonio por ser parte de un nuevo ciclo dentro de nuestra vidas, a todos les agradezco la infinidad de veces que me han ayudado. Se que siempre estaremos juntos por encima de las diferencias que lleguemos a tener.

Por la cantidad interminable de veces que interrumpiste mi trabajo para compartir tu tiempo conmigo. Porque tu llegada a nuestra familia le dio un giro a nuestras vidas, trajiste la tranquilidad y armonía de regreso, llenas de color y vida la casa con tus risas, por todas las veces que subiste las escaleras para abrazarme y hacer que renovara las ideas plasmadas en este trabajo, te quiero muchísimo Luisma. A mis “hermanos” los Chuchos por haberme invitado a ser parte de esta hermandad, por ganar esos dos campeonatos y por todos los partidos que perdimos. De forma especial, por aquel día en que me salvaron de cometer un error hubiera evitado que estuviera donde hoy estoy y ser lo que soy, por aquel viaje a Puebla, les estaré siempre agradecido.

Por escucharme siempre, acompañarme en las etapas difíciles, por brindarme un buen consejo, hacerme poner siempre los pies en la tierra, enseñarme el valor de las cosas y de las personas, por crecer junto a mi, por jugar conmigo y por hacerme ver siempre mis errores sin maquillaje; por buscar lo mejor para mi y ser ese tipo de persona que me hace sentir seguro de tener un buen amigo, gracias Compaigre. A Marco Antonio Fragozo Olvera, mi papí, por los años de amistad y ser siempre alguien que me apoya en lo que me propongo, por tu forma de enseñarme tantas cosas de esta vida, por ser como un hermano mayor para mi, gracias por incluirme en tu familia, que Dios te cuide siempre y tengas la felicidad junto a Faby. Casi 10 años de camino juntos con altibajos, diferencias y promesas que regularmente hemos cumplido. No siempre será así, tendremos caminos separados pero quisiera contar contigo si algún día lo necesito, cuídate y mucha suerte David.

A mis amigos del CONA, los profesores Ángeles, Silver, Mónica, Sonia, Raúl, Jose Jorge, Charly, Paty y Neta por hacerme la estancia dentro del trabajo muy divertida, por sus consejos, apoyo, bromas y por dejarme ser parte de ese grupo. A todos mis niños, siempre me motivaron a crecer como persona, no seré el mejor profesor que tengan, pero nunca dejare de intentarlo. Gracias por todas las muestras de afecto que me han brindado desde mi llegada al plantel, me permitieron compartir conocimientos con ustedes y espero haberlos motivado a ser mejores cada día.

A Paty por acompañarme en el camino de este trabajo, hubiera terminado muchísimo tiempo después sin tu ayuda, gracias por doblegar mi obsesión de hacerlo todo y hacerme ver mis errores, por hacer de un instante común algo especial.... cuando puedo compartirlo contigo.

A los niños CIC: Adrian, Adriana, Obdulia, Edgar, Lilis, Arrianita, Hector, Isma, David, Mochis, Josué y todos los del niños del cic-fut, gracias por regalarme de su tiempo y dejarme conocerlos. Al doctor Felipe Rolando Menchaca le agradezco todo el tiempo que me regalo y compartió sus conocimientos, por todo el apoyo que me brindo desde mi llegada a este centro pero sobre todo, por ser un gran ejemplo de motivación y superación. A mis sinodales por el tiempo invertido en la revision del material y la aportación de su experiencia en este trabajo. Al CONACYT por el apoyo brindado para la realización de los estudios dentro de este centro.

Si pudiera escribir el nombre de todas las personas

que han colaborado a que presente este trabajo necesitaría bastantes hojas, si debiera agradecer

a todas las personas que me han apoyado, enseñado y acompañado hasta el día de hoy; ocuparía mas

hojas que las de esta tesis; por esta razón, les estoy agradecido por su aportación a la realización de mis metas y les pido una disculpa, ya que sin ser menos

importantes omití su nombre.

Índice.

I

Índice Pág.

Lista de figuras…………………………………………………………………….… VI

Lista de tablas………………………………………………………………………… VIII

INTRODUCCIÓN.

Antecedentes……………………………………………...……………....... IX

Planteamiento del problema………………………………………………. IX

Objetivos……..………………………………...……………………………. X

Justificación…………………………………………………...……………... XI

Beneficios Esperados………………………………………………......…. XII

Alcances…………………………………………………………………….... XIV

Límites………………………………………..………………………............ XV

Organización de la Tesis……………………………………………...……. XV

CAPÍTULO 1. ESTADO DEL ARTE.

1.1 Historia de los sistemas de auditoria y detección de intrusos….……. 2

1.2 Estructura de los sistemas de detección de intrusos……………….. 3

1.2.1 Definición de IDS……..…………………………………………… 3

1.2.2 Elementos de los sistemas de identificación de intrusos………. 5

1.2.2.1 Fuentes de Información…………...………………………….. 5

1.2.2.2 Análisis………………………………………..…………............. 6

1.2.2.3 Respuesta……………………………………………..…………. 6

1.2.2.4 Capacidades de generación de reportes y archivado………. 7

1.2.2.5 Estrategia de Control………………………………………….. 7

1.2.2.6 Tiempo de análisis…………………………………………….. 8

1.2.3 Métodos de detección de anomalías……………………………… 8

1.2.3.1 Métodos detección de anomalías alternativas……………… 9

1.3. Situación actual de los sistemas IDS………………………………... 12

1.4 Herramientas de detección de intrusos en Linux………………….… 13

1.4.1. Snort…………..……………………………………………………… 14

1.4.2. Tripwire………………………………………………………………. 14

1.4.3. Inotify…………………………..………………………………….… 16

Índice.

II

Pág.

CAPÍTULO 2. MARCO TEÓRICO.

2.1 La seguridad informática………………………………………………..… 17

2.1.1 Elementos a proteger………………………………………………... 17

2.1.2 Intrusos o atacantes…………………………………………………. 18

2.1.3 Amenazas lógicas……………………………………………………. 19

2.1.4 Los mecanismos de prevención más habituales en Linux……… 21

2.1.5 Canales de comunicación seguros SSH………………………….. 23

2.1.6 Estándares de seguridad…………………………………………… 26

2.2 Arquitectura del sistema operativo Linux…………………………....... 27

2.2.1 Breve historia de GNU/Linux…………………………………..….. 28

2.2.2 Distribuciones Linux………………………………………………... 28

2.2.3 Características generales de Linux……………………………….. 29

2.2.4. Directorios en Linux………………………………………………… 30

2.2.4.1 Sistema de directorios……………………………………….. 31

2.2.4.2 Las cuentas de los usuarios………………………………... 33

2.2.4.3 Mecanismos de protección……………………………….… 33

2.2.4.4 Los archivos de inicialización del sistema…………..…….. 35

2.2.4.5 Detección de archivos que comprometen la seguridad.... 35

2.4.4.6 Modificación del sistema de directorios……………….…. 35

2.4.4.7 Modificación del esquema de permisos………………….. 38

2.2.4.8 Escalamiento de permisos………………………………….. 38

2.2.4.9 Detección de modificaciones en los archivos del sistema. 39

2.2.5 Procesos……………………………………………………………… 40

2.2.6 Intérprete de comandos……………………………………………. 41

2.2.7 Sistema de almacenamiento de sucesos……………………….. 42

2.2.7.1 El demonio syslogd…. ………………………………………..….. 42

2.2.7.2 Auditoria de seguridad…………………………………………… 42

2.3 Entorno de trabajo del servidor de monitoreo………………….……. 43

2.3.1 Servidor de páginas web…………………………………………... 43

2.3.2 Servidor de base de datos………………………………………... 43

2.4 Comentarios finales……………………………………………………... 44

Índice.

III

Pág. CAPÍTULO 3. ANÁLISIS Y DISEÑO DEL SISTEMA.

3.1 Análisis y diseño del sistema de detección de intrusos....................... 45

3.2 Requerimientos……………………………………………………………. 45

3.3 Análisis de los requerimientos………………………………………….. 47

3.4 Arquitectura general del sistema…..………………………………..……. 48

3.4.1 Capas de diseño…………………………………………………….. 51

3.4.2 Tiempos de respuesta y de análisis…………………………..…. 52

3.4.3 Uso de recursos……………………………………………………... 52

3.4.4 Plataformas………………………………………………………….. 52

3.5 Descripción de los procesos……………………………..…………….. 53

3.6 Modelo funcional…………………………………………………………. 55

A) Conexión segura…………………………………………………… 56

B) Análisis de sistema cliente……………………………………….. 58

C) Búsqueda de cambios…………………………………………..… 60

D) Base de datos modificaciones……………………………………... 62

E) Impresión de informes…………………………………………….. 64

F) Generación de perfil de usuario………………………………..… 66

G) Administración y actualización de cambios………………….... 68

H) Sistema de respaldo………………………………………………. 70

CAPÍTULO 4. IMPLEMENTACIÓN DEL SISTEMA.

4.1 Estructura de la aplicación…………………………………………….… 73

4.2 Sistema de detección de intrusos DAYUSOL………………………… 74

4.2.1. Entorno de red………………………………………………………. 75

4.2.2. Canal de comunicación seguro…………………………………… 76

4.2.3 Análisis de sistema (sensor)……………………………………….. 77

4.2.4. Directorio de aplicaciones………………………………………… 79

4.2.4.1. Detección de modificaciones……………………………………... 80

4.2.4.2. Base de datos intrusiones………………………………………. 82

4.2.4.3. Generación de perfil de usuario……………………………….. 82

4.2.4.4. Políticas de análisis de integridad……………………………... 82

4.3 Administración y actualización de cambios…………………………….. 85

Índice.

IV

Pág.

4.3.1. Base de datos de estadísticas y reportes de incidentes……… 85

4.3.2. Reportes de intrusiones usando correo electrónico……………. 87

4.4 Respaldo de archivos……………………………………………………. 87

4.4.1. Políticas de respaldo de información…………………………….. 87

4.4.2. Respaldo y restauración de datos …..…………………………… 88

4.4.3. Espacio y encriptación…………………………………………….. 88

4.5. Comentarios finales……………………………………………………… 88

CAPÍTULO 5. PRUEBAS DEL SISTEMA DAYUSOL

5.1 Sistema de directorios del cliente DAYUSOL………………………. 89

5.1.1 Utilitarios del sistema DAYUSOL………………………………… 91

5.2. Actualización de cambios de DAYUSOL……………………………. 93

5.3. Interfaz grafica de usuario y reportes……………………………….. 93

5.3.1. Alarma de DAYUSOL mediante correo electrónico……………. 96

5.4. Análisis de fiabilidad e integridad de los sistemas DAYUSOL……… 97

5.4.1. Técnicas utilizadas para la evaluación

de detección de intrusos... ……………………………………. 97

5.4.1.1. Modificaciones DAYUSOL……………………………………... 98

5.4.1.2. Instalación de software mediante gestores de paquetes....... 100

5.4.1.3. Modificación de permisos, usuario, grupo, guid………..… 102

5.5. Pruebas de rendimiento para DAYUSOL en el cliente………………. 106

5.5.1. Pruebas de rendimiento para el cliente 192.168.1……………… 106

5.5.2. Utilización de recursos en el cliente 192.168.1.10………….... 107

5.4.3. Utilización de recursos en el cliente 192.168.1.11………........ 108

5.4.3. Utilización de recursos en el cliente 192.168.1.20……………. 109

5.5. Comentarios finales……………………………………………………. 110

CAPITULO 6. CONCLUSIONES Y TRABAJOS A FUTURO

6.1. Conclusiones………………………………………………………..……. 111

6.2. Trabajos a futuro……………………………………………………..… 112

Índice.

V

Pág.

BIBLIOGRAFÍA…...…………………………………..……………………………..… 113

GLOSARIO………………………………………………..………………………….… 115

ANEXO 1. Manual de usuario……………………………………………………….. 119

ANEXO 2. Políticas y código fuente…………………………………………..…. 123

Índice de figuras.

VI

Índice de figuras

Nombre Pág

Figura 1.1. Tipos de intrusiones………………………………………………….. 4

Figura 1.2. Clasificación de los IDS……………………………………………… 7

Figura 1.3. Estado de arte de los IDS……………………………………………. 12

Figura 1.4. Diagrama de flujo de Tripwire……………………………………….. 15

Figura 1.5. Generacion de reportes de Tripwire………………………………… 16

Figura 1.6. Reportes de Tripwire Enterprise…………………………………….. 16

Figura 2.1. Arquitectura cliente-servidor de SSH……………………………….. 24

Figura 2.2. Arquitectura de SSH………………………………………………….. 25

Figura 2.3. Canal de comunicación cifrado usando SSH……………………… 26

Figura 2.4. Autenticación de SSH usando llaves públicas…………………….. 26

Figura 2.5. Sistema de directorio de archivos Linux.…………………………… 33

Figura 2.6. Arquitectura del sistema operativo Linux…………………………... 37

Figura 3.1. Esquema general del sistema……………………………………….. 48

Figura 3.2. Modelo funcional……………………………………………………… 55

Figura 3.3. Diagrama de estados………………………………………………… 56

Figura 3.4. Gráfico de Estados de Conexión Segura…………………………... 57

Figura 3.5. Diagrama de actividades del sistema Conexión Segura…………. 57

Figura 3.6. Gráfico de Estados de Análisis de sistema………………………… 58

Figura 3.7. Diagrama de actividades del sistema Análisis…………………….. 59

Figura 3.8. Gráfico de estados de Búsqueda de cambios…………………….. 60

Figura 3.9. Diagrama de actividades del sistema Análisis…………………….. 61

Figura 3.10. Gráfico de estados de Base de datos modificaciones…………... 62

Figura 3.11. Diagrama de actividades del sistema Base de datos modificaciones………………………………………………………..……………..

63

Figura 3.12. Gráfico de Estados de Impresión de Informes…………………... 64

Figura 3.13. Diagrama de actividades del sistema Impresión de Informes….. 65

Figura 3.14. Gráfico de Estados de Generación de perfil de usuarios……….. 66

Figura 3.15. Diagrama de actividades del sistema Impresión de Informes..... 67

Figura 3.16. Gráfico de Estados de Administración y actualización de cambios………………………………………………………………………………

68

Figura 3.17. Diagrama de actividades del sistema administración y actualización de cambios…………………………………………………………..

69

Figura 3.18. Gráfico de Estados del sistema Respaldos………………………. 70

Figura 3.19. Diagrama de actividades del sistema Respaldos………………... 71

Figura 3.20. Casos de uso del IDS………………………………………………. 71

Figura 3.21. Arquitectura de la metodología propuesta………………………... 72

Figura 4.1. Arquitectura de DAYUSOL………………………………………….. 74

Figura 4.2. Diagrama de entorno de red DAYUSOL…………………………... 75

Figura 4.3. Integridad de archivos utilizando funciones compendio………….. 76

Figura 4.4. Estructura del directorio de usuarios DAYUSOL………………….. 79

Figura 4.5. Estructura detallada del directorio REMOTO……………………… 80

Figura 4.6. Búsqueda de modificaciones………………………………………... 81

Figura 4.7. Dase de datos Entidad-Relación de DAYUSOL…………………... 86

Índice de figuras.

VII

Nombre Pag

Figura 5.1. Escenario de pruebas de DAYUSOL……………………………….. 89

Figura 5.2. Árbol de directorio de cliente de DAYUSOL……………………….. 90

Figura 5.3. Árbol de directorio de cliente de DAYUSOL después la de detección de intrusos……………………………………………………………….

90

Figura 5.4. Líneas del archivo de reporte después la de detección de intrusos……………………………………………………………………………….

91

Figura 5.5. Contenido del archivo instalados……………………………………. 92

Figura 5.6. Árbol de directorio de cliente de DAYUSOL con los respaldos de /etc y /usr…………………………………………………………………………….

92

Figura 5.7. Consulta del estado de los clientes en DAYUSOL2008………….. 93

Figura 5.8. Tablas de la base de datos DAYUSOL208………………………… 93

Figura 5.9. Interfaz REPORTE DE RED………………………………………… 94

Figura 5.10. Interfaz REPORTE DE HOST……………………………………… 95

Figura 5.11. Interfaz REPORTE DETALLADO…………………………………. 96

Figura 5.12. Reportes en formato electrónico (.PDF)………………………….. 96

Figura 5.13. Bandeja de entrada de correo electrónico con los reportes de DAYUSOL……………………………………………………………………………

97

Figura 5.14. Contenido del correo electrónico enviado por DAYUSOL……… 97

Figura 5.15. Elementos detectados por DAYUSOL en el cliente Router…….. 98

Figura 5.16 Elementos detectados por DAYUSOL en el cliente Moniton……. 99

Figura 5.17. Elementos detectados por DAYUSOL en el cliente Alexin……... 100

Figura 5.18. Elementos detectados por DAYUSOL en la instalación de paquetes con APT…………………………………………………………………..

101

Figura 5.19. Registros de DAYUSOL 2008 de los paquetes instalados con APT……………………………………………………………………….................

102

Figura 5.20. Reporte de RED de DAYUSOL posterior a la intrusión Zeus y Remote Shell….………………………………………………………………….....

103

Figura 5.21. Reporte de HOST de DAYUSOL posterior a la intrusión Zeus y Remote-Shell………………………………………………………………………..

104

Figura 5.22. Reporte DETALLADO de DAYUSOL posterior a la intrusión Zeus y Remote-Shell……………………………………………………………….

104

Figura 5.23. Correo electrónico recibido debido a la intrusión Zeus y Remote-Shell………………………………………………………………………..

105

Figura 5.24. Detección del montaje de dispositivos en el mismo análisis de la intrusión Zeus y Remote-Shell………………………………………………….

105

Figura 5.25 Recursos utilizados por DAYUSOL en cliente Router…………… 107

Figura 5.26 Recursos utilizados por DAYUSOL en cliente Moniton………….. 108

Figura 5.27 Recursos utilizados por DAYUSOL en cliente Alexin……………. 109

Figura 5.28 Recursos utilizados por DAYUSOL en cliente Alex-lap-hp……… 110

Figura 5.28 Carga de trabajo durante el análisis con DAYUSOL en cliente Alex-lap-hp…………………………………………………………………………..

110

Índice de tablas.

VIII

Índice de tablas.

Nombre Pág.

Tabla 2.1. Posibles combinaciones de permisos……………………………….... 34

Tabla 3.1. Nivel de riesgo de directorios en el sistema operativo Linux………. 49

Tabla 3.2. Parámetros de validación de permisos de los archivos…………….. 50

Tabla 3.3. Política de propiedades de archivo…………………………………… 50

Tabla 3.4. Política integridad de archivo………………………………………….. 50

Tabla 3.5. Procesos principales del IDS propuesto……………………………… 53

Tabla 3.6. Crear perfil del cliente…………………………………………………... 53

Tabla 3.7. Instalar perfil del cliente………………………………………………… 54

Tabla 3.8. Programación de ejecución……………………………………………. 54

Tabla 3.9. Establecer método de autenticación………………………………….. 54

Tabla 3.10. Establecer método de conexión……………………………………… 54

Tabla 3.11. Establecer estructura de análisis…………………………………….. 54

Tabla 3.12. Establecer métodos de análisis de integridad……………………… 54

Tabla 3.13. Establecer métodos de impresión de reportes de análisis………... 55

Tabla 3.14. Mostar estado del cliente……………………………………………... 55

Tabla 3.15. Descripción de Conexión segura…………………………………….. 56

Tabla 3.17. Descripción análisis del cliente………………………………………. 58

Tabla 3.18. Descripción de búsqueda de cambios………………………………. 60

Tabla 3.19. Descripción de base de datos de modificaciones………………….. 62

Tabla 3.20. Descripción de impresión de informes………………………………. 64

Tabla 3.21. Descripción de generación de perfil de usuario……………………. 66

Tabla 3.22. Descripción de administración y actualización de cambios………. 68

Tabla 3.23. Descripción del sistema de respaldos………………………………. 69

Tabla 4.1. Especificaciones del entorno de red de DAYUSOL…………………. 75

Tabla 4.2. Especificaciones del SSH implementado en DAYUSOL…………… 76

Tabla 4.3. Especificaciones de estructura de archivos en DAYUSOL………… 77

Tabla 4.4. Especificaciones de compendios en DAYUSOL…………………….. 78

Tabla 4.5. Resumen de sensores de DAYUSOL………………………………… 78

Tabla 4.6. Directorio de aplicaciones de DAYUSOL…………………………….. 80

Tabla 4.7. Estructura de políticas de DAYUSOL………………………………… 83

Tabla 4.8. Estructura de políticas de DAYUSOL………………………………… 83

Tabla 4.9. Políticas y riesgo implementados en DAYUSOL……………………. 84

Tabla 4.10. Programaciones de análisis utilizadas en DAYUSOL……………... 85

Tabla 4.11. Base de datos de estadísticas y reportes de DAYUSOL…………. 86

Tabla 5.1. Resumen de modificaciones en el cliente Router…………………… 98

Tabla 5.2. Resumen de modificaciones en el cliente Moniton………………….. 99

Tabla 5.3. Resumen de modificaciones en el cliente Alexin……………………. 100

Tabla 5.4. Resumen de modificaciones con la instalación de paquetes………. 101

Tabla 5.5. Características de hardware del cliente Router……………………… 106

Tabla 5.6. Características de hardware del cliente Miniton…………………….. 106

Tabla 5.7. Características de hardware del cliente Alexin………………………. 108

Tabla 5.8. Características de hardware del cliente Alex-lap-hp………………... 109

Introducción.

IX

INTRODUCCIÓN.

Este apartado plantea los antecedentes, la definición del problema, la justificación, los objetivos que se buscan alcanzar; además de los beneficios esperados al término del proyecto de investigación.

Antecedentes.

La seguridad informática es un aspecto al que se le presta mucha atención en la actualidad; como consecuencia del valor que se le ha dado a la información almacenada en los equipos de cómputo y al desarrollo de grandes redes como lo es internet; las empresas e instituciones aceptan los riesgos de este entorno de intercomunicaciones distribuido y se preocupan cada vez mas por la seguridad de sus sistemas. Una parte importante de la seguridad de la información en los equipos de cómputo recae en el sistema operativo, la forma en que está diseñado, las políticas de seguridad que implementa, la gestión de los usuarios y los permisos de realizar determinadas tareas, el tiempo que transcurre entre la detección de un error en la programación (bug) y la corrección de este, además de los sistemas de protección instalados [1]. Un sistema de protección utilizado en los equipos de cómputo actualmente es la detección de intrusos (IDS), básicamente es una herramienta que permite al administrador del sistema detectar ataques informáticos, monitorear su comportamiento, incrementar la seguridad y reducir las vulnerabilidades frente ataques de diversas características [2]. Lo que se persigue con esta herramienta es disminuir los incidentes de ataques a los que se ven sometidos los sistemas informáticos, el manejo de estos cuando ya se han realizado, las medidas que se deben tomar para restaurar el sistema y las adecuaciones para evitar que sucedan otra vez, además de la generación de reportes de incidentes para tener un análisis de los riesgos a los que se enfrentan. En este contexto, es necesario realizar un análisis de los marcos de referencia de la administración del sistema operativo, las amenazas informáticas existentes, las metodologías de funcionamiento de los sistemas de detección de intrusos y las herramientas que se implementan para este propósito. El presente trabajo de tesis aborda el diseño de una metodología y su implementación para la de detección de modificaciones en el sistema operativo Linux; hace uso del conocimiento de las amenazas informáticas existentes, el almacenamiento de los informes del sistema, los conceptos de integridad de la información, las técnicas criptográficas que proporcionan la base de autenticación y la certificación de los usuarios en sistemas electrónicos.

Planteamiento del Problema. Se ha observado un incremento notable de usuarios de equipo de cómputo con plataformas Linux en los últimos años [3]; gradualmente, también ha crecido el número de software malicioso generado para este sistema operativo [4]. Por esta razón, muchos desarrolladores en todo el mundo se dan a la tarea de crear programas que mejoren la seguridad de los sistemas, sin embargo no siempre se puede estar completamente protegido. En algún momento, el equipo presentará vulnerabilidad y esta será aprovechada por alguien con malas intenciones; por lo que existe la posibilidad de una intrusión, si el sistema no cuenta con las herramientas necesarias para la detección, el administrador podría pasar

Introducción.

X

días en saber que ha sucedido un ataque informático, mientras mas tiempo transcurra desde la intrusión, el volumen de información que podría ser afectada se incrementa [1]. Este aspecto se vuelve más complejo en un entorno de red, donde el número de equipos de cómputo se incrementa. Con base en los aspectos anteriores, surge esta investigación enfocada a proporcionar una metodología de detección de intrusos de los sistemas de archivos de los equipos de cómputo en un entorno de red, con el fin de identificarlas, determinar una posible intrusión y recaudar evidencia suficiente para sustentar la tomar de decisiones sobre las medidas necesarias para contrarrestar el posible daño realizado.

Objetivos.

Objetivo General.

El objetivo que se plantea esta tesis es desarrollar e implementar una metodología de detección de modificaciones del sistema de archivos Linux, con la capacidad de reconocer intrusiones, tipificarlas y generar un informe. En base a una política de seguridad, determinar la fiabilidad del sistema de archivos de acuerdo a los elementos detectados y el riesgo que representan para el óptimo funcionamiento o integridad de la información almacenada.

Objetivos Específicos.

• Analizar la estructura de directorios del sistema operativo Linux y definir el riesgo de seguridad que representa la modificación de cada uno de ellos.

• Diseñar una metodología que permita obtener las propiedades significativas de los archivos del sistema operativo y validar la integridad de la información contenida en cada uno de ellos.

• Crear un sistema de directorios en un elemento central dentro de una red, el cual permita almacenar la información de identificación de los archivos obtenida previamente de cada equipo de cómputo.

• Diseñar e implementar una base de datos que permita almacenar los datos de las modificaciones detectadas.

• Implementar una herramienta informática que permita el análisis, almacenamiento, determinación de las probables intrusiones, generación de reportes de elementos detectados y actualización del estado de cada equipo.

• Implementar un entorno de red que permita realizar pruebas de reconocimiento y detección de intrusiones.

• Analizar el uso de recursos de hardware necesarios para el análisis de detección de modificaciones implementado.

Introducción.

XI

Justificación.

La seguridad de los sistemas informáticos es uno de los principales problemas con los que podemos encontrarnos hoy en día. Resulta de vital importancia la conservación, almacenamiento e integridad de la información en formato electrónico, ya que esta ha pasado de ser un elemento abstracto de baja importancia, a ser considerada incluso como un activo dentro del capital de las empresas [5]. La tarea de análisis de un equipo de computo requiere de herramientas de procesamiento electrónico de información y conocimiento de las amenazas informáticas, debido a que el proceso de instalación, configuración y revisión de múltiples sistemas resulta tedioso, en ocasiones, es imposible de realizar por una sola persona dedicada a la seguridad informática, por lo cual se automatizan algunas de estas tareas, con lo que se consigue reducir notablemente el tiempo de respuesta ante incidentes informáticos. Algunos factores como el aumento de las amenazas informáticas, la necesidad de conectarse a redes de dispositivos a gran escala como internet y un bajo cumplimiento de las políticas de seguridad, incrementan el riesgo de ser víctimas de un ataque informático. Para enfrentar estas amenazas, existen herramientas para hacer de un sistema Linux un elemento confiable para el procesamiento de la información, la mayoría de ellas de uso libre en versiones básicas, algunas otras con costo para versiones de tipo empresarial, pero en general, son herramientas independientes y la instalación es opcional a la distribución del sistema operativo [6]. Un elemento de seguridad en los sistemas Linux es el sistema de bitácoras, el cual consiste en llevar un registro de casi todos los procedimientos, recursos, usuarios y errores que se generan durante el uso del equipo de cómputo. Este elemento es flexible, debido a que permite almacenar información dependiendo de reglas configurables, pero, no existe una metodología para revisar esta información y determinar elementos que comprometan la integridad del sistema. Por lo tanto se tiene un volumen de información muy grande, sin clasificar y casi imposible de revisar minuciosamente por parte del administrador del sistema [6]. La revisión de la integridad de la información almacenada toma relevancia debido a la probabilidad de las modificaciones que pudieran presentarse sin autorización, estas modificaciones sobre la información sensible del sistema podrían comprometer su funcionamiento. Otro elemento consiste en la revisión de las llamadas al sistema, el cual permite una restricción sobre el tipo de contenido que se ejecuta dentro de un entorno Linux, esta técnica requiere para su correcta aplicación una base de comportamiento de cada uno de los ejecutables del sistema y la verificación de este, se aplica en tiempo real por lo que se puede bloquear contenido no deseado [6]. Los elementos de seguridad descritos anteriormente permiten detectar intrusiones, en un escenario ideal, un sistema de detección necesita reconocer las variaciones en la estructura de los sistemas de archivos, programas, procesos o permisos de ejecución en cuanto ocurren, es decir en tiempo de ejecución; pero esto, exige

Introducción.

XII

demasiados recursos al sistema y merman su rendimiento. Otra opción disponible consiste en analizar un proceso o acción cuando ha finalizado su ejecución y se han registrado los cambios, con el objetivo de saber que objeto fue ejecutado o modificado, bajo que privilegios y por cuanto tiempo [7]. Las herramientas de detección pueden pertenecer al sistema operativo o instalarse de manera opcional y permiten la reducción del tiempo de respuesta ante un incidente informático [6]. Beneficios Esperados. Con el desarrollo de este trabajo de investigación, se pretende contar con una metodología para generar un directorio de referencia consistente en las aplicaciones, llamadas al sistema y algunos utilitarios del sistema operativo Linux. Esta metodología será implementada en un entorno de red, lo que permitirá la ejecución de un banco de pruebas específicas, que sirva como referencia para determinar su confiabilidad y el desempeño de esta en ambientes de trabajo reales. La herramienta a desarrollar cumplirá con los siguientes aspectos: 1. Proporcionar confiabilidad y validación del software instalado por el administrador del sistema, utilizando técnicas de criptografía y una base de datos en un medio de almacenamiento seguro. 2. Reducir la ejecución de código no autorizado o modificado por parte de los usuarios del sistema, restringiendo las aplicaciones que les son permitidas dependiendo de su actividad específica. 3. Implementar la metodología presentada para obtener reportes de los análisis realizados a los equipos de cómputo y obtener reportes fáciles de entender en el menor tiempo posible. 4. Con lo anterior se pretende reducir el tiempo de detección de cambios de la estructura de directorios del sistema operativo, proporcionando al administrador un informe oportuno del estado del equipo.

Alcances. La herramienta de seguridad generada en este trabajo permitirá analizar cotidianamente las modificaciones de programas que trabajan con el sistema operativo Linux; tomando como base el reporte emitido, el administrador determinara las estrategias a seguir después de que el sistema de archivos muestre alguna modificación. Los análisis de los equipos se efectuarán en intervalos de tiempo bien definidos y sin la intervención o supervisión del administrador del sistema, la conexión, análisis y almacenamiento de los cambios será trabajo directo de la aplicación. El sistema de detección de intrusiones permitirá el análisis de varios equipos de cómputo dentro de un entorno de red, considerando un esquema cliente - servidor para la implementación.

Introducción.

XIII

Límites. La capacidad de análisis y de almacenamiento de información depende del número de clientes analizados, de las prestaciones de hardware y de la tecnología de red utilizada para la transferencia de datos. Esta herramienta constituye una opción dentro de las herramientas de protección de los sistemas informáticos, no existe una a solución integral o única, deben utilizarse conjuntamente un grupo de elementos de protección y prevención para obtener un sistema informático fiable; los elementos mas utilizados son los firewalls, analizadores de red y monitores de recursos [1]. Además, al ser una herramienta pasiva, es necesaria la intervención humana para las tareas de configuración, diseño de políticas de seguridad y la determinación de procedimientos o estrategias a seguir cuando reporta una posible intrusión o modificaciones del sistema de archivos.

Organización de la Tesis.

La información documental de este trabajo se encuentra organizada de la siguiente manera:

� Capítulo 1. Estado del arte de los sistemas actuales de identificación de intrusos y las técnicas que implementan.

� Capítulo 2. Proporciona los conceptos básicos de seguridad informática, las

amenazas existentes y los fundamentos sobre el funcionamiento de la herramienta de detección de intrusos.

� Capítulo 3. Se muestra el modelo de los subsistemas planteados para cumplir los

objetivos y los cuales se utilizarán para la generación de la metodología de detección de modificaciones del sistema de archivos, así mismo, se describe la arquitectura de los procedimientos de análisis del sistema, los métodos de autenticación, las técnicas de certificación y la codificación electrónica.

� Capítulo 4. Se resumen los pasos necesarios para la implementación de la

herramienta de seguridad propuesta y los recursos utilizados para cumplir este propósito. También se describe la generación de la base de datos y los esquemas de seguridad utilizados en el desarrollo del sistema informático.

� Capítulo 5. Se describen las pruebas realizadas a la herramienta desarrollada y los

resultados obtenidos, los criterios considerados para la evaluación de la herramienta en cuestiones de fiabilidad, recursos de carga en el cliente, entre otros aspectos.

� Capítulo 6. Se analizan los objetivos frente a los logros obtenidos, se establecen

recomendaciones y se proponen trabajos futuros.

Capitulo 1. Estado del arte.

1

CAPITULO 1. ESTADO DEL ARTE. Este capítulo presenta el estado actual de los sistemas de detección de intrusiones existentes, los desarrollos que se han realizado en materia de seguridad informática y las técnicas utilizadas para la detección de anomalías.

A finales de la década de los noventas, muy poca gente tomaba en serio el tema de la seguridad de las computadoras; por una parte, la red de intercomunicación mas grande del mundo llamada Internet, iba creciendo exponencialmente, redes importantes se adherían a ella cada día; por otro lado, el desarrollo tecnológico disminuyo el precio de los sistemas informáticos y puso al alcance de miles de usuarios la adquisición de equipos de cómputo. En 1988, se protagonizo el primer gran incidente de la seguridad informática, un programa desarrollado por Robert Tappan Moris se convirtió en el gusano de Internet, miles de equipos de cómputo conectados a la red se vieron inutilizados durante días, se calcula que el costo de la reparación por el daño causado por el gusano fue de entre 200 y hasta 53,000 dólares en cada equipo infectado [6]. Desde ese momento, el tema de la seguridad en sistemas operativos y redes ha sido un factor vital para los administradores de sistemas informáticos. Poco después de este incidente, la agencia DARPA (Defense Advanced Research Projects Agency) creó el CERT (Computer Emergency Response Team), un grupo formado en su mayor parte por voluntarios calificados de la comunidad informática, cuyo objetivo principal es facilitar una respuesta rápida a los problemas de seguridad que afectan a los equipos de computo. Con esta referencia y a casi 20 años de distancia, podemos hacer un análisis similar, tomando ahora como elemento fundamental el crecimiento de los usuarios con sistemas operativos sobre plataforma Linux y su acceso a Internet. El número de usuarios que utilizan el sistema operativo Linux ha crecido de manera sorprendente [3], no solo son usuarios que realizan aplicaciones de trabajos escolares o pequeños desarrollos de software. En la actualidad, se tienen servidores de correo, páginas web, bases de datos, entre muchas otras aplicaciones; hay empresas muy grandes utilizando esta plataforma, incluso, algunos países como Brasil, Venezuela, Ecuador, India, Sudáfrica, China y Corea del Sur han decidido hacer oficial el uso de software de código abierto en sus dependencias gubernamentales[3]. Por otro lado, el acceso a la red mas grande del mundo se ha vuelto algo casi indispensable; la convergencia de tecnologías de comunicación le ha permitido un desarrollo vertiginoso, hoy se puede acceder a internet desde muchas partes, utilizando diferentes tipos de conexión (alambrica, inalámbrica) y una variada cantidad de dispositivos (teléfonos móviles, PALM, PC). Esto implica, que el número de usuarios conectados e intercambiando información sea extremadamente grande, pero por desgracia, varios de ellos no tienen las mejores intensiones y en algún momento pretenderán obtener beneficios de una manera no adecuada, podrían ganar acceso a información o algún otro recurso que no le pertenezca, incluso hacer un mal uso de ellos o destruirlos. Por estas razones, debemos hacer hincapié en la necesidad de contar con sistemas que procesen, almacenen e intercambien nuestra información de manera fiable, comenzaremos a describir los términos de la seguridad informática, los riesgos que existen, los métodos para proveer de fiabilidad al sistema operativo, los avances en materia de prevención y las soluciones disponibles para hacer frente a esta problemática.

Capitulo 1. Estado del arte.

2

Dentro de este trabajo de investigación nos enfocaremos a los equipos de cómputo y los elementos que permiten brindarle seguridad. Uno de los aspectos fundamentales es el sistema operativo, la seguridad en este punto se implementa haciendo uso de mecanismos propios de su diseño como son: protección de la memoria, control de acceso a los archivos, protección de los recursos del sistema, entre otros. Estos elementos no son suficientes y requieren el complemento de otras herramientas de análisis, prevención y manejo de errores. En el mundo existe un gran número de herramientas que permiten realizar análisis completos del sistema operativo Linux, algunos realizan auditorías y otros permiten establecer mecanismos de seguridad, con el fin de evitar que los ataques se repitan; estas herramientas han evolucionado de la misma forma en que lo ha hecho el sistema operativo, algunas han sido incluidas como módulos de una distribución, otras, han incrementado su funcionalidad desde su aparición hasta llegar a ser de tipo empresarial [1]. Entre estas herramientas de seguridad destacan los sistemas de detección de intrusiones (IDS), los cuales son elementos de software o hardware que automatizan el proceso de monitorear los eventos que ocurren en equipos de cómputo o red, analizándolos en busca de signos de problemas de seguridad. Las herramientas de detección de intrusos basadas en host permiten incrementar la seguridad en los sistemas informáticos, mediante el análisis de anomalías o de uso indebido del equipo; la información proporcionada por estos elementos, permite determinar las características de las violaciones, las técnicas necesarias para solucionar el problema específico y generación de reportes de eventos [7].

1.1 Historia de los sistemas de auditoria y detección de intrusos. La seguridad en los sistemas de información se remonta a los primeros elementos de comunicación existentes en la década de los 50s, la empresa Bell Telephone System, de Estados Unidos, estableció la necesidad de utilizar auditorías mediante el Procesamiento Electrónico de Datos (EDP), rompiendo con el anterior sistema basado en los tradicionales informes de papel. Posteriormente, el Departamento de Defensa empleó numerosos recursos en los años 70 para la investigación de políticas de seguridad, directrices y pautas de control de lo que denominaban sistemas de confianza. Estos esfuerzos culminaron con la Iniciativa de Seguridad de 1977 [2]. Los Sistemas de Confianza son aquellos sistemas que emplean los suficientes recursos de hardware y software para permitir el procesamiento simultáneo de una variedad de información confidencial o clasificada, el documento publicado por el Departamento de Defensa trata el tema de las auditorías y los objetivos de un mecanismo de monitoreo [7]. A medida que el número de ordenadores crecía, también lo hacia el número de eventos a analizar al grado de que esta tarea se volvía humanamente imposible. James P. Anderson fue la primera persona en documentar la necesidad de un mecanismo que automatizara la revisión de los eventos de seguridad y describió el concepto de Monitor de Referencias en 1980 [2]. Propuso un sistema de clasificación que distinguía entre ataques internos y externos, basado en si los usuarios tenían permiso de acceso o no al ordenador y debía distinguir entre el comportamiento normal o inusual de las cuentas basándose en patrones de uso, creados a partir del análisis de estadísticas de comportamiento de usuario.

Capitulo 1. Estado del arte.

3

Entre 1984 y 1986 se desarrollo el Sistema Experto de Detección de Intrusos (IDES), un modelo que definía un sistema de detección de intrusiones en tiempo real. Este proyecto proponía una correspondencia entre actividad anómala y el uso indebido, entendiendo por anómala, aquella actividad inusual en un contexto estadístico [4]. Usaba perfiles para describir a los sujetos del sistema (principalmente usuarios), y reglas de actividad para definir las acciones que tenían lugar (eventos de sistema o tiempos de CPU). En la década de los 90s, en la Universidad de California, fue desarrollado el Sistema de Monitoreo de Red (NSM) para trabajar en una estación UNIX de Sun. Fue el primer sistema de detección de intrusiones que monitoreaba el tráfico de red, utilizando los datos del propio tráfico como principal fuente de datos [2]. Los anteriores sistemas utilizaban los eventos de sistema o registraban las pulsaciones de teclado. El funcionamiento del NSM es la base de los sistemas de detección de intrusiones de red hoy en día.

1.2 Estructura de los sistemas de detección de intrusos.

La detección de intrusiones es el fruto de la aplicación del Procesamiento Electrónico de Datos (EDP) a las auditorías de seguridad, utilizando mecanismos de identificación de patrones y métodos estadísticos [4].

1.2.1 Definición de IDS. La detección de intrusiones es el proceso de monitorear los eventos que ocurren en un sistema de computadoras o en una red, y analizarlos en busca de signos de intrusiones, las que se definen como intentos de comprometer la confidencialidad, integridad, disponibilidad, o traspasar los mecanismos de seguridad de una computadora o una red [4]. Las intrusiones son causadas por atacantes que acceden al sistema por Internet, usuarios del sistema que intentan ganar privilegios adicionales para los cuales no están autorizados, y usuarios autorizados que usan indebidamente los privilegios que tienen. Los sistemas de detección de intrusiones, o SDI (también conocidos como IDS, siglas en inglés), son productos de hardware o software que automatizan este proceso de monitoreo y análisis [7].

La detección de intrusos se puede realizar a partir de la caracterización anómala del comportamiento y del uso que hacen de los recursos del sistema. Este tipo de detección pretende cuantificar el comportamiento normal de un usuario. Para una correcta distinción hay que tener en cuenta las tres distintas posibilidades que existen en un ataque:

• Penetración externa: Se define como la intrusión que lleva a cabo un usuario o un sistema de computadores no autorizado desde otra red.

• Penetración interna: Es aquella que lleva a cabo el usuario interno que excede sus permisos de acceso.

• Abuso de recursos: Se define como el abuso que un usuario lleva a cabo sobre unos datos o recursos de un sistema al que está autorizado su acceso.

Capitulo 1. Estado del arte.

4

La idea central de este tipo de detección es el hecho de que la actividad intrusiva es un subconjunto de las actividades anómalas [4]. Sin embargo en la mayoría de las ocasiones una actividad intrusiva resulta del agregado de otras actividades individuales que por sí solas no constituyen un comportamiento intrusivo de ningún tipo; las diferentes intrusiones que puede reconocer un IDS son: 1. Intrusivas pero no anómalas. Se les denomina falsos negativos y en este caso la actividad es intrusiva pero como no es anómala no se consigue detectarla. Se denominan falsos negativos porque el sistema erróneamente indica ausencia de intrusión. 2. No intrusivas pero anómalas. Se denominan falsos positivos y en este caso la actividad es no intrusiva, pero como es anómala el sistema la detecta como intrusiva. Se denominan falsos positivos, porque el sistema erróneamente indica la existencia de intrusión. 3. Ni intrusiva ni anómala. Son negativos verdaderos, la actividad es no intrusiva y se indica como tal. 4. Intrusiva y anómala. Se denominan positivos verdaderos, la actividad es intrusiva y es detectada. El la figura 1.1 se muestra gráficamente las intrusiones que puede reconocer un IDS, considerando si la intrusión esta dentro de lo normal o anómalo y la correspondencia de estos con los ataques o un evento inofensivo.

Figura 1.1. Tipos de intrusiones [4].

Capitulo 1. Estado del arte.

5

1.2.2 Elementos de los sistemas de identificación de intrusos. A continuación se mencionan los principales elementos de un sistema de identificación de intrusos, los cuales difieren de acuerdo a las técnicas implementadas para la realización de cada uno de ellos.

1.2.2.1 Fuentes de Información. Se describen las diferentes fuentes de información de eventos usadas para determinar si una intrusión ha tenido lugar. Estas fuentes pueden provenir de diferentes niveles del sistema, siendo mas comunes las de monitoreo de red, host, y aplicación.

• Basados en Red: La mayoría de los sistemas de detección de intrusiones comerciales son basados en red. Estos IDS detectan ataques capturando y analizando paquetes de red. Escuchando en un segmento de red o un switch, un IDS basado en red puede monitorear el tráfico de red afectando a múltiples hosts que estén conectados al segmento de red, y de esta manera proteger a estos hosts. Los IDS basados en red a menudo consisten de un conjunto de sensores de propósito simple o hosts ubicados en varios puntos de una red. Estas unidades monitorean el tráfico de red, realizando un análisis local del tráfico y reportando ataques a una consola de administración central. Como los sensores están limitados a ejecutar el IDS, pueden ser asegurados más fácilmente contra ataques. Muchos de estos sensores están diseñados para ejecutarse en modo furtivo, para hacer más difícil para un atacante determinar su presencia y ubicación [2].

• Basados en Host: Operan sobre información recolectada de un sistema de cómputo individual. (Los IDS basados en aplicación son un subconjunto de los IDS basados en Host) Este punto de ventaja permite analizar actividades con gran confiabilidad y precisión, determinando exactamente que procesos y usuarios están involucrados en un ataque particular sobre el sistema operativo. Adicionalmente, a diferencia de los IDS basados en red, estos IDS pueden “ver” el resultado de un ataque frustrado, ya que pueden acceder y monitorear directamente los archivos de datos y procesos del sistema usualmente blancos de los ataques. Los IDS basados en host normalmente utilizan dos tipos de fuente de información, los seguimientos de auditoria del sistema operativo, y los logs del sistema. Los seguimientos de auditoria del sistema operativo son usualmente generados en el núcleo del sistema, y por esto son más detallados y mejor protegidos que los logs. Sin embargo, los logs del sistema son mucho menos obtusos y mucho más pequeños que las auditorias, y son además mucho más fáciles de entender. Algunos IDS basados en host están diseñados para soportar una infraestructura de IDS de administración y reportes centralizada que puede permitir una simple consola de administración analizar varios hosts. Otros generan mensajes en formatos que son compatibles con sistemas de administración de red [2][4].

• Basados en aplicación: Los IDS basados en aplicación son un subconjunto especial de los IDS basados en Host que analizan los eventos que ocurren dentro de una aplicación de software. La fuente común de información utilizada por los IDS basados en aplicación son los archivos log de las transacciones de las aplicaciones.

Capitulo 1. Estado del arte.

6

La habilidad para interactuar con la aplicación directamente, con conocimiento especifico de la aplicación, incluido en el motor de análisis, permite a los IDS basados en aplicación detectar comportamiento sospechoso cuando los usuarios autorizados exceden su autorización. Esto es porque tales problemas aparecen más comúnmente en la interacción entre el usuario, los datos, y la aplicación [2].

1.2.2.2 Análisis. La parte de los sistemas de detección de intrusiones que realmente organiza e interpreta los eventos derivados de las fuentes de información, decidiendo cuando esos eventos indican que están ocurriendo intrusiones o que ya han ocurrido. Los tipos más comunes de análisis son detección de uso indebido y detección de anomalías.

• Detección de usos indebidos (misuse): El análisis encuentra algo conocido como malo. Para encontrar usos indebidos se comparan firmas con la información recogida en busca de coincidencias. Es la técnica usada por la mayoría de los sistemas comerciales [2][4][7].

• Detección de anomalías: Busca patrones anormales de actividad. Para la detección de anomalías se manejan técnicas estadísticas que definen de forma aproximada lo que es el comportamiento usual o normal. Hay puntos fuertes y débiles asociados con esta aproximación, y parece ser que los IDS más efectivos usan mayormente métodos de detección de usos indebidos con componentes de detección de anomalías. Utilizan técnicas como: Detección de umbral, medidas estadísticas, medidas basadas en reglas, incluyendo redes neuronales, algoritmos genéticos y modelos de sistemas inmunes [2][4][7][9].

1.2.2.3 Respuesta El conjunto de acciones que el sistema toma una vez este detecta una intrusión. Típicamente son agrupadas en medidas activas y pasivas, donde las activas involucran alguna intervención automatizada por parte del sistema, y las pasivas involucran reportar por parte del IDS a los humanos, sus hallazgos, de quienes se espera tomen alguna acción basados en esos reportes[2][1].

• Respuestas activas: Afectan al progreso del ataque, pueden ser llevadas a cabo de forma automática por el sistema, o mediante intervención humana. Estas acciones pueden ser de diversa naturaleza; no obstante, la mayoría se pueden clasificar en estas tres categorías principales: ejecutar acciones contra el intruso, corregir el entorno y recopilar más información. Se debe tener gran cuidado en cuanto a las acciones a tomar y obtener asesoramiento legal antes de realizar cualquier respuesta al ataque [4][7].

• Respuestas pasivas: Consisten en el envío de información al responsable dejando en él la toma de decisiones. En los primeros detectores de intrusiones, todas las respuestas eran pasivas. Por muy afinados que sean los mecanismos de respuesta automática, hay ocasiones en que un sistema no tiene la responsabilidad suficiente para tomar una decisión. Las alarmas por pantalla son una de las alarmas más comunes entre los sistemas de detección de intrusiones.

Capitulo 1. Estado del arte.

7

Un mensaje en una ventana indica al usuario que se ha cometido una posible intrusión, acompañando a veces el mensaje con información adicional, como la dirección del posible atacante, el protocolo usado, etc. Muchas veces, el contenido de estas alarmas puede ser configurado. Otra de las posibles formas de recibir respuestas pasivas es a través del correo electrónico o mensajes a un teléfono móvil. Algunos sistemas de detección de intrusiones comerciales están integrados con mecanismos de gestión de redes [2][4].

En la Figura 1.2 se muestra la clasificación de los IDS de acuerdo a las fuentes de información, las técnicas de análisis y las estrategias de respuesta que implementan, todas ellas descritas anteriormente

Figura 1.2. Clasificación de los IDS [2].

1.2.2.4 Capacidades de generación de reportes y archivado. Muchos de los IDS comerciales, proveen capacidades para generar reportes y otros documentos de información detallada. Algunos pueden dar reportes de los eventos del sistema e intrusiones detectadas sobre un periodo particular (por ejemplo una semana o un mes). Algunos proveen estadísticas o logs generados por el IDS en formatos apropiados para la inclusión en un sistema de bases de datos [1][7].

1.2.2.5 Estrategia de Control.

Estrategia de control se refiere a como los elementos de un IDS están controlados, y además, como la entrada y la salida del IDS es administrada [1][7].

• Centralizada: Bajo estrategias de control centralizadas, toda la monitorización, detección y los reportes son controlados directamente desde una ubicación central.

Capitulo 1. Estado del arte.

8

• Parcialmente distribuida: La monitorización y la detección son controladas desde un nodo de control local, con reportes jerárquicos a una o más ubicaciones centrales.

• Totalmente distribuida: La monitorización y la detección se hacen usando una aproximación basada en agentes, donde las decisiones de respuesta se toman en el lugar de análisis.

1.2.2.6 Tiempo de análisis.

Es el tiempo que pasa entre los eventos que son monitorizados y el momento que se realiza el análisis de dichos eventos.

• Basado en Intervalos (Modo Batch): El flujo de información desde los puntos de monitorización a los motores de análisis no es continuo; la información es manejada de una manera similar a los esquemas de comunicación “almacenamiento y envío”. Muchos de los primeros IDS basados en host usaban este esquema de tiempo, ya que confiaban en los registros de auditoria del sistema operativo, los cuales eran generados como archivos. Los IDS basados en intervalos no pueden desempeñar respuestas activas [2].

• Tiempo real (Continuos): Operan con alimentación de información continua desde las fuentes de información. Este es el esquema de tiempo predominante para los IDS basados en red, los cuales consumen información desde los flujos de tráfico de red. El término tiempo real es usado en el control de procesos. Esto significa que la detección desempeñada por un IDS de tiempo real produce resultados lo suficientemente rápido como para permitir al IDS tomar acciones que afecten el progreso del ataque detectado [2].

1.2.2 Métodos de detección de anomalías. Los detectores de anomalías identifican comportamiento inusual o anormal (anomalías) en un host o una red. Funcionan sobre la suposición de que los ataques son diferentes de la actividad normal (legítima) y pueden por lo tanto ser detectados por sistemas que identifican estas diferencias. Los detectores de anomalías construyen perfiles representando el comportamiento normal de los usuarios, hosts, o conexiones de red. Estos perfiles son construidos de datos históricos recolectados sobre un período normal de operación. Posteriormente, los detectores recogen datos de eventos y usan una variedad de medidas para determinar cuando las actividades monitoreadas se desvían de lo normal. Las medidas y técnicas usadas en la detección de anomalías incluyen:

• Detección de umbral [4]. Este sistema es conocido también como detección de umbral y disparador (threshold and trigger). En este caso, se cuenta el número de veces que ocurren los elementos que forman los perfiles de cada usuario, y se comparan estos datos con valores de umbral (algún nivel establecido como permisible).

Capitulo 1. Estado del arte.

9

• Medidas estadísticas [4]. Los sistemas estadísticos pueden ser de tipo paramétrico o no paramétrico. Los primeros son aquellos cuyas distribuciones son conocidas de antemano, para encajar en un patrón particular. Por ejemplo, en las primeras versiones de IDES, la distribución utilizada era la Gaussiana o normal. La mayoría de las primeras soluciones basadas en medidas estadísticas utilizaban aproximaciones de tipo paramétrico. Los enfoques estadísticos no paramétricos, por tanto, trabajan con perfiles de comportamiento que no se basan en distribuciones preestablecidas, en cambio son “aprendidas” de un conjunto de valores históricos, observados sobre el tiempo.

• Medidas basadas en reglas [4]. Son similares a las medidas estadísticas no paramétricas, en que los datos observados definen el uso de patrones aceptable, pero difiere en que esos patrones son especificados como reglas, no como cantidades numéricas.

Otras medidas utilizadas para este propósito son las redes neuronales, algoritmos genéticos y modelos de sistemas inmunes, solo las dos primeras métricas son usadas en los IDS actuales. Desafortunadamente, los detectores de anomalías y los IDS basados en ellos producen frecuentemente un gran número de falsas alarmas, ya que los patrones normales de comportamiento de usuario y sistema pueden variar ampliamente. A pesar de este defecto, la detección de anomalías se hace valida porque son capaces de detectar nuevas formas de ataques, a diferencia de los IDS basados en firmas que dependen de encontrar patrones de ataques pasados.

1.2.2.1 Métodos detección de anomalías alternativas. Aparte de los métodos de detección antes mencionados, han ido apareciendo nuevas soluciones, aplicables a la detección de usos indebidos o a la detección de anomalías, las posibilidades en el campo de la detección son enormes. Cualquier sistema relacionado con técnicas de aprendizaje, reducción de datos, o toma de decisiones se puede aplicar de algún modo a la detección de intrusiones. Estas técnicas son utilizadas en conjunción con otras más tradicionales, para refinar los procesos de detección.

• Sistema inmune: Consiste en aprovechar las similitudes existentes entre el sistema inmune del organismo y la detección de intrusiones, basadas en la identificación de lo que es propio al sistema y lo ajeno al mismo. El sistema es capaz de reconocer comportamientos extraños al organismo (antígenos). Los antígenos, en el contexto de un sistema computacional con usuarios y comportamientos individuales; estas técnicas no deberían utilizarse de forma única, sin el apoyo de algún otro mecanismo de detección complementario. Algunos ataques, tales como los de condición de carrera, enmascaramiento, o violaciones de políticas de sistema no hacen uso de procesos privilegiados, por lo que no son detectados por este enfoque [2].

• Genética: Los algoritmos genéticos también son de gran utilidad en la detección de intrusiones, son un método de análisis de datos avanzado, un algoritmo genético es una búsqueda basada en la mecánica de la selección natural y de la genética natural. Combina la supervivencia del más apto entre estructuras de secuencias con un intercambio de información estructurado, aunque aleatorio, para constituir así un algoritmo de búsqueda que tenga algo

Capitulo 1. Estado del arte.

10

de las genialidades de las búsquedas humanas. Cada solución será representada a través de una cadena de 0s y de 1s o cromosomas que se verán entonces sometidos a una imitación de la evolución de las especies: mutaciones y reproducción por combinación. Como se favorece la supervivencia de los más "aptos" (las soluciones más correctas), se provoca la aparición de híbridos cada vez mejores que sus padres. Al despejar los elementos más aptos, se garantiza que las generaciones sucesivas estarán cada vez más adaptadas a la resolución del problema. Para utilizar algoritmos genéticos en la detección de intrusiones, los desarrolladores han definido vectores de hipótesis para los datos de eventos, donde los vectores pueden indicar si ha habido una intrusión o no. Entonces, la hipótesis se somete a prueba para determinar si es válida. Con los resultados de la prueba, se desarrolla una versión mejorada (evolucionada) de la hipótesis. Este proceso se repite hasta encontrar una solución [2].

• Minería de datos (Data mining): Según apuntan algunos, la minería de datos es el sucesor de la estadística clásica. Ambos llevan al mismo fin, el cual es construir modelos compactos y comprensibles que relacionen la descripción de una simulación y un resultado relacionado con dicha descripción. Su diferencia reside en que las técnicas de minería de datos construyen su modelo de forma automática, mientras que las técnicas estadísticas clásicas deben ser manejadas por un profesional. La detección de intrusiones que utiliza técnicas de minería de datos es similar a la basada en reglas. Intenta descubrir patrones fiables de características de sistema que puedan definir pautas de comportamiento de sistema y usuario. Estos conjuntos de características de sistema son procesados mediante métodos de inducción por motores de detección que identifican tanto anomalías como usos indebidos. La minería de datos extrae modelos a partir de grandes cantidades de información. Tiene la peculiaridad de encontrar relaciones ente los datos que serían más difíciles de detectar mediante otros métodos de análisis. Entre los algoritmos disponibles para aplicar la minería de datos sobre datos de auditoría predominan tres: clasificación, análisis de enlace, y análisis de secuencia. Clasificación: Asigna los datos a una serie de categorías predefinidas. Los algoritmos de clasificación determinan clasificadores, tales como árboles de decisión o reglas. En la detección de intrusiones, los clasificadores deciden si los datos de auditoría pertenecen a una categoría normal o anómala. Análisis de enlace: Identifica las relaciones y correlaciones entre los campos en el cuerpo de los datos. Un algoritmo de análisis de enlace óptimo reconoce el conjunto de características de sistema más adecuado para revelar intrusiones. Análisis de secuencia: Crea patrones de secuencias. Estos algoritmos pueden identificar aquellos eventos que suelen ocurrir juntos, y proporcionar medidas estadísticas de tiempo para mejorar la detección de intrusiones. Estas medidas ayudan en la detección de ataques basados en denegación de servicio. Una de las ventajas de la minería de datos es que mejoran el rendimiento, la manejabilidad y reducen el tiempo de trabajo, además de su rapidez, también son considerados por su sencillez. Estas técnicas permiten trabajar con importantes cantidades de información sin problemas [2][4].

Capitulo 1. Estado del arte.

11

• Detección basada en agentes: Los agentes son aplicaciones de software que realizan funciones de monitorización en máquinas. Funcionan de forma autónoma, es decir, son sólo controlados por el sistema operativo, no por otros procesos. Los agentes están siempre en funcionamiento, siendo posible la comunicación y cooperación entre ellos si es necesario. El grado de complejidad de los agentes es variable. Pueden realizar tareas sencillas como registrar el número de ocasiones en que un usuario entra al sistema, o más complejas como la búsqueda de evidencias de ciertos ataques, de acuerdo con determinados parámetros. Además, tienen la capacidad de responder de forma muy precisa ante posibles intrusiones, por ejemplo, modificando prioridades de procesos y de acuerdo a sus características, los agentes se pueden utilizar tanto en detección de anomalías como de usos indebidos. Como estos agentes se pueden comunicar entre sí, pueden realizar de forma individual tareas simples, de forma que la tarea conjunta sea más compleja, sin embargo, este sistema también tiene sus desventajas, si un monitor falla, los datos enviados por los transmisores-receptores conectados a él, dejarán de llegar[2][4][7].

• Sistemas trampa (Honeypot): En vez de repeler las acciones de los atacantes, utilizan técnicas para monitorizarlas y registrarlas, para así aprender de ellos, un honeypot no es un sistema de detección de intrusiones, pero puede ayudar a mejorar sus métodos de detección y aportar nuevos patrones de ataque. Esta diseñado para engañar a los intrusos, poder estudiar sus actividades, y así aprender de sus métodos. Se basa en la idea de conocer al enemigo para poder combatirlo, los sistemas están diseñados para imitar el comportamiento de aquellos sistemas que puedan ser de interés para un intruso, comúnmente, poseen mecanismos de protección para que un atacante con éxito no pueda acceder a la totalidad de la red [2][4].

• Verificador de integridad de archivos: Un verificador de integridad de ficheros es una herramienta utilizada por sistemas de detección de intrusiones, normalmente los basados en máquina, para mejorar sus capacidades. Aplican funciones resumen, u otros métodos de cifrado robustos, a ficheros críticos de sistema, comparando los resultados con una base de datos de referencia, y comunicando los posibles cambios o diferencias.

Hay varias razones por las que utilizar este tipo de herramientas para detectar intrusiones. Un atacante puede alterar o eliminar ficheros para no dejar evidencias de su actividad. Además, puede querer instalar algún troyano que le permita obtener el control de la máquina. O incluso puede dejar una puerta trasera que le deje volver a entrar en el sistema. Los verificadores de integridad de ficheros no sólo pueden servir para detectar intrusiones a través de los cambios encontrados en ficheros. También son de gran ayuda durante un análisis forense, facilitando la identificación del ataque o método utilizado [8]. Además, ayudan a devolver a la normalidad un sistema, optimizando el proceso de restauración [2][4][7].

En la Figura 1.3 se presentan las estrategias de análisis de detección de anomalías y usos indebidos, además de la clasificación de las técnicas implementadas, esto representa el estado actual de los sistemas de identificación de intrusos.

Capitulo 1. Estado del arte.

12

Figura 1.3. Estado de arte de los IDS.

1.3. Situación actual de los sistemas IDS. A pesar de todos los avances realizados, estos sistemas no tienen el nivel de madurez deseado. La mayoría comparte una serie de aspectos pendientes de ser mejorados; sus principales puntos débiles y necesidades podrían ser descritos en los siguientes aspectos: Falsos positivos. Son aquellas alarmas que emite el detector cuando identifica erróneamente un ataque o intrusión. El problema llega cuando el número de este tipo de alarmas es inaceptablemente alto. Este inconveniente se agrava con los falsos negativos, en los que el detector no reconoce un ataque cuando ha ocurrido [2]. Heurística. Este tipo de detectores contiene una base de datos con patrones de ataques que comparan con la actividad que analizan. Un ataque conocido, modificado ligeramente, puede ser totalmente indetectable por un detector de este tipo. La adopción de técnicas heurísticas, tal como han hecho los fabricantes de antivirus, es sólo una de las medidas que utilizarán los IDS en el futuro para corregir esta situación [2]. Estandarización. Los productos de detección de intrusiones actuales no utilizan ningún estándar en diversos aspectos de su metodología. La adopción de estándares no sólo solucionaría problemas de compatibilidad y entendimiento entre los productos existentes; sino que permitiría a las empresas que se dedican al desarrollo de estos productos afrontar de forma conjunta un problema común [2]. Algunos de los aspectos en los que sería aplicable un estándar son: un protocolo de comunicación, un lenguaje genérico para la detección de alarmas, o una definición de un conjunto de reglas para personalizar el motor de detección. Hay algunos organismos que han dedicado importantes esfuerzos en el ámbito de la

Capitulo 1. Estado del arte.

13

estandarización y normalización de los IDSs, pero muchos de los fabricantes de detectores de intrusiones prefieren patentar sus propias soluciones antes que adoptar un estándar [7]. Encriptación. Compartir el mismo medio físico para establecer diferentes comunicaciones obliga a utilizar algún tipo de algoritmo de cifrado para proteger la información [9]. Aunque la encriptación en las comunicaciones es un obstáculo para el trabajo de los IDS de red, ya que el cifrado anula las capacidades de interpretación de los datos, hay formas de solventarlo. Una de las más recurridas consiste en la implantación de agentes en las máquinas que participan en la comunicación [7]. Será imprescindible el uso de técnicas de encriptación para establecer enlaces seguros entre los elementos de un IDS, como por ejemplo, entre los sensores y el sistema central. Protocolos. En el caso de IPv6 esto es especialmente sensible, ya que sus características le permiten construir túneles sobre redes IPv4. Es muy probable que los fabricantes de detectores de intrusiones tengan en cuenta esta característica en sus futuros productos [2][7]. Sobrecarga de alarmas. Cuando se despliega un IDS en una gran corporación puede llegar a generar miles de alarmas al día. Gestionarlas puede convertirse en una labor imposible si no se disponen de los medios adecuados. Aunque hay algunas soluciones, este aspecto aún necesita mejorarse [2]. Recursos. Con el aumento del tráfico de red también crecen las necesidades de recursos de sistema por parte de los detectores. Una de las soluciones que se están empezando a aplicar consiste en la fabricación de soluciones específicas basadas en hardware, que alivien en cierto modo la carga de proceso a la que están sometidos los sistemas de detección [2][7]. Aún no existe una exigencia formal sobre la formulación y aplicación de estándares en la industria de la detección de intrusiones, esto dependerá de las decisiones tomadas por las organizaciones responsables de los productos más importantes. Las nuevas tecnologías se desarrollan a un ritmo vertiginoso, y los retos de seguridad deben atenderse a la misma velocidad. Los detectores de uso indebido pueden reconocer ataques conocidos, siendo posible la actualización de sus bases de ataques periódicamente de forma similar a como ya se hace con los antivirus y los detectores de anomalías[4], son una de las herramientas de seguridad más prometedoras, pudiendo detectar ataques no conocidos, valiéndose de gran variedad de métodos de análisis; es vital considerar a los IDS son una herramienta sumamente importante dentro de los mecanismos de seguridad, pero no son la solución definitiva. Están principalmente diseñados para reducir la carga de trabajo de los administradores de seguridad, realizando diversos análisis sobre los datos disponibles en el sistema, también, ayudan a fortalecer la seguridad de los sistemas, y combinados con otras herramientas brindan un alto grado de protección[10].

1.4 Herramientas de detección de intrusos en Linux. En la actualidad existe un número muy grande de herramientas de detección de intrusos, algunas de las cuales son desarrolladas por los mismos administradores de los equipos en algún lenguaje de programación como Perl, o lenguaje C. Por otro lado, tenemos paquetes propios de cada distribución, que permiten hacer las tareas de

Capitulo 1. Estado del arte.

14

monitoreo o supervisión del sistema, de las cuales podemos destacar las mas utilizadas para la detección de intrusos o la integridad de los archivos en los sistemas operativos Linux.

1.4.1Snort [11]. Creada por Marty Roesh, Snort es uno sistemas de detección de intrusiones de red mas populares, basa su funcionamiento en reglas y soporta algunas funciones de detección de anomalías; es una herramienta de software libre capaz de realizar análisis de tráfico en tiempo real, así como registrar paquetes en redes; Este sistema tiene la ventaja de funcionar bajo gran variedad de plataformas. Puede realizar análisis de protocolos, búsqueda y comparación de contenidos, puede detectar gran variedad de ataques y sondeos, tales como desbordamientos de buffer, escaneo sigiloso de puertos, ataques CGI, intentos de identificación de sistema operativo, etc. También, puede utilizarse como un rastreador de paquetes (sniffer), como registrador de paquetes, y como detector de intrusiones de red; proporciona una interfaz de usuario de fácil manejo y emite reportes de los análisis realizados, además de que está escrito en código fuente abierto, el cual se puede obtener en su sitio oficial.

1.4.2 Tripwire [12]. La herramienta Tripwire es un comprobador de integridad para archivos y directorios de sistemas Unix: compara un conjunto de estos objetos con la información sobre los mismos, almacenada previamente en una base de datos, y alerta al administrador en caso de que haya cambiado algo. La idea es simple: se crea un resumen de cada archivo o directorio importante al instalar el sistema, y esos resúmenes se almacenan en un medio seguro, de forma que si alguno de los archivos es modificado (por ejemplo, por un atacante que sustituye un programa por una versión troyanizada o añade una entrada al archivo de contraseñas) Tripwire envía una alerta la próxima vez que se realice la comprobación. Para generar esos resúmenes se utilizan funciones hash, de forma que es casi imposible que dos archivos generen el mismo resumen; concretamente Tripwire implementa md2, md4, md5, CRC-16 y CRC-32. Fue diseñado por el Dr. Eugene Spafford en 1992, para 1997 fundó Tripwire Inc. que trajo consigo un producto de perfil empresarial denominado Tripwire para servidores. En el año 2000 esta herramienta se convirtió en un producto con capacidad multiplataforma, y se separo el proyecto Tripwire Open Source Linux Edition para los sistemas de código abierto utilizando la Licencia Pública General de GNU. Las diferencias de esta herramienta en sus versiones empresariales y Open Source GNU, consisten en que la primera posee una mejor presentación de informes, una más amplia plataforma de apoyo, y, con el componente opcional Tripwire Manager, la centralización de la presentación de informes además de una interfaz gráfica de usuario. Las principales características de Tripwire Enterprise incluyen una fácil configuración de las políticas de evaluación, la detección de los cambios en tiempo real, administración centralizada en una consola con interfaz gráfica de usuario web, una base de datos centralizada que almacena los cambios históricos, la GUI es fácil de usar y también, la integración con los sistemas de gestión de cambios, que permite cambios automatizados de acuerdo a perfiles y permisos. Esta herramienta tiene un

Capitulo 1. Estado del arte.

15

costo que varía de acuerdo al número de equipos supervisados y cuenta con soporte de servicio y configuración. Por su parte, Tripwire Open Source se encuentra en la versión 2.4.0, la cual contiene una mejora de la funcionalidad de las secuencias de comandos para compilar en una gama más amplia de sistemas operativos de tipo POSIX (Linux / BSD / UNIX). Está disponible en los repositorios de las distribuciones Debian, Ubuntu, RedHat y SuSe, que son de las más utilizadas.

La metodología que implementa se resume en el diagrama de flujo que se muestra en la Figura 1.4. la forma de detección es aplicable a un solo equipo y realizando análisis con la aplicación instalada en el mismo.

Figura 1.4. Diagrama de flujo de Tripwire[12].

Los reportes generados por esta herramienta en su versión Open Source son desde una terminal de comandos, en la Figura 1.5 se muestran las imágenes del resumen del análisis, en la versión empresarial donde destaca la generación de los gráficos y la interfaz web para desplegar el contenido de los datos desde algo general hasta la presentación de detalles de cambios detectados (ver Figura 1.6).

Capitulo 1. Estado del arte.

16

Figura 1.5. Generación de reportes de Tripwire[12].

Figura 1.6. Reportes de Tripwire Enterprise[12].

1.4.3 Inotify [13]. Esta es una herramienta de auditoria del sistema de archivos Linux, es un subsistema del kernel de Linux que ofrece la posibilidad de monitorear ciertos archivos o directorios para recibir notificaciones de eventos en los mismos. Viene por defecto en las distribuciones que tienen un kernel 2.6.13 o superior. Esencialmente, monitorea sobre los i-nodos de cada archivo; cuando el núcleo realiza alguna acción como copiar, borrar, mover, entre otras, lo hace mediante llamadas al sistema; todas estas llamadas son capturadas por el modulo de Inotify, el cual realiza un seguimiento a los i-nodos que esta acción afecta. Esto supone un monitoreo del sistema de archivos en tiempo real. Desafortunadamente, en los sistemas Linux, puedes borrar enlaces a i-nodos para borrar un archivo, debido a que algunos existen solo como vínculos hacia los archivos que físicamente están almacenados en otra dirección, o puedes hacer que apunte a otro i-nodo, pero el i-nodo antiguo seguirá ahí y puedes seguir escribiéndolo o leyéndolo, esta es una razón por la cual en Linux es posible sobrescribir un archivo mientras está abierto, que es lo que pasa cuando se actualizan los paquetes. Esto significa una gran desventaja para el sistema cuando detecta cambios en la eliminación de archivos con enlaces.

Capítulo 2. Marco teórico.

17

CAPÍTULO 2. MARCO TEÓRICO. Este capítulo sirve como sustento a la investigación de la tesis, presenta los conceptos de seguridad de los sistemas informático, los riesgos y amenazas actuales. Se describen las características del sistema operativo Linux y su esquema de seguridad.

2.1 La seguridad informática. La seguridad es una característica de cualquier sistema, la cual nos indica que el sistema está libre de todo peligro, daño o riesgo. Para el caso de sistemas operativos o redes de computadores, la seguridad es muy difícil de conseguir y se adopta el término de fiabilidad, el cual expresa probabilidad de que un sistema se comporte tal y como se espera [6]. Se entiende que mantener un sistema fiable, consiste básicamente en garantizar tres aspectos: confidencialidad, integridad y disponibilidad. La confidencialidad nos dice que los objetos de un sistema han de ser accedidos únicamente por elementos autorizados a ello, y que esos elementos autorizados no van a convertir esa información en disponible para otras entidades. La integridad significa que los objetos solo pueden ser modificados por elementos autorizados, y de una manera controlada. La disponibilidad indica que los objetos del sistema tienen que permanecer accesibles a elementos autorizados, es lo contrario de la negación de servicio [14]. Generalmente tienen que existir los tres aspectos descritos para que haya seguridad; un sistema Linux puede proporcionarlos, pero, dependiendo del entorno en que un sistema trabaje, corresponderá a sus responsables dar prioridad a un cierto aspecto de la seguridad y determinar los criterios para que estos aspectos se cumplan.

2.1.1 Elementos a proteger. Los tres elementos principales a proteger en cualquier sistema informático son el software, el hardware y los datos. Por hardware entendemos el conjunto formado por todos los elementos físicos de un sistema informático, como las CPUs, las terminales, el cableado, los medios de almacenamiento secundario o tarjetas de red. Por software, podemos entender el conjunto de programas lógicos que hacen funcional al hardware, tanto sistemas operativos como aplicaciones, y por datos, el conjunto de información lógica que manejan el software y el hardware, por ejemplo paquetes que circulan por un cable de red o entradas de una base de datos. Habitualmente los datos constituyen el principal elemento de los tres a proteger, ya que es el más amenazado y seguramente el más difícil de recuperar. La pérdida de una aplicación puede entenderse como un programa de sistema, o el propio núcleo de Linux. Este software se puede restaurar sin problemas desde su medio original (por ejemplo, el CD-ROM con el sistema operativo que se utilizó para su instalación). Sin embargo, en caso de pérdida de una base de datos o de un proyecto de un usuario, no tenemos un medio base desde el que restaurar; se debe contar con el uso de un sistema de copias de seguridad, a menos que la política de copias sea muy estricta, es difícil restaurar los datos al estado en que se encontraban antes de la pérdida [14] [15].

Capítulo 2. Marco teórico.

18

Los tres elementos descritos anteriormente, están expuestos a diferentes amenazas, la taxonomía más elemental de estas amenazas se puede clasificar en cuatro grandes grupos [15] [16]:

• Interrupción. Un objeto del sistema se pierde, queda inutilizable o no disponible.

• Intercepción. Un elemento no autorizado consigue un acceso a algún determinado objeto del sistema.

• Modificación. Es una intercepción, además, consigue modificar el objeto. Un caso especial de la modificación es la destrucción, que se entiende como una modificación que inutiliza al objeto afectado.

• Fabricación. Es una modificación, destinada a conseguir un objeto similar al atacado de forma que sea difícil distinguir entre el objeto original y el “fabricado”.

2.1.2 Intrusos o atacantes. Para evaluar la seguridad informática, se debe clasificar en grupos a los posibles elementos que tienen el potencial de atacar a los sistemas de computo; se suele identificar a los atacantes únicamente como personas; esto tiene sentido si hablamos de responsabilidades por un delito informático. Es preferible hablar de elementos y no de personas, el sistema puede verse perjudicado por múltiples entidades aparte de humanos, como por ejemplo programas, catástrofes naturales, un intruso, un gusano, o un simple error del administrador [17]. La clasificación de los intrusos o atacantes está conformada de la siguiente manera:

• Personas: La mayoría de ataques al sistema van a provenir en última instancia de personas que, intencionada o no intencionadamente, pueden causar enormes pérdidas. Los diferentes tipos de personas que de una u otra forma pueden constituir un riesgo para los sistemas y generalmente se dividen en dos grandes grupos: Atacantes pasivos. Exploran por el sistema pero no lo modifican o destruyen.

Atacantes activos. Dañan el objetivo atacado, o lo modifican a su favor. Generalmente los curiosos y los crackers realizan ataques pasivos.

• Ingeniería social. El propósito de este método es conseguir, mediante mentiras o engaños, que alguien facilite la información necesaria para poder llevar a cabo posteriores ataques. Normalmente, este tipo de información se facilita sin que el usuario sepa siquiera que está comprometiendo la seguridad de sus sistemas. Son varios los métodos que puede utilizar para obtener información o que se le permita un acceso que debería estar restringido.

• Autoridad falsa. Consiguen información simplemente convenciendo a la víctima

de que están en una posición en la que esa información les es necesaria, por ejemplo, diciendo que son un jefe superior o supervisor de sistemas.

• Suplantación. La suplantación es una versión de la autoridad falsa en la que se

adopta la personalidad de un individuo que realmente existe, es mucho más

Capítulo 2. Marco teórico.

19

fácil si está hablando a través del teléfono, mediante un correo, en un chat o mediante un mensaje instantáneo.

• Personal. Las amenazas a la seguridad de un sistema provenientes del personal de la propia organización rara vez son tomadas en cuenta; se presupone un entorno de confianza donde a veces no existe, por lo que se pasa por alto el hecho de que casi cualquier persona de la organización, incluso el personal ajeno a la infraestructura informática (secretariado, personal de seguridad, personal de limpieza y mantenimiento) puede comprometer la seguridad de los equipos.

• Crackers. Los entornos de seguridad media son un objetivo típico de los intrusos, ya sea para revisarla, para utilizarlas como enlace hacia otras redes o simplemente por diversión. De esta forma, un atacante solo ha de utilizar un escáner de seguridad contra el dominio completo y luego atacar mediante un simple exploit los equipos que presentan vulnerabilidades; esto convierte a las redes de las empresas o a las de proveedores de servicios de internet, en un objetivo fácil para intrusos que pueden utilizar toda la red para probar nuevos ataques o como nodo intermedio en un ataque a otros organismos, sin desearlo, se convierten en un apoyo a los intrusos que atacan sistemas teóricamente más protegidos, como los militares.

• Intrusos remunerados. Este es el grupo de atacantes que suele afectar más a las grandes empresas o a organismos de defensa. Se trata de intrusos con gran experiencia en problemas de seguridad y un amplio conocimiento del sistema, que son pagados por una tercera parte generalmente para robar secretos o simplemente para dañar la imagen de la entidad afectada.

2.1.3 Amenazas lógicas. Bajo la etiqueta de amenazas lógicas encontramos a todo tipo de programas que de una forma u otra pueden dañar un sistema creados de forma intencionada para ello. Se considera software malicioso (malware), los errores de los programadores también constituyen una amenaza denominada agujeros (bugs) [9]. Software incorrecto. Las amenazas más habituales a un sistema Linux provienen de errores cometidos de forma involuntaria por los programadores de sistemas o de aplicaciones y una situación no contemplada en la etapa de diseño. A estos errores de programación se les denomina bugs, y a los programas utilizados para aprovechar uno de estos fallos y atacar al sistema se les denomina exploits [15]. Puertas traseras. Durante el desarrollo de aplicaciones grandes o de sistemas operativos es habitual entre los programadores insertar “atajos” en los sistemas habituales de autenticación del programa o del núcleo que se está diseñando. A estos atajos se les denomina puertas traseras, y con ellos se consigue mayor velocidad a la hora de detectar y depurar fallos. Algunos programadores pueden dejar estos atajos en las versiones definitivas de su software para facilitar un mantenimiento posterior, para garantizar su propio acceso, o simplemente por descuido [9]. La cuestión es que si un atacante descubre una de estas puertas traseras va a tener un acceso global a los datos, lo que obviamente supone un grave peligro para la integridad del sistema.

Capítulo 2. Marco teórico.

20

Bombas lógicas. Son partes de código de ciertos programas que permanecen sin realizar ninguna función hasta que son activadas; la tarea que realizan no es la original del programa, sino que generalmente se trata de una acción perjudicial. Los activadores más comunes de estas bombas lógicas pueden ser la ausencia o presencia de ciertos archivos, la ejecución bajo un determinado usuario o la llegada de una fecha concreta [9]. Canales cubiertos. También denominados canales ocultos, son vías de comunicación que permiten a un proceso transferir información de forma que viole la política de seguridad del sistema; su detección suele ser difícil, y algo tan simple como el puerto abierto en una máquina puede ser utilizado a modo de canal por un intruso [9]. Virus. Es una secuencia de código que se inserta en un archivo ejecutable (denominado huésped), de forma que cuando el archivo se ejecuta, el virus también lo hace, insertándose a sí mismo en otros programas. En Linux los virus no suelen ser un problema de seguridad grave, debido a que presenta una clara definición de usuarios, grupos, propietarios de archivos y permisos. En Linux, un virus puede afectar únicamente al usuario que ejecute el programa maligno [9]. Gusanos. Es un programa capaz de ejecutarse y propagarse por sí mismo a través de redes, en ocasiones portando virus o aprovechando bugs de los sistemas a los que conecta para dañarlos. Al ser difíciles de programar su número no es muy elevado, pero el daño que pueden causar es muy grande. Puede automatizar y ejecutar en unos segundos todos los pasos que seguirá un atacante humano para acceder a el sistema [6] [15][17]. Caballos de Troya. Los troyanos o caballos de Troya son instrucciones escondidas en un programa de forma que este parezca realizar las tareas que un usuario espera de él, pero que realmente ejecute funciones ocultas sin el conocimiento del usuario. Pueden clasificarse de acuerdo a su método de propagación en tres categorías:

• Programa caballo de Troya. Un programa malicioso que llega enmascarado como cualquier otra cosa, pero que se salta en secreto, las medidas de seguridad de los sistemas.

• Código fuente modificado. Una copia del código fuente de un programa que ha sido modificado con el fin de que incluya alguna puerta trasera o algún agujero de seguridad.

• Programas sustituidos. Después de un ataque, es posible que un cracker sustituya algunos programas del sistema por otras versiones que incluyan al-guna puerta trasera o que le permitan ocultar su actividad.

Los troyanos llegan frecuentemente en forma de juegos, reproductores multimedia, programas para comprometer archivos o cualquier otro programa de interés, algunos otros métodos son: mensajes en los grupos de noticias, correos indeseados (spam), correcciones a problemas de seguridad o pruebas de seguridad, noticias falsas de actualizaciones, entre otros [4] [9] [10].

Programas conejo o bacterias. Bajo este nombre se conoce a los programas que no hacen nada útil, sino que simplemente se dedican a reproducirse hasta que el número de copias acaba con los recursos del sistema (memoria, procesador, disco), produciendo una negación de servicio.

Capítulo 2. Marco teórico.

21

Técnicas salami. Se conoce al robo automatizado de pequeñas cantidades de bienes (generalmente dinero) de una gran cantidad origen. El hecho de que la cantidad inicial sea grande y la robada pequeña hace extremadamente difícil su detección, su uso más habitual es en sistemas bancarios. Herramientas de seguridad. Cualquier herramienta de seguridad representa un arma de doble filo: de la misma forma que un administrador las utiliza para detectar y solucionar fallos en sus sistemas o en la subred completa, un potencial intruso las puede utilizar para detectar esos mismos fallos y aprovecharlos para atacar los equipos. No se puede basar la seguridad de un sistema en el supuesto desconocimiento de sus problemas por parte de los atacantes. Si como administradores no se utilizan herramientas de seguridad que muestren las debilidades de los sistemas (para corregirlas), es seguro que un atacante no va a dudar en utilizar tales herramientas para explotar las debilidades encontradas [18] [19].

2.1.4 Los mecanismos de prevención más habituales en Linux. Para proteger los sistemas se debe realizar un análisis de las amenazas potenciales que puede sufrir, las perdidas que podrán generar, y la probabilidad de su ocurrencia. A partir de este análisis se diseña una política de seguridad que defina responsabilidades y reglas a seguir para evitar tales amenazas o minimizar sus efectos en caso de que se produzcan. A los mecanismos utilizados para implementar esta política de seguridad se les denomina mecanismos de seguridad; son la parte más visible del sistema de seguridad, y se convierten en la herramienta básica para garantizar la protección de los sistemas o de la propia red. Los mecanismos de seguridad se dividen en tres grandes grupos: de prevención, de detección y de recuperación. Los mecanismos de prevención son aquellos que aumentan la seguridad de un sistema durante el funcionamiento normal de este, previniendo la ocurrencia de violaciones a la seguridad; por ejemplo, el uso de cifrado en la transmisión de datos se puede considerar un mecanismo de este tipo, ya que evita que un posible atacante escuche las conexiones hacia o desde un sistema Linux en la red [19]. Por mecanismos de detección se conoce a aquellos que se utilizan para detectar violaciones de la seguridad o intentos de violación [14] [17] [19]; ejemplos de estos mecanismos son los programas de auditoría como Tripwire [12]. Finalmente, los mecanismos de recuperación son aquellos que se aplican cuando una violación del sistema se ha detectado, para retornar a este a su funcionamiento correcto; ejemplos de estos mecanismos son la utilización de copias de seguridad o el hardware adicional. Dentro de este último grupo de mecanismos de seguridad encontramos un subgrupo denominado mecanismos de análisis forense, cuyo objetivo no es simplemente retornarlo a su modo de trabajo normal, sino averiguar el alcance de la violación, las actividades de un intruso en el sistema, y la puerta utilizada para entrar; de esta forma se previenen ataques posteriores y se detectan ataques a otros sistemas de una red [8] [9]. Para la seguridad de los sistemas, se enfatiza en el uso de mecanismos de prevención y de detección; evitar un ataque, detectar un intento de violación, o detectar una violación exitosa inmediatamente después de que ocurra es mucho más productivo y menos comprometedor para el sistema que restaurar el estado tras una penetración de la máquina. Si se consiguiera un sistema sin vulnerabilidades y cuya política de seguridad se implementara mediante mecanismos de prevención de una forma completa, no serian necesarios los mecanismos de detección o recuperación [17].

Capítulo 2. Marco teórico.

22

Aunque esto es imposible de conseguir en la práctica, será en los mecanismos de detección, y sobre todo en los de prevención donde se basa el peso de la seguridad informática. Mecanismos de autenticación e identificación. Estos mecanismos hacen posible identificar entidades del sistema de una forma única, y posteriormente, autenticarlas (comprobar que la entidad es quien dice ser). Son los mecanismos más importantes en cualquier sistema, ya que forman la base de otros mecanismos que basan su funcionamiento en la identidad de las entidades que acceden a un objeto [17] [18]. Mecanismos de control de acceso. Cualquier objeto del sistema ha de estar protegido mediante mecanismos de control de acceso, que controlan todos los tipos de acceso sobre el objeto por parte de cualquier entidad del sistema. Dentro de Linux, el control de acceso más habitual es el discrecional (Discretionary Access Control,DAC), implementado por los bits de lectura, escritura y ejecución y las listas de control de acceso para cada archivo (objeto) del sistema; sin embargo, también se permiten especificar controles de acceso obligatorio (Mandatory Access Control, MAC) [16] [17]. Mecanismos de separación. Cualquier sistema con diferentes niveles de seguridad ha de implementar mecanismos que permitan separar los objetos dentro de cada nivel, evitando el lujo de información entre objetos y entidades de diferentes niveles siempre que no exista una autorización expresa del mecanismo de control de acceso. Los mecanismos de separación se dividen en cinco grandes grupos, en función de como separan a los objetos: separación física, temporal, lógica, criptográfica y fragmentación. Dentro de Linux, el mecanismo de separación más habitual es el de separación lógica o aislamiento, implementado en algunos sistemas mediante una Base Segura de Cómputo (Trusted Computing Base, TCB), implementados por SELinux (Linux Security Enviroment) [17] [18]. Mecanismos de seguridad en las comunicaciones. Es especialmente importante para la seguridad de nuestro sistema el proteger la integridad y la privacidad de los datos cuando se transmiten a través de la red. Para garantizar esta seguridad en las comunicaciones, se utilizan mecanismos que basan su funcionamiento en la criptografía y se utilizan en mayor medida los protocolos seguros como SSH o Kerberos [17]. Criptografía. Es la herramienta fundamental para asegurar la privacidad, secrecía o confidencialidad de los datos, es un término proveniente de raíces griegas que significa escritura oculta, recientemente, ha sido descrita, como el arte o ciencia de desarrollar y usar mecanismos para transformar los datos en ilegibles para cualquiera, excepto para el destinatario [16]. Se utilizan técnicas que permiten modificar la información de entrada mediante algún tipo de algoritmo matemático, el resultado, es una transformación de la información ya sea para ocultarla o determinar su integridad; el proceso inverso resulta muy complejo si no se conocen las técnicas y los datos semillas utilizados para la transformación. Esto proporciona varios aspectos de la seguridad informática, primero, la confidencialidad: evitar que personas no autorizadas tengan acceso a los datos, y segundo, autenticación: proveer un método para certificar que nuestros datos son efectivamente nuestros ante los destinatarios y por ultimo, la integridad: que el contenido de la información no sea alterado. Las principales técnicas de encriptación son:

Capítulo 2. Marco teórico.

23

• Encriptamiento de llave secreta. Denominada también de cifrado simétrico se basa en utilizar una misma llave (patrón de la semilla de codificación) para encriptar y para desencriptar la información. Ejemplos de este tipo de sistemas son Blowfish, DES y RC4, las desventajas de este método son, principalmente, la necesidad de verificar que cada entidad conserva secreta la llave y el problema de entregar la llave secreta a todos los usuarios de manera que no sea vulnerable a la intercepción[18][19].

• Encriptamiento de Llave Pública. Denominada también cifrado asimétrico, reemplaza la llave única por un par de llaves llamadas pública y privada. La llave publica se compartida a los usuarios con los que intercambia información y es utilizada para cifrar la información cuando se desea compartir algo, solo se puede descifrar la información recibida haciendo uso de la llave privada del receptor. Un ejemplo de este tipo de cifrado es el RSA y el DSA, la desventaja de este sistema radica en el tiempo de cifrado y descifrado debido a que no se usa el mismo elemento [18].

• Compendios y resúmenes criptográficos. Las sumas de comprobación, compendio o función hash, es una cadena de texto generada por un algoritmo matemático que permite verificar si dos archivos son idénticos. El cambio de un solo bit en uno de esos archivos hará que esas cadenas sean diferentes. La herramienta más utilizada en la actualidad para realizar comprobaciones de suma es MD5, conocida como cadena resumen, esta es la suma de comprobación con el cifrado más fuerte de las que se usan habitualmente. Una función hash criptográfica acepta como entrada un conjunto de datos y genera como salida un resultado de longitud fija casi siempre más pequeña que el mensaje original [19] [20].

• Firmas Digitales. Esta basado en el esquema de llave publica RSA, el ISO/IEC 9796 fue el primer estándar internacional publicado en 1991, para el 1994 fue considerado como el elemento de seguridad mas importante en Estados Unidos, debido a que permite establecer relaciones de confianza entre dos entidades. Al igual que en un ambiente de relaciones personales, esta marca debe identificar a la entidad de manera única; en la práctica, el remitente somete los datos por enviarse a una función que los resume digitalmente (función compendio o hash). Este resultado lo encripta con su llave privada y lo agrega como firma al mensaje original.

El receptor certifica que el mensaje proviene del propietario de la llave pública con que desencripta el mensaje compendiado, si el compendio descifrado concuerda con el compendio del mensaje original, obtiene datos de los cuales ha validado su origen y su integridad [19] [20].

2.1.5 Canales de comunicación seguros SSH.

Basado en un protocolo llamado SSH, la cual es una especificación para realizar una comunicación segura en entorno de red. El Secure Shell es una herramienta poderosa que permite realizar tareas en un equipo de manera remota, es decir, un equipo puede realizar actividades desde otro utilizando un entorno de comunicación como la red o el internet. Cubre los aspectos de autenticación, encriptacion e integridad de la información de los datos transmitidos en la red, para los sistemas Linux se cuenta con el Open-SSh, el cual está basado en la especificación SSH-2 (Versión 2 del protocolo

Capítulo 2. Marco teórico.

24

SSH) [22]. Permite ejecutar remotamente comandos y hacer transferencias seguras de archivos. Secure Shell (SSH) es un programa usado para asegurar la comunicación entre dos entidades, utiliza una arquitectura cliente - servidor, donde los clientes SSH pueden conectarse a los servidores, como se muestra en la figura 2.1. Se utiliza para ejecutar comandos remotos de forma segura y sirve como un reemplazo de Telnet, permite realizar una utilidad de copia de seguridad remota, sustituyendo a los protocolos tradicionales, como el Protocolo de transferencia de Archivos (FTP) y Protocolo de Copias Remotas (RCP) [22].

Figura 2.1. Arquitectura cliente-servidor de SSH.

SSH garantiza los siguientes aspectos en una comunicación cliente-servidor [22]:

• Privacidad de los datos. Utilizar un algoritmo de encriptación fuerte, significa proteger los datos de intrusos, típicamente, las redes basadas en IPv4 no garantizan la privacidad de los datos. Cualquiera que tenga acceso a un host o a la red puede acceder a los datos que viajan por ella.

• Integridad de las comunicaciones. La información intercambiada no puede ser alterada, el protocolo SSH-2 usa la comprobación de integridad criptográfica, que verifica que los datos transmitidos no han sido cambiados y también, que realmente viene a partir del otro extremo de la conexión. SSH-2 usa algoritmos basados en MD5 y SHA-1. Md5 es uno de los algoritmos criptográficos de reducción más utilizados en todo el mundo, fue desarrollado por Ronald Rivest del Instituto Tecnologico de Massachusetts. Desde el año de 1996 se publico una vulnerabilidad de este algoritmo por el método de colisiones, a pesar de haber sido considerado criptográficamente seguro en un principio, en agosto del 2004, Xiaoyun Wang, Dengguo Feng, Xuejia Lai y Hongbo Yu anunciaron el descubrimiento de colisiones de hash para MD5, el ataque demostrativo requirio una hora de cálculo con un clúster IBM P690 [4]. Este método es critico para aplicaciones que generan en tiempo de operación el resumen hash y lo mantienen como herramienta de autenticacion, para nuestro caso, el método será almacenado de una fuente fiable y sera comprobado en subsecuentes análisis, por lo que se considera apropiado su uso.

Capítulo 2. Marco teórico.

25

• Autenticación. Se valida la identidad del receptor y el emisor en una comunicación. Cada conexión SSH implica dos autenticaciones: el cliente verifica la identidad del servidor SSH (la autenticación de servidor), y el servidor verifica la identidad del usuario que solicita el acceso (la autenticación de usuario). La autenticación de servidor asegura que el servidor SSH es genuino, no un impostor, que se protege contra el utilizando su conexión de red a una máquina diferente.

La autenticación de servidor también protege contra ataques " el hombre en medio ", en el que el atacante se coloca ser visto entre el cliente y el servidor, fingiendo ser el cliente sobre un lado y el servidor sobre el otro, engañando a ambos lados y leyendo todo su tráfico en el proceso. Hace uso de llaves DSA para autenticar al anfitrión de la sesión y sólo le permite una conexión por cada cliente.

• Autorización. Se permite el control de acceso a usuarios autorizados únicamente. Reenvío o tuneleo para encriptar programas o aplicaciones basadas en TCP/IP. El medio de autorización decide lo que alguien puede o no puede hacer. Esto ocurre después de la autenticación. El acceso a sesiones de conexión interactivas, el puerto TCP y el despliegue de ventanas gráficas puede ser controlado todo. Los métodos de cifrado y los algoritmos utilizados para SSH se basan en normas de la industria tales como 3DES, Blowfish, Twofish, AES y RSA.

La estructura de SSH está basada en tres capas que definen el método de autenticación que utilizarán, cabe mencionar que este protocolo autentica en ambos sentidos, al cliente en el servidor y al servidor en el cliente. La capa superior se encarga de la autorización y los elementos permitidos por cada sesión, por último se determinan los recursos disponibles para el cliente. En la figura 2.1 se muestran las capas que conforman SSH y la parte que ocupan dentro del protocolo TCP/IP.

Figura 2.2. Arquitectura de SSH [22].

SSH gestiona un canal de comunicación seguro entre el cliente y el servidor mediante un proceso de peticiones y autenticaciones. En la figura 2.3 se muestra una representación del canal cifrado y establecido entre el cliente y servidor de SSH.

Capítulo 2. Marco teórico.

26

Existen varios métodos para aplicar la validación de un usuario solicitante de una conexión SSH y el servidor, el uso de contraseña o password, una frase secreta que es la semilla del archivo de autenticación y el uso de llaves públicas

Figura 2.3. Canal de comunicación cifrado usando SSH.

Llave pública. En este esquema, se hace uso de un cifrado asimétrico, utiliza un par de llaves llamadas pública y privada. La llave pública es compartida a los usuarios con los que se intercambia información y es utilizada para cifrar la información cuando se desea compartir algo, sólo se puede descifrar la información recibida haciendo uso de la llave privada del receptor. Un ejemplo de este tipo de cifrado es el RSA y el DSA, el cual se muestra en la figura 2.4, donde se muestran las llaves del cliente y del servidor, la llave de sesión generada para cada conexión y la necesidad de contar en el servidor con un reconocimiento de la llave publica del cliente mediante su llave privada

Figura 2.4. Autenticación de SSH usando llaves públicas.

2.1.6. Estándares de seguridad. Un estándar es comúnmente aceptado como la norma de fabricación de acuerdo a un modelo o un patrón; pueden ser un conjunto de reglas establecida para caracterizar un producto o un método de trabajo. Dentro de la seguridad informática, han existido un gran número de aportaciones en diversas áreas, por lo que se han tenido que unificar criterios o generar acuerdos que permitan un desarrollo bien organizado de los avances en esta materia. Existen varios estándares internacionales relacionados con seguridad informática que se consideran importantes en la actualidad o que deben ser referenciados por su importancia histórica [4] [23].

• El RFC2196 Site Security Handbook. Ofrece una guía práctica para quienes intentan asegurar servicios e información, generado por la Internet Engineering Task Force (IETF).

Capítulo 2. Marco teórico.

27

• El estándar británico BS 7799. Es un estándar aceptado ampliamente que ha sido utilizado como base para elaborar otros estándares de seguridad de la información, incluyendo el ISO 17799 y el ISO 27001. Fue desarrollado por el British Standards Institute.

• El estándar IS 15408. Elaborado por la La Organización Internacional para la Estandarización (International Organization for Standardization, ISO). Este estándar, The Common Criteria for Information Technology Security Evaluation v2.1 (ISO IS 15408) es una mezcla mejorada de ITSEC, el Canadian Criteria, y el US Federal Criteria.

• La Serie Arco Iris - Rainbow Series- (Orange Book ) (E.U.) Una importante serie de documentos es la Rainbow Series, que describe varios estándares de seguridad desarrollados en los Estados Unidos. El Orange Book corresponde directamente al diseño de sistemas de auditoría y monitoreo; base fundamental de los IDS. Es un material utilizado para el desarrollo de esta investigación debido a que plantea los principios fundamentales del control de acceso a los sistemas y la integridad de los archivos.

• ISO 11131:1992. Banking and Related Financial Services; Sign-on Authentication. La Organización Internacional para la Estandarización y la Comisión Electrónica Internacional (IEC), forman el sistema especializado para la estandarización internacional, de ellos desprende el ISO/IEC 27001 publicado en 2005, el cual describe Tecnologías de la información, Técnicas de seguridad y Sistemas de gestión de seguridad de la información. Es una guía que define la metodología para la implementación, diseño, uso y adecuación de la seguridad de la información; los apartados A 10.10.10 y A 12.3, están destinados a la auditoria y monitoreo de los sistemas respectivamente.

2.2 Arquitectura del sistema operativo Linux. La creciente popularidad de Linux se debe entre otras razones a su extraordinaria estabilidad, acceso libre al código fuente (lo que permite personalizar el funcionamiento y permite verificar el funcionamiento real) y a la abundancia de documentación relativa a los procedimientos. Cada día existen mas programas que están disponibles para este sistema, y la calidad de los mismos aumenta de versión a versión. La gran mayoría de los mismos viene acompañados del código fuente y se distribuyen gratuitamente bajo términos similares a los del núcleo. Existen numerosas distribuciones de Linux ensambladas por empresas (caso de SuSE, RedHat), fundaciones (caso de Debian, Gentoo, UBUNTU) e incluso administraciones públicas. Cada distribución suele incluir software adicional, incluyendo software que facilita la instalación del sistema. Este apartado está enfocado a describir de manera breve la especificación que conforma la estructura del sistema operativo Linux, en cualquiera de sus distribuciones incluye una base comúnmente llamada núcleo; los módulos con los que interactúa, las aplicaciones disponibles y el funcionamiento general; cabe destacar, que la taxonomía de la estructura del sistema operativo será parte fundamental del desarrollo del proyecto de tesis.

Capítulo 2. Marco teórico.

28

2.2.1 Breve historia de GNU/Linux. El sistema operativo Linux tiene sus orígenes en la plataforma Unix, Unix nació en los años 60, de un proyecto bajo control del Instituto Tecnológico de Massachusetts (MIT), los laboratorios Bell y General Electric. En 1966, un grupo de investigadores de los Laboratorios Bell desarrolló un sistema operativo experimental llamado MULTICS (Información multiplexada y Sistema de Computación). En 1969 se rediseña el SO basado en MULTICS y se denomina Unix, para 1973, escribieron el núcleo de Unix en lenguaje C, un lenguaje de programación de alto nivel, a diferencia de la mayoría de los sistemas, los cuales estaban escritos en lenguaje ensamblador [24]. El Unix en C se podía mantener más fácilmente, y podía trasladarse a otras máquinas casi sin problemas. En 1982 AT&T lanza la primera versión comercial de Unix, el cual, fue concebido para entornos grandes como potentes servidores de internet, básicamente, para el entorno empresarial y por lo tanto bastante caro. La idea de desarrollar un clon de Unix que aportara toda su potencia y de costo accesible para todo el mundo, trajo el surgimiento de FreeBSD, OpenBSD y Linux. Estos clones de Unix respetan sus normas y sus estándares (POSIX), son de código fuente abierto y están bajo la cobertura de la GPL, la Licencia Publica General GNU; lo que representa obtener el código fuente y que esto no genere un costo.

Linux fue generado en Finlandia en 1991 cuando Linus B. Torvalds, estudiante de la Universidad de Helsinki, partiendo de un pequeño sistema Unix denominado Minix. Linus decidió difundir el código fuente por Internet, de manera gratuita y con el nombre de Linux (contracción de Linus y Unix) [26].

La versión era pequeña y se enriqueció debido al uso de de algunos programas GNU, como la bash, el compilador GCC, entre otros. El número de personas que comenzaron a colaborar en el proyecto creció de manera importante, hasta llegar a los cientos de colaboradores; se entregó la primera versión estable de Linux denominada 1.0 en marzo de 1994 [27]. Actualmente, Linux es un sistema Unix completo, estable, que sigue evolucionando y que cada día gana nuevos adeptos. Durante muchos años Linux perteneció, casi por completo al mundo universitario, ahora que el Internet llega a millones de usuarios, Linux se está extendiendo a pasos agigantados, incluso en el mundo empresarial. Linux funciona sobre muchas plataformas como los procesadores x86, 64 bits, Alpha, Sparc, Amiga, Atari y los MAC.

2.2.2 Distribuciones Linux. Una distribución es un conjunto de aplicaciones reunidas por un grupo, empresa o persona para permitir instalar fácilmente un sistema Linux, se destacan por las herramientas para configuración y sistemas de paquetes de software a instalar. La base del software incluido con cada distribución incluye el núcleo Linux y las herramientas GNU, al que suelen adicionarse también varios paquetes de software procedentes de muchos otros proyectos casi todas con Licencia GPL [27]. La base del sistema de cada distribución es muy parecida, incluyendo paquetes básicos del proyecto GNU, un intérprete de comandos y algunas utilidades como son bibliotecas, compiladores y editores de texto. Estos componentes (esenciales para un sistema operativo) en conjunto, nos proporcionan el ambiente funcional necesario para la utilización de los más diversos programas y aplicaciones. Algunas de las ventajas que ofrece el sistema operativo se mencionan a continuación [26]:

Capítulo 2. Marco teórico.

29

• Precio. Debido a que su licencia es GNU, podemos descargarlo gratuitamente desde Internet o comprarlo a un precio muy bajo.

• Requerimientos. Actualmente los sistemas operativos necesitan muchos recursos del sistema para ejecutarse con fluidez, Linux, al poder funcionar exclusivamente en modo texto sin la necesidad de cargar un entorno grafico puede ejecutarse en cualquier maquina a partir de un i386.

• Estabilidad. Al tener un núcleo basado en UNIX, hereda esa estabilidad que siempre ha caracterizado a los sistemas UNIX.

• Seguridad. A nivel de servidor podemos encontrar que la seguridad de GNU/Linux frente a otros servidores de código cerrado del mercado es mucho mayor.

• Multitarea real. Es posible ejecutar varios procesos simultáneamente.

• Velocidad. Debido a la multitarea real que incorpora, y que no es necesario cargar su entorno gráfico para ejecutar servicios o aplicaciones, hacen que su velocidad sea muy superior a otros sistemas operativos que necesitan necesariamente cargar un entorno gráfico para su funcionamiento.

• Código fuente. El paquete incluye el código fuente, por lo que es posible modificarlo y adaptarlo a nuestras necesidades libremente. Sin olvidar que se puede analizar totalmente su funcionamiento.

• Entorno de programación. Es ideal para la programación, se puede programar para otros sistemas operativos; está extensamente documentado, y existen múltiples herramientas para el programador.

• Crecimiento. Su sistema de crecimiento, gracias a la licencia GNU, el código abierto, y la gran comunidad de miles de programadores en todo el mundo, es de los más rápidos que existen en la actualidad.

2.2.3 Características generales de Linux [25]. La historia de los sistemas operativos es un recuento de diversas soluciones a los diferentes problemas que se han ido encontrando; por mencionar algunos de estos tenemos el de la concurrencia de procesos, la memoria compartida, la comunicación entre los procesos, el soporte a múltiples usuarios, etcétera. Los cuales, han sido superados por la evolución de estos con respecto a los requerimientos de sus usuarios. En los sistemas operativos actuales de código libre o comercial, podemos generalizar los siguientes aspectos:

• Multitarea. La palabra multitarea describe la capacidad de ejecutar varios programas al mismo tiempo sin detener la ejecución de cada aplicación. Se le denomina multitarea prioritaria porque cada programa tiene garantizada la oportunidad de ejecutarse, y se ejecuta hasta que el sistema operativo da prioridad a otro programa, por medio del modulo planificador para que se ejecute. Linux y otros sistemas operativos multitarea consiguen el proceso de prioridad supervisando los procesos que esperan para ejecutarse, así como los

Capítulo 2. Marco teórico.

30

que se están ejecutando. El sistema programa cada proceso para que disponga de las mismas oportunidades de acceso al microprocesador. El resultado es que las aplicaciones parecen estar ejecutándose al mismo tiempo (en realidad hay una segmentación del tiempo de ejecución de millonésimas de segundo entre una ejecución y otra). Linux también es capaz de gestionar máquinas con varios microprocesadores, obteniendo la capacidad de procesar paralelamente varios procesos (tantos como microprocesadores tenga la máquina). Esto es lo que se llama concurrencia real.

• Multiusuario. La capacidad de Linux para asignar el tiempo de microprocesador simultáneamente a varias aplicaciones ha derivado en la posibilidad de ofrecer servicio a diversos usuarios a la vez, ejecutando cada uno de ellos una o más aplicaciones. La característica más relevante de Linux y sus funciones de multiusuario y multitarea, es que más de una persona puede trabajar con la misma máquina simultáneamente desde la misma terminal o desde terminales distintas.

• Shell programable. Dentro del shell existe la sintaxis de los comandos de Linux. La programación del shell de ofrece la característica para personalizar su sistema y hacerlo mas amigable o para simplificar muchas de las aplicaciones que se requieren ejecutar, permitiendo realizar una serie de procesos en segundo plano (background) para poder trabajar en otros.

• Independencia de dispositivos. Permite la adaptabilidad del núcleo en cuanto a la visualización de dispositivos nuevos en el sistema, ya que ve a estos dispositivos como enlaces, o simples controladores. No obstante, si existiese algún problema con algún dispositivo, y al tener el código libre, siempre se puede programar un controlador para un dispositivo que no exista, cosa que no es posible realizar en otro sistema operativo comercial.

• Comunicaciones y redes. La superioridad de UNIX sobre otros sistemas operativos es evidente en sus utilidades y conexión en red, por lo que Linux incluye posibilidades de conexión en red tan ajustadamente acopladas como ningún otro sistema operativo, posee la flexibilidad incorporada y podemos mencionar que Internet nació y se creo en un mundo UNIX.

• Portabilidad. La portabilidad es simplemente la posibilidad de transportar un sistema operativo de una plataforma a otra sin que se vea alterado su comportamiento. En la actualidad, Linux es capaz de correr en múltiples plataformas, como pueden ser el i386, ALPHA, PowerPC, etcétera.

2.2.4. Directorios en Linux [5] [25]. La información de los sistemas operativos Linux se organiza en lo que llamamos directorios, estos son elementos contenedores, almacenan archivos o directorios; la estructura que siguen es jerárquica y siempre dependen de un directorio principal denominado raíz (/). Es importante este concepto debido a la estructura basada en directorios del sistema Linux, la cual sirve como base de referencia para todas las actividades; todos los elementos son tratados como directorios, algunos de estos almacenan archivos que determinan la funcionalidad del sistema operativo, los dispositivos de entrada o salida, incluso, los procesos son tratados como directorios virtuales.

Capítulo 2. Marco teórico.

31

2.2.4.1 Sistema de directorios. Es la parte del sistema responsable de la administración de los datos en los dispositivos de almacenamiento; debe proporcionar los medios necesarios para un almacenamiento seguro y privado de la información. La información dentro de los sistemas Linux esta organizada en forma de directorios; los archivos se identifican en la estructura de directorios por la ruta (PATH) en la que se localizan y la estructura de directorios hace uso del sistema de archivos jerárquico estándar (File System Hierarchy Standard, FHS), esta estructura de directorios se describe de manera breve a continuación. / Directorio raíz: Solo hay una raíz, es el único directorio que no contiene

directorio padre, a partir de este se generan todos los demás. Contiene un archivo con la imagen binaria de arranque del núcleo de Linux; esta imagen se carga en memoria al iniciarlo y se mantiene allí hasta que se apaga. Solamente el administrador del sistema debe tener derecho se ejecución, modificación y lectura de este directorio.

/bin Directorio de binarios: Contiene los ejecutables básicos del sistema,

normalmente se encuentran los programas de uso común para los usuarios, como son la copia de archivos, la visualización, el listado del contenido de directorios, etc. Son las aplicaciones del sistema y de este directorio depende el funcionamiento correcto de la interfaz de comandos.

/sbin Directorio de binarios de superusuario: Contiene los ejecutables del

administrador del sistema. /usr Directorio de usuarios: De este directorio se generan los directorios de trabajo

de cada uno de los usuarios; Algunos sistemas han adoptado por incluir los directorios de trabajo de los usuarios en el “/home/”; para dar una mejor organización de este directorio que contiene elementos de trabajo con los usuarios en el entorno de trabajo en red. /urs/bin Contiene los programas ejecutables que son de tamaño

considerablemente grande, los cuales se utilizan menos que los contenidos en /bin.

/usr/lib Contiene los archivos de biblioteca, utilizados por los

compiladores de lenguajes como FORTRAN, Pascal, C, etc. Estos contienen básicamente funciones, en un formato especifico, que pueden ser invocadas desde estos lenguajes.

/usr/man Contiene las páginas del manual en el disco del equipo de

computo. /usr/local Este directorio son generalmente utilizados para que contengan

archivos ejecutables que no forman parte de Linux, cualquier utilidad desarrollada por los usuarios debería estar almacenada en este lugar.

/home Directorio de usuarios del equipo: Se localizan los directorios de los usuarios

del sistema en las cuales guardan sus archivos y configuraciones personales.

Capítulo 2. Marco teórico.

32

/root Directorio del root: Es el directorio de trabajo del administrador del sistema

operativo, o superusuario “root”. /etc Este directorio contiene órdenes y las configuraciones específicas del sistema,

entre ellas las necesarias para arrancar, también contiene las configuraciones globales del software instalado; estas órdenes y configuraciones se guardan en un directorio aparte porque la mayoría de ellas solo pueden ser ejecutadas por usuarios privilegiados.

/tmp Se utiliza para almacenamiento temporal de información. /var Contiene archivos variables, como pueden ser las colas de impresión. /boot Es donde se encuentran los archivos de arranque, así como el núcleo que se

cargará en el inicio. /dev Este directorio contiene todos los dispositivos (devices) empleados para la

comunicación con dispositivos periféricos; tales como impresoras, discos, terminales, etc. Un archivo de dispositivo es reconocido por el núcleo como un elemento de Entrada-Salida; esto es denominado independencia de dispositivo, y permite emplear las mismas funciones para trabajar con cualquier dispositivo tratándolo como un archivo ordinario.

/proc Este directorio guarda la información sobre los procesos que hay en ejecución

y sobre el sistema en general (CPU, memoria); es una copia de lo que está en la memoria, por lo tanto, cada proceso ejecutado o terminado, realizara modificaciones sobre este directorio.

/lib Contiene la biblioteca de funciones necesarias para el compilador de C.

Contiene las bibliotecas compartidas, esenciales en el sistema. /media Este directorio sirve para “montar” los dispositivos de almacenamiento

externos; las unidades de CD, DVD, las memorias USB, los discos duros externos, terminales, impresoras, etc.

Como puede apreciarse en la figura 2.5, la estructura del árbol es bastante grande, se ha descrito solo los directorios de un nivel debajo de la raíz, esta estructura jerárquica permite distribuir las prioridades de los directorios y la importancia de sus contenidos. El uso inapropiado de las características de un directorio o de un archivo constituye un riesgo de seguridad. Los controles de acceso a recursos y los usuarios del sistema son el esquema de seguridad del sistema operativo. Estos conceptos serán retomados en los capítulos posteriores debido a la importancia y clasificación de los elementos contenidos en los directrios, la estructura será clasificada de acuerdo al nivel de riesgo que implica la modificación de los archivos que contiene y la relación con el funcionamiento del sistema.

Capítulo 2. Marco teórico.

33

Figura 2.5. Sistema de directorio de archivos Linux.

2.2.4.2 Las cuentas de los usuarios. La mayoría de los sistemas Linux suelen tener un gran número de usuarios, y cada uno de ellos tiene una cuenta desde la cual accede al sistema. Normalmente, cuando se crea una cuenta, el administrador del sistema se encarga de que ésta cumpla unas normas mínimas de seguridad que no comprometan en modo alguno la seguridad del sistema. Pero a veces, los usuarios modifican su contenido y sin cuenta ponen en peligro la integridad de sus propios datos y, consecuentemente, la seguridad de todo el sistema, ya que estas vulnerabilidades pueden ser aprovechadas por los intrusos informáticos para afianzarse aún más en el sistema. Vamos a centrarnos en aquellos aspectos relacionados con la seguridad de las cuentas de los usuarios, como pueden ser los permisos y el propietario de los archivos o directorios, así como de los archivos de arranque e inicialización del Shell. Este aspecto es importante considerando que en el recae la mayor parte de la seguridad del sistema, la información donde se almacenan los usuarios validos de Linux es en /etc/users. Técnicamente no es posible trabajar en el ambiente Linux si no se tiene un usuario reconocido por el sistema, razón por la cual, muchos de los intrusos intentan obtener este archivo con permisos de escritura, o de lectura para ingresar como otro usuario con privilegios. El usuario que existe en los sistemas Linux como administrador es root, este usuario tiene la capacidad de decidir sobre todas las acciones del equipo, por ser el administrador posee privilegios sobre todos los elementos del sistema. Un usuario no administrador debería tener permisos restringidos y solo sobre algunos elementos del sistema, inicialmente toda su información se maneja dentro del directorio /home. 2.2.4.3 Mecanismos de protección. El sistema de archivos de los sistemas Linux proporciona una serie de mecanismos para controlar quién y qué se puede realizar con los archivos almacenados. Estos mecanismos son los permisos, el identificador de propietario (User ID, UID) y el identificador de grupo (Group ID,GID) que poseen todos y cada uno de los archivos y directorios del sistema.

Capítulo 2. Marco teórico.

34

• Los permisos, el propietario y el grupo. Los permisos son un conjunto de 9 bits que controlan quién puede leer, escribir y ejecutar o acceder a un determinado archivo o directorio, respectivamente. Estos 9 bits se encuentran agrupados de tres en tres siguiendo el patrón rwx y cada uno de estos grupos de 3 bits se representa mediante un número octal. En la tabla 2.1 aparecen las ocho posibles combinaciones que se pueden realizar con cada grupo de 3 bits.

Octal

Binario

Permisos

0

000

--- 1

001

--x

2

010

-w- 3

011

-wx

4

100

r-- 5

101

r-x

6

110

rw- 7

111

rwx

Tabla 2.1. Posibles combinaciones de permisos.

El primer grupo corresponde a los permisos del propietario del archivo, el segundo a los permisos del grupo y el tercero a los permisos del resto de los usuarios.

La aplicación de cada uno de estos grupos de permisos depende del UID y el GID. Si el UID coincide con el UID del archivo al que se desea acceder, se aplicarán los permisos correspondientes al propietario, si el UID es distinto al del archivo pero el GID coincide, se aplican los permisos para el grupo. Si no coinciden ni el UID ni el GID, se aplicarán los permisos correspondientes al resto de los usuarios. Junto a estos 9 bits aparecen otros 3 que afectan a la operación de los archivos ejecutables y directorios: el bit SUID, el bit SGID y el bit sticky.

• Los bits SUID y SGID. Los bits SUID y SGID, con código octal 4000 y 2000, respectivamente, se aplican principalmente a archivos ejecutables. Estos bits permiten que el usuario que ejecuta el programa pueda acceder a archivos que de otra forma no podría. Cuando se ejecuta un programa con el bit SUID activado, el proceso que ejecuta el programa adopta durante toda la ejecución de éste el UID del propietario. Con el bit SGID ocurre lo mismo, excepto que la identidad que se adopta es la del grupo. Cuando un programa tiene activado el bit SUID, aparece una 's', en vez de una 'x', en los permisos del propietario del archivo. Si se activa el bit SGID, la 's' aparecerá en los permisos del grupo.

• El bit sticky. El bit sticky (código octal 1000) puede utilizarse tanto en programas como en directorios. Cuando se utiliza sobre un programa, éste queda continuamente cargado en memoria, de manera que no hay necesidad de hacer intercambios de páginas entre memoria principal y secundaria. Si el bit sticky se activa sobre un directorio, ningún usuario puede borrar o renombrar en ese directorio archivos que pertenezcan a otros usuarios. Este bit es especialmente útil en directorios de escritura pública como /tmp, ya que evita que cualquier usuario pueda borrar o modificar los archivos de los demás. Para identificar un programa o directorio con el bit sticky activado, tan sólo se debe comprobar que la 'x' de los permisos del resto de los usuarios del sistema ha sido sustituida por una 't'.

Capítulo 2. Marco teórico.

35

• Cambio de los permisos, el propietario y el grupo. Todos los permisos se pueden modificar mediante el programa chmod. El propietario y el grupo de un archivo se pueden cambiar mediante los programas chown y chgrp, respectivamente. El programa chown sólo puede ser utilizado por el superusuario, mientras que el programa chgrp puede ser utilizado por el superusuario o cualquier usuario, siempre que éste sea el propietario del archivo y pertenezca al grupo al que se va a cambiar el archivo.

2.2.4.4 Los archivos de inicialización del sistema. Los archivos de inicialización del sistema, tales como /etc/rc. config, /sbin/init. d/*, /etc/rc o /etc/rc. d/*, son el lugar ideal para que un intruso coloque un mecanismo que le permita acceder al sistema. Estos archivos y directorios deberían estar protegidos contra escritura, de forma que el superusuario sea el único que pueda modificarlos. A fin de evitar riesgos, estos archivos deberían ser periódicamente revisados, con idea de detectar posibles modificaciones que pudieran poner en peligro la integridad del sistema. El archivo /etc/profile. El archivo /etc/profile es el primero que se ejecuta una vez que el usuario ha cedido al sistema. Este archivo es común para todos los usuarios y normalmente contiene inicializaciones y valores de variables predeterminados, así como alias globales para todo el sistema. A este archivo sólo debería poder acceder para escritura el superusuario, ya que si un intruso consigue acceder a él, las consecuencias podrían ser desastrosas. Lo más normal es que los permisos de este archivo sean 644. 2.2.4.5 Detección de archivos que comprometen la seguridad. Aparte de los archivos propios de root,, en las cuentas de los usuarios pueden existir determinados archivos que pueden resultar conflictivos. Entre ellos podemos encontrar los archivos con el bit SUID o el bit SGID activados, archivos ejecutables, e incluso un archivo oculto .rhosts que permita el acceso remoto a nuestra cuenta.

• Archivos con los bits SUID/SGID activados. Los archivos con los bits SUID o SGID activados son peligrosos por dos razones. La primera es que los archivos con algunos de estos bits activados, sobre todo si se tratan de shell scripts, pueden poner en peligro la seguridad del sistema si están implementados siguiendo unas normas mínimas de seguridad. La segunda razón, la que más nos interesa, es que normalmente uno de los métodos más utilizados por los intrusos para acceder al sistema adoptando la identidad de otro usuario son los shells o los programas que ejecutan un shell y que tienen el SUID activado. Si se detecta la presencia de este tipo de archivos en cuentas de los usuarios, el sistema ganaría en seguridad.

2.4.4.6 Modificación del sistema de directorios. Todas las modificaciones que se realizan al sistema de directorios en Linux son manejadas por una interfaz, la cual permite interacción con el núcleo del sistema operativo y este a su vez, realiza la interacción con el dispositivo físico. De esta manera, cada modificación o acceso a el sistema de archivos se realiza haciendo uso de llamadas al sistema. Solo nos interesan para este trabajo de investigación las

Capítulo 2. Marco teórico.

36

relacionadas con el sistema de archivos, en la figura 2.6 se muestra un esquema de la interfaz de llamadas al sistema que implementa el núcleo de Linux. El usuario puede utilizar diversos métodos que modifican o consultan el sistema de archivos, entre los que podemos mencionar: Desde el intérprete de comandos.

• rm Eliminación de archivos y directorios pertenecientes al cliente, con permisos de ejecución y escritura.

• mv Mover o renombrar archivos y directorios pertenecientes al cliente, con permisos de ejecución y escritura.

• vi Generación de archivo mediante un editor de texto, se almacena el archivo con el nombre del usuario como propietario y el grupo al que pertenece, se asignan permisos según máscara predeterminada por el administrador.

• ln Generación de enlaces suaves o fuertes de un archivo o directorio, se almacena el archivo con el nombre del usuario como propietario y el grupo al que pertenece, se asignan permisos según mascara predeterminada por el administrador.

Desde las aplicaciones.

• Las aplicaciones que trabajan directamente con la generación o edición de los archivos como pudieran ser un editor de palabras, hojas de cálculo, editores de imágenes, entre muchas otras, hacen uso de llamadas al sistema para la manipulación de la información dentro del sistema de directorios y archivos. (sys_open, sys_exit, creat, close, read, write).

La instalación o desinstalación de paquetes.

• Existen varios métodos para agregar programas o eliminarlos, pero la metodología es casi siempre la misma, obtener un paquete de archivos comprimidos, crear una carpeta para descomprimir dentro los archivos, generar los archivos compilados a partir del código fuente, incluir dependencias funcionales de otros paquetes instalados o solicitar la instalación de las librerías necesarias para el funcionamiento .Por último, instalar el paquete de acuerdo a los archivos de configuración, los parámetros de ruta, usuario, permisos de ejecución y documentación necesaria para la utilización del software.

Este procedimiento puede hacerse desde la línea de comandos, llevando consigo algunas operaciones de configuración adicionales. El usuario autorizado para instalar paquetes es únicamente el administrador del sistema (root), los usuarios solo pueden instalar software que quedará dentro de su directorio /home y el cual no estará disponible para otros usuarios ni ejecutado fuera de este nivel, incluso, si existen dependencias funcionales del paquete con otros que se ejecutan como administrador estas no serán realizadas y la instalación quedará incompleta o no funcionará el software.

Capítulo 2. Marco teórico.

37

Figura 2.6. Arquitectura del sistema operativo Linux.

Algunas de las herramientas que facilitan el trabajo de instalación de software son los gestores de paquetes, los cuales mantienen una base de datos de los paquetes disponibles en repositorios y permiten mantener un sistema de archivos actualizados. En el caso de las distribuciones Linux Basadas en Debían, los paquetes disponibles para el Sistema Operativo se encuentran empaquetados en un formato comprimido con extensión”.deb”. Estos paquetes han sido probados para una distribución derivada directa, existen otros paquetes con extensiones diferentes que funcionan en esta distribución, pero deben ser instalados de manera manual, debido a la diferencia de la estructura de directorios principalmente. Algunas de las herramientas utilizadas para la actualización de software, instalación y eliminación de paquetes son las siguientes:

• Apt-get: Interfaz en línea de órdenes de APT (Advanced Package Tool), herramienta para la gestión de paquetes de software del Proyecto Debian. Es básicamente una biblioteca de funciones de C++ empleada por otros programas. Almacena una lista de los servidores en internet (repositorios) donde se encuentran los paquetes disponibles. ``/etc/apt/sources.list''

• Permite la instalación, desinstalación y actualización de algún paquete. Además de mantener una base de datos de todos los paquetes instalados en el equipo.

• Aptitude: Es una interfaz para APT, muestra una lista de paquetes de software que permiten elegir de modo interactivo la instalación o eliminación de éstos. Cuenta con un sistema de búsqueda de patrones que facilitan las relaciones de dependencia funcional de los paquetes. Está diseñado para GNU/Debian, y se extendió hacia otras distribuciones basadas en paquetes RPM. Es básicamente una biblioteca de funciones que provee la interfaz gráfica consistente en menús desplegables.

Capítulo 2. Marco teórico.

38

• Synaptic: Es una interfaz gráfica GTK+ de APT para el sistema de gestión de paquetes de Debian. Utiliza un sistema de paquetes .deb, pero también puede ser utilizado en sistemas basados en paquetes RPM. Permite la actualización de paquetes, modificación de repositorios, actualización y eliminación de paquetes, además de un sistema de búsqueda de patrones en un entorno muy sencillo de utilizar, su interfaz permite realizar la mayoría de las tareas con algunos clicks del mouse.

La instalación de paquetes no es una tarea cotidiana, es decir, no sucede con mucha frecuencia y sólo el administrador lo puede realizar; en el mejor de los casos un usuario puede agregar programas dentro de su directorio. Por esta razón, al encontrar alguna instalación o eliminación de los programas debemos suponer que la tarea la realizó el administrador del sistema, en caso contrario, habría alguna intrusión y ésta debería verse reflejada en el reporte de integridad.

2.4.4.7 Modificación del esquema de permisos. Se describen a continuación, los comandos que permiten la modificación de las propiedades de usuario, grupo y permisos de los archivos del sistema Linux, son parte de las llamadas de sistema operativo.

• Chown: Este comando permite la modificación del propietario del archivo, al realizar copias de archivos, éstos obtienen siempre como propietario al usuario que realiza la operación, de la misma manera ocurre con la creación de archivos. Un archivo no podrá ser eliminado si no es el propietario del archivo o el usuario administrador del sistema.

• Chgrp: Este comando permite la modificación del grupo al que pertenece el archivo, los usuarios pertenecientes al mismo grupo tendrán privilegios de acuerdo al sistema de permisos que posea el archivo.

• Chmod: Este comando permite la modificación del esquema de permisos que tienen el propietario, los usuarios del grupo y todos los demás usuarios del sistema. Se implementa en agrupamientos de 3 bits que son colocados en decimal para facilitar su interpretación, corresponden a usuario, grupo, y todos los demás. El último agrupamiento es un conjunto especial que le permite ejecutarse bajo otro propietario o grupo

2.2.4.8 Escalamiento de permisos. A continuación veremos los problemas de seguridad en los que puede estar implicado el sistema de archivos o los archivos existentes, definiendo como escalamiento de permisos a todo acceso por parte de un usuario a recursos no permitidos, por medio de abuso de recursos, explotación de bug o cualquier otra técnica. Archivos de dispositivos: Los archivos de dispositivos son el mecanismo que nos proporcionan los sistemas Linux para comunicarnos con el hardware y los dispositivos del sistema. Este mecanismo proporciona una gran flexibilidad, sobre todo a los programadores, que no se tienen que preocupar por el tipo de dispositivo que se esté utilizando, pero tiene el inconveniente de que puede comprometer la seguridad del sistema si un intruso consigue acceder a cualquiera de ellos sin autorización. Existen

Capítulo 2. Marco teórico.

39

dispositivos, que permiten acceder a la memoria del sistema. Lógicamente, a este archivo sólo debería poder acceder, tanto para lectura como para escritura, el superusuario, ya que si un intruso consigue acceder a él podría, entre otras muchas cosas, modificar sus privilegios, cambiar los permisos de los procesos, modificar los datos que se encuentren en memoria, obtener las contraseñas de los usuarios e incluso bloquear el sistema. Algo parecido pasaría con otros archivos de dispositivos, como, por ejemplo, los que permiten acceder a las distintas particiones de los discos duros, modems, redes, terminales, etc. Parece lógico pensar que la existencia de archivos de dispositivos en el sistema supone un verdadero peligro, y realmente lo es si sus permisos no están debidamente protegidos o no están correctamente establecidos.

Una práctica bastante común en los intrusos informáticos consiste en crear archivos

de dispositivos en el sistema tras haber accedido a él como root. Normalmente suelen

crearlos en directorios ocultos y darles nombres de programas del sistema. Todo

archivo de dispositivo que no se encuentre en el directorio /dev puede ser considerado

como sospechoso. Los archivos de dispositivos pueden ser creados mediante el

programa mknod. Lógicamente, este programa debe estar bien protegido, de forma

que sólo pueda ser ejecutado por el superusuario.

Archivos del sistema con el bit SUID activado: Si un intruso consigue acceder al sistema como superusuario, lo más normal es que se las ingenie de alguna manera para mantener los privilegios la próxima vez que acceda al sistema. De entre todas las posibilidades existentes, una de las más utilizadas es la creación de programas con el bit SUID activado propiedad del superusuario. Si un intruso coloca este tipo de programas en la cuenta de un usuario, resulta muy fácil detectar, pero si el intruso decide ocultar el programa en uno de los directorios en los que se almacenan los archivos del sistema y además le asigna el nombre de uno de estos programas, puede ser casi imposible detectarlo.

Caballos de Troya en los directorios públicos del sistema: Otro mecanismo muy utilizado por los intrusos informáticos consiste en la creación de caballos de Troya en los directorios públicos del sistema. Estos caballos de Troya suelen ser programas ejecutables para que el usuario no pueda conocer su contenido. Normalmente, estos programas crean archivos .rhosts, modifican los permisos de determinados archivos del directorio de entrada del usuario, añaden líneas conflictivas en los archivos de arranque del shell o crean shells con el bit SUID activado. Todos estos métodos persiguen un objetivo común: obtener los privilegios del usuario que ejecuta el caballo de Troya.

2.2.4.9 Detección de modificaciones en los archivos del sistema.

Si se produce un ataque en el sistema, es muy probable que el intruso modifique o cree determinados archivos para facilitar su entrada en el sistema en una próxima ocasión. Una práctica bastante extendida consiste en modificar el comportamiento de diversos programas del sistema, como Is o ps, de forma que no sean información que pueda delatar su presencia. Otra práctica muy común consiste en crear shell scripts con el bit SUID activado y ocultarlos entre los archivos del sistema. Esta práctica, aunque efectiva, podría ser detectada fácilmente, ya que el administrador podría comprobar periódicamente la presencia de este tipo de archivos en el sistema. Pero de todas estas prácticas, una de las más difíciles de detectar es la modificación los propios programas del sistema.

Capítulo 2. Marco teórico.

40

Un intruso podría modificar el programa login de forma que introduciendo un nombre de usuario determinado pudiera ceder al sistema como root. Otra alternativa podría ser modificar el programa passwd para que todas las contraseñas de los usuarios quedaran almacenadas en archivo o fueran enviadas por correo electrónico a una dirección determinada. La única manera de detectar este tipo de modificaciones en los archivos es mantener una base de datos con los datos de los archivos e información adicional como un checksum o un resumen e ir comparándola periódicamente con los datos de los archivos almacenados actualmente en el sistema. Si se detecta cualquier variación entre los datos almacenados y los datos de los archivos del sistema, es muy probable que un intruso haya modificado algún archivo. Lo normal sería incluir en la base de datos aquellos directorios que contengan programas clave del sistema, como, por ejemplo, /bin, /usr/bin, /sbin o /usr/sbin, junto a otros que el administrador considere también importantes o piense que pueden resultar conflictivos. Una vez creada la base de datos, tendremos información suficiente para detectar cualquier modificación que se pudiera producir sobre los archivos de los directorios especificados. Para comprobar si se ha producido algún tipo de modificación sobre cualquiera de los archivos, se debe ejecutar algún procedimiento de búsqueda de diferencias.

2.2.5 Procesos [5] [17] [19]. Los procesos son programas que se encuentran en ejecución, puede haber mas de un programa ejecutándose al mismo tiempo, debido a que Linux es multitarea, pero no dos procesos al mismo tiempo en el sentido de que solo existe un procesador en el equipo de computo. Cuando un programa es leído por el sistema operativo y cargado en memoria para ejecutarse se convierte en proceso; a estos se les asignan recursos para que puedan ejecutarse correctamente, podemos citar algunos como: memoria, CPU, dispositivos de entrada-salida, etc. Cada proceso en Linux tiene asociado un número que lo identifica; este número es asignado por el núcleo y se denomina identificador de proceso o PID (process identifier); además del PID, los procesos tienen asignado otro número denominado PPID (parent PID), que identifica al proceso padre del proceso. La generación de procesos, es un concepto que deriva del manejo de hilos, procesos que generan a otros procesos, los cuales se multiplexan en el tiempo de atención del procesador. Los tres estados básicos en los que se puede hallar un proceso se describen a continuación: 1.- El proceso se esta ejecutando- Sólo puede haber un proceso en este estado debido a que solo hay un procesador, el CPU es compartido en tiempo por todos los procesos, se alternan de acuerdo a su prioridad. 2.-El proceso está durmiendo- Se encuentra en este estado cuando no puede proseguir su ejecución por faltarle algún recurso o porque esta esperando la terminación de una operación de entrada-salida 3.-El proceso no dispone de procesador- Se encuentra listo para ejecutarse y continúa su ejecución cuando se lo indique el planificador de CPU o scheduler.

Capítulo 2. Marco teórico.

41

El núcleo como eje del sistema operativo, se encarga de la administración de las direcciones de memoria, la creación, ejecución y destrucción de los procesos, la administración del sistema de interrupciones y el de excepciones, el sistema virtual de archivos, los dispositivos de entrada y salida, los sistemas de memoria cache, los diferentes sistemas de archivos y los procesos de comunicación entre todos los elementos anteriores. Cuando se agregan al núcleo módulos para que trabajen como herramientas del sistema, la relación de ejecución y control pasa a ser perteneciente del Kernel, por lo cual, de estos últimos también se encarga el núcleo. El objetivo de un análisis del núcleo del sistema, refiere al monitoreo directo de la administración de los procesos y el manejo de los módulos que se instalan; la modificación o creación de estos, debe ser comparada con una base de datos fiable para determinar el estatus del sistema, previendo códigos maliciosos en procesos no permitidos o en módulos del núcleo que pudieran haber sido modificados.

2.2.6 Intérprete de comandos [5] [17] [28]. El shell o intérprete de comandos es el interfaz básico que permite comunicarse con la computadora y arrancar los programas guardados en una unidad de almacenamiento. Internamente, es un programa que espera a que se le introduzca una orden o comando para ejecutarlo, tras lo cual vuelve a quedarse a la espera del siguiente comando. Esta funcionalidad básica es un punto común que tienen todos los intérpretes de comandos de cualquier sistema operativo. Dependiendo del shell y de los recursos a su disposición, aparecen diversas extensiones que constituyen un autentico lenguaje de programación que se encuentran en todos los sistemas operativos Linux; algunos de los elementos importantes de una shell son:

• El prompt, es un indicativo de que la shell esta lista para recibir nuevos comandos, las variables de entorno permiten al usuario asignar o acceder a cierta información, la cual es valida solo mientras la shell que el usuario esta usando continué cargada en memoria. Cuando el usuario sale del sistema (log out) esta información se pierde.

• La entrada y salida estándar son unas abstracciones que proporcionan al programador una forma unificada de leer y escribir datos desde un programa, la entrada inicialmente apunta al teclado, pero, el usuario puede hacer que la entrada estándar apunte a un archivo de datos o a otro recurso; lo mismo ocurre con la salida estándar, esta apunta por defecto a la pantalla, pero un usuario puede manipularla de tal manera que apunte a un archivo, la impresora, etcétera.

• Una tubería, es una forma de conectar la salida de un programa con la entrada de otro programa automáticamente. Este concepto permite que varios programas puedan encadenarse y hacer que los resultados de un comando puedan tratarse como datos a procesar por el siguiente. Una característica principal de un sistema operativo multitarea es que puede aparentar que esta ejecutando varios procesos a la vez.

La interfaz de comandos es un elemento importante en la realización de esta tesis, se utiliza la Bourn Shell (Bash) para la búsqueda y recopilación de información del sistema de archivos.

Capítulo 2. Marco teórico.

42

2.2.7 Sistema de almacenamiento de sucesos [5] [17]. Todos los eventos de un sistema operativo Linux pueden ser almacenados, desde el acceso de los usuarios, hasta el uso de archivos o intentos de modificaciones no permitidas; la información de estos eventos es almacenada en archivos de texto plano denominados bitácoras, algunos ejemplos de eventos son: conexión de los usuarios, llamadas al sistema, errores de programas, etc. Aunque muchos de los archivos de bitácora son comunes en cualquier sistema, su localización, o su formato, pueden variar entre diferentes sistemas Linux. Estas referencias son utilizadas por elementos de búsqueda de intrusiones o de seguridad forense para determinar el punto en que el sistema fue corrompido.

2.2.7.1 El demonio syslogd. Linux maneja todos sus procesos con un control comúnmente llamado demonio, los demonios se encargan del manejo de los procesos específicos de cada tarea, existen así, demonios de impresión, del trabajo con archivos, la interfaz gráfica, el que verifica el funcionamiento generalizado del sistema se llama syslog. El demonio syslogd se lanza automáticamente al arrancar un sistema Linux, y es el encargado de guardar informes sobre el funcionamiento de la máquina. Recibe mensajes de las diferentes partes del sistema y los envía y/o almacena en diferentes localizaciones, tanto locales como remotas, siguiendo un criterio definido en el archivo de configuración (/etc/syslog.conf), donde se especifican las reglas a seguir para gestionar el almacenamiento de mensajes del sistema. Es muy importante este sistema de monitoreo, ya que es el elemento de seguridad implementado por el propio sistema, todo lo que ocurra en el sistema es registrado por este demonio, incluyendo los fallos, los intentos de conexión o los intentos de intrusión. 2.2.7.2 Auditoria de seguridad. El hecho de examinar los registros de las bitácoras se denomina auditoria de seguridad del sistema, el análisis de esta permite detectar intentos de ataque, uso indebido de los recursos o actividades sospechosas; existen desventajas; debido a la gran cantidad de información que potencialmente se registra, puede hacer difícil detectar problemas por el volumen de datos a analizar. La auditoria puede ser utilizada para reconstruir eventos después de que haya ocurrido un problema; los daños pueden ser fácilmente evaluados, localizando con precisión, cuando, como y porque ocurrió el problema. Puede ayudar en el proceso de recuperación de archivos utilizando el control de cambio realizados en este; puede asistir en la detección de intrusos, examinando los registros cuando son creados o después de producido el hecho, detectar cambios en el rendimiento del sistema por algún virus o gusano; incluso, permite comprobar si el sistema opera normalmente o existe un incremento notable de uso de los recursos a consecuencia de algún ataque.

Capítulo 2. Marco teórico.

43

2.3 Entorno de trabajo del servidor de monitoreo. Los sistemas de monitoreo tienen un gasto de recursos de cómputo grande dependiente de la técnica de identificación que implementen, aunado a esto, pueden contar con su propio entorno de aplicación y presentación, lo cual representaría una carga extra para el sistema huésped. Con el objetivo de realizar una herramienta portable, ligera y fácilmente configurable, se pueden utilizar tecnologías que implementan estos últimos dos aspectos, permitiendo enfocar el desarrollo de la herramienta en el aspecto de análisis de posibles intrusiones; a continuación se mencionan dos herramientas fundamentales de trabajo para el acceso y almacenamiento de la información.

2.3.1 Servidor de páginas web. Los servidores web son sistemas que proporcionan recursos utilizando el protocolo de transferencia de hipertexto (http por sus siglas en ingles), esta diseñado para transferir páginas desarrolladas en lenguaje HTML haciendo uso de una interfaz de comunicación implementada en navegadores (browser). El servidor se encarga de proporcionar los recursos que le son solicitados por un equipo denominado cliente. Permite una muy alta disponibilidad de la información a múltiples usuarios dentro de una red y es el método mas difundido de conexión en internet en la actualidad. El conjunto aplicado para este servidor lo constituyen básicamente un lenguaje de programación y una base de datos, destacando la pila de aplicaciones Linux, Apache, PHP / Perl /Phyton, MySQL (LAMP). En particular, el servidor HTTP Apache esta diseñado para plataformas Linux /GNU, pero puede ser implementado incluso en Windows. Su desarrollo comenzó en 1995 por parte de la Apache Software Fundation, actualmente se encuentra en la versión 2.2. Entre sus aspectos más destacables podemos mencionar la modularidad, capacidad de mensajes de error configurables, uso de técnicas de autenticación y su conexión a bases de datos. Apache tiene amplia aceptación dentro de los usuarios de red, llegando a ser empleado en el 48% de los sitios web en el mundo en el año 2005, en el desarrollo de este proyecto, será una pieza fundamental, ya que almacenara el gestor de reportes que permitirá dispones de la información desde cualquier punto de la red.

2.3.2 Servidor de base de datos. Los sistemas de base de datos permiten el almacenamiento, modificación y consulta de volúmenes muy grandes de información en tiempos muy cortos. MySQL es un sistema de gestión de base de datos relacional, utiliza el lenguaje de consultas estructurado (SQL), es desarrollado por la empresa Open Source. MySQL Se puede instalar en diferentes plataformas, implementa socket TCP/IP para la conexión con los clientes, entre muchas otras cosas. La versión mas reciente es la 5.0 que soporta transacciones, procedimientos almacenados, conectividad segura, maneja la licencia GPL y una licencia privativa que brinda soporte y servicios adicionales por parte de la empresa.

Capítulo 2. Marco teórico.

44

2.4 Comentarios finales. En este capítulo se dio una introducción a la problemática de la seguridad de la información y un contexto de las amenazas existentes, además de los mecanismos de detección de intrusos en los sistemas de cómputo. Se proporcionó una panorámica del problema y de la relación e interdependencia de los sistemas de seguridad con el sistema operativo. Posteriormente, se dio una introducción de los esquemas y elementos que utilizan los sistemas de detección de intrusos, destacando algunas de las ventajas de conformidad a las técnicas que se implementan; haciendo una mención importante en las recomendaciones que existen para el diseño de este tipo de sistemas. Se describió de manera somera la arquitectura del sistema de archivos Linux, elemento en que recaerá la mayor importancia de nuestro desarrollo; y por ultimo, se hizo mención de los elementos que por construcción pudieran representar una portabilidad y un soporte a la gestión de recursos e información dentro de una red de área local.

Capitulo 3. Análisis y diseño del sistema.

45

CAPÍTULO 3. ANÁLISIS Y DISEÑO DEL SISTEMA. A lo largo de este capítulo se muestra la metodología utilizada para el análisis de los sistemas de archivos Linux y la detección de intrusiones, los requerimientos para la generación de un esquema de directorios referencia, la búsqueda de cambios, la arquitectura de los procedimientos de monitoreo, el diseño de la base de datos de modificaciones, los métodos de autenticación y codificación.

3.1 Análisis y diseño del sistema de detección de intrusos. En este capitulo se retoman los diseños de funcionamiento de los sistemas de detección de intrusos descritos en el capítulo 1, se define un esquema del nivel de riesgo que constituye una intrusión para cada uno de los directorios del árbol de archivos del sistema operativo Linux. Posteriormente, se describen las características que permiten la identificación y reconocimiento de modificaciones de un archivo incluyendo técnicas criptográficas. Continuamos con el análisis de los requerimientos mínimos del sistema, considerando los elementos que intervienen en la operación y las restricciones propias determinadas por cuestiones de seguridad, recursos disponibles, tecnologías utilizables entre otros. Realizado análisis de requerimientos, se procede al modelado del sistema, este modelo será desarrollado en subsistemas funcionales, los cuales corresponden a elementos específicos de acción del sistema. Cada subsistema tiene relación funcional con los demás, por lo tanto, será descrito en diagramas de actividades, los cuales incluyen descripción de los elementos encargados de ejecutar los procedimientos necesarios. Para finalizar, se diseña el modelo de una base de datos relacional, la cual permita almacenar datos de la integridad del sistema analizado, sirva de base fiable de monitoreo y permita la actualización de las anomalías detectadas. Además, será utilizada como plataforma para la generación de reportes y estadísticas de los equipos analizados.

3.2 Requerimientos. Para crear un diseño, se debe restringir el campo de acción del sistema, definir los recursos necesarios y las limitaciones o lineamientos, se enfoca en la descripción de lo que debe de hacer, dejando a la etapa de implementación el cómo se debe hacer.

3.2.1 Dominio de acción. Las capacidades del sistema están fundamentadas en los siguientes elementos:

• Obtención de una huella digital del sistema de archivos de un equipo de cómputo en producción.

• Traslado seguro de la información obtenida en el cliente hacia el servidor.

• Almacenamiento de la huella digital en un equipo servidor.

Capitulo 3. Análisis y diseño del sistema.

46

• Crear en el servidor una estructura de directorios que sirva como base fiable

para los análisis posteriores.

• Generación de informes de cambios en la huella digital del sistema obtenida en el análisis del equipo de cómputo en producción.

• Actualización de los cambios permitidos de la estructura de archivos del equipo de cómputo en producción.

Esta breve descripción permite bosquejar el comportamiento global del sistema, se enfatiza el análisis de aspectos imprescindibles, algunos como son: la integridad de la información, el medio de comunicación entre equipos de cómputo, los protocolos utilizados para realizar la transferencia de información, la seguridad de la información, los mecanismos de búsquedas de diferencias y la actualización de las posibles modificaciones permitidas. Integridad- Utilizar técnicas criptográficas existentes para la obtención y validación de la integridad de información electrónica. Se puede hacer uso de herramientas propias del sistema operativo. Medio de comunicación- Se debe de contar con un medio de comunicación que permita el intercambio de información entre los equipos de cómputo. Este canal debe de implementar un estándar comercial para garantizar la conectividad del sistema. Las redes de comunicación actuales utilizan una topología basada en el modelo OSI; el alcance del sistema debe ser una red de área local (LAN), utilizando la pila de protocolos TCP/IP. De acuerdo al tipo de red que se tenga, el sistema deberá ser adaptable, tendrá la capacidad de trabajar en una red interna, con direcciones privadas y fijas. Los ambientes donde se manejan asignación de direcciones de red de manera dinámica no serán aplicables para esta herramienta. La capacidad del sistema debe estar limitada por el número de direcciones IP disponibles en el segmento de red que se utiliza. Este entorno debe permitir la comunicación de los equipos hacia internet. Políticas de seguridad- Las políticas son el conjunto de reglas que se establecen para llevar a cabo un esquema de seguridad, estas reglas son aplicables a diferentes niveles del sistema. Se deben diseñar políticas propias de cada entorno, pero es indispensable para nuestro desarrollo crear un conjunto de reglas bien definido, basado en los principales materiales de seguridad informática expuestos como referencia en este trabajo. Se recomienda crear una política restrictiva y adecuarla con base a las características de los usuarios del equipo de cómputo. Privacidad y autenticación- El sistema operativo Linux cumple con estos dos niveles por construcción, el acceso a la red no establece un esquema que cubra estos aspectos, por lo tanto, se debe implementar un esquema que garantice el cumplimiento de autenticar a los involucrados en una comunicación de red y la privacidad de la información que se intercambian. Estaciones de trabajo y servidores- No puede existir una red de comunicaciones sin estaciones de trabajo y servidores, incluso, el servidor se integra como parte de la red. El análisis puede realizarse a cualquiera de las dos clases de equipos sin adecuaciones extra.

Capitulo 3. Análisis y diseño del sistema.

47

Administración centralizada- El análisis e identificación de modificaciones, la administración de los cambios en la estructura, la creación de perfiles y la programación de análisis se realizan de manera centralizada en el servidor de monitoreo.

3.3 Análisis de los requerimientos De acuerdo a las anteriores premisas, consideremos plantear una propuesta del funcionamiento general del sistema, la descripción de los componentes principales y las políticas que se utilizan para detectar las intrusiones:

• Tomando como principio la identificación de intrusos basados en host, se contara con un sensor que recolecte información de un sistema de cómputo individual; con la capacidad de acceder y monitorear directamente los archivos de datos y procesos del sistema usualmente blancos de los ataques.

• Habilitado para soportar una infraestructura de IDS de administración y reportes centralizados, permite a un equipo de cómputo de administración rastrear varios hosts. Implementa la detección de usos indebidos; comparando características especificas de los archivos y su huella digital, con la información almacenada en la base de datos fiable en busca de coincidencias.

• La forma de respuesta del sistema es pasiva; la cual consiste en el envío de información al responsable correspondiente, dejando recaer en él la toma de decisiones; por muy afinados que sean los mecanismos de respuesta automática, hay ocasiones en que un sistema no tiene la capacidad suficiente para tomar una decisión. Las alarmas por pantalla son utilizadas para este propósito, enviando un mensaje dentro de una ventana indicando al administrador una posible intrusión, acompañando al mensaje con información adicional, como: los archivos que has sufrido modificaciones o eliminados, la fecha y hora en que se realizó el análisis, entre otros; el contenido de estas alarmas puede ser configurado, en casos considerados sensibles para el funcionamiento del sistema se cuenta con la opción de enviar un correo electrónico al administrador del sistema.

• Para la generación de reportes y archivado de los documentos de información detallada, se usa un manejador de base de datos, algunas de las ventajas de esta implementación podrían ser: reportes de los eventos del sistema e intrusiones analizados de manera rápida sobre un periodo particular de tiempo, además de proveer estadísticas de los eventos generados por el IDS en formatos apropiados.

• Se utiliza un control centralizado; es decir, la recolección de información de los sensores, detección y los reportes son administrados directamente desde una ubicación central y está basado en intervalos de tiempo (Modo Batch); donde, el flujo de información desde los sensores al motor de análisis no es continuo; la información se maneja en esquemas de comunicación de almacenamiento y envió. En la figura 3.1 se presenta el esquema descrito anteriormente.

• En una analogía con un sistema de seguridad basado en cámaras: Se colocaran sensores (cámaras fotográficas) para tomar instantáneas de directorios previamente seleccionados del sistema de archivos de un equipo.

Capitulo 3. Análisis y diseño del sistema.

48

La primera imagen adquirida por el sensor será enviada al servidor y servirá para crear la estructura de directorios, será considerada la base fiable. En un tiempo posterior, el servidor solicitara al sensor capturar una imagen del equipo cliente y enviarle esta información, el servidor recibe la nueva imagen, compara ambas imágenes (la almacenada fiable y la actual) y busca modificaciones, en caso de encontrarlas, genera el archivo de reporte con las incidencias detectadas.

CLIENTE CLIENTE CLIENTE CLIENTE CLIENTE

SERVIDORConsolaComandos

Respuesta

BDANALISIS

Almacenamiento

Figura 3.1. Esquema general del sistema.

3.4 Arquitectura general del sistema. EL sistema de detección de intrusos basado en políticas de seguridad tiene esta arquitectura:

• Las reglas de acceso y los mecanismos para especificarlas.

• Los mecanismos de supervisión de archivos modificados

• Las acciones correspondientes para el manejo de archivos modificados.

• Generación de reportes

• Actualización de modificaciones no permitidas en el servidor 1.- Las Políticas de seguridad. Pueden implementarse políticas de seguridad definiendo reglas, por mencionar algunas, se pueden establecer reglas para supervisar los accesos al sistema, los

Capitulo 3. Análisis y diseño del sistema.

49

permisos con los que se accede, etc. Las reglas de acceso especifican qué partes serán supervisadas y qué tipos de acceso constituyen una violación; estas reglas se establecen como una mascara de selección para el usuario o los grupos que usan el recurso. Son diseñadas por el administrador del sistema y almacenadas en el directorio del servidor de monitoreo. Se determinan los lineamientos para formar políticas en el capitulo siguiente en base a los esquemas de seguridad [17][18][21] y al propuesto por Tripwire [12]. Estos lineamientos pueden ser ajustados a los requerimientos de cada entorno donde se implemente y los servicios que proporciona. En la tabla 3.1 Se define un nivel de riesgo para considerar la importancia de los contenidos de los directorios o archivos para el funcionamiento general del sistema. Nivel de riesgo Características de los elementos Alto (High) • Archivos ejecutables

• Archivos ejecutables SUID o GUID.

• Directorio del administrador del sistema (/root)

• Directorio de archivos de inicio y nucleo (/boot)

• Directorio de aplicaciones del sistema operativo solo utilizables por el administrador (/bin)

• Directorio de librerías utilizadas por las aplicaciones del sistema operativo, solo utilizables por el administrador (/lib)

• Directorio de configuración de usuarios, contraseñas, servicios, código fuente de aplicaciones, administrador de paquetes (/etc)

• Directorio de archivos y aplicaciones disponibles sin permiso de escritura para lo usuarios no administradores de Linux (/usr)

Medio (Medium) • Directorios de esquemas de dispositivos utilizables (/dev)

• Directorio de montaje de dispositivos de intercambio de información (/media)

• Directorio de aplicaciones del sistema con permiso de ejecución para los usuarios no administradores de Linux

Bajo (Low) • Directorio de elementos variables , almacena bitácoras y publicaciones del servidor web(/var)

• Directorio de usuarios no administradores de Linux (/home)

• Directorio virtual de ejecución de procesos y estado del sistema (/proc)

Tabla 3.1. Nivel de riesgo de directorios en el sistema operativo Linux. Esta clasificación está basada en los aspectos de significantes de la seguridad y el impacto que representan las intrusiones en estos directorios. El nivel Alto esta formado por elementos críticos que representan puntos de vulnerabilidad muy importantes, el nivel Medio se forma de elementos que no son críticos, pero son significativos para la seguridad del sistema, por ultimo, el nivel bajo esta formado por los elementos que representan un impacto mínimo en la seguridad del sistema. Cabe destacar que esta clasificación esta basada en las especificaciones estándar de Tripwire [12], existen diferencias en la composición de los elementos y niveles debido a que en este desarrollo se pretende analizar directorios completos y Tripwire [12] esta orientado al análisis de archivos específicos.

Capitulo 3. Análisis y diseño del sistema.

50

El directorio /proc es un elemento virtual que define el estado del sistema, es un directorio dinámico que no será analizado en este desarrollo debido a la conceptualización del tiempo de análisis propuesto en esta metodología. El entorno de realizar análisis en tiempos establecidos y no en tiempo real limitan la aplicación de este directorio. Las políticas también deberán introducir el concepto de escalamiento de permisos, por lo tanto se consideran imprescindibles mecanismos de identificación de permisos con los que cuenta el directorio y la detección de modificaciones no deseadas en éste sentido. Se deben considerar los propietarios y los grupos a los que pertenecen los archivos analizados, sobre todo los del superusuario (root) por tener privilegios administrativos dentro del entorno Linux. En la tabla 3.2 se muestra el esquema determinado para la formulación de políticas que validen los permisos de los archivos.

Permisos Propietario y grupos SUID, GUID 1 bit

Permisos usuario 3 bits

Permisos grupo 3 bits

Permisos otros 3 bits

Propietario archivo

Grupo del propietario

Tabla 3.2. Parámetros de validación de permisos de los archivos. Los archivos dentro de Linux pueden ser invocados desde otro lugar o con otro nombre siempre que existan simbólicamente enlaces, esto podría suponer un riesgo cuando se realizan a elementos fundamentales del sistema como son todas las aplicaciones propias de root. Se añaden a la lista de lineamientos un referente del número de enlaces simbólicos que posee cada archivo al momento de verificar sus propiedades. Por ultimo, el tamaño de un archivo perteneciente a un nivel de riesgo Alto puede determinar una intrusión, debido a que la modificación supondría la inserción de código malicioso [9]. Estos lineamientos suponen el control de las propiedades de un archivo dentro del esquema del sistema operativo Linux, estos no son suficientes y se debe realizar la validación del contenido de cada archivo con la implementación de algún algoritmo criptográfico que determine la integridad de los datos. La tabla 3.3 muestra el esquema que tendrán las políticas de las propiedades para cada uno de los archivos analizados y la tabla 3.4 muestra el esquema de las políticas de integridad.

Política propiedades de archivo Enlaces Nombre Permisos Propietario

y grupos Tamaño

Tabla 3.3. Política de propiedades de archivo.

Política integridad de archivo Nombre Resumen criptográfico (huella digital)

Tabla 3.4. Política integridad de archivo. 2.- El comprobador de integridad. La idea principal es usar copias de diferentes instantes de tiempo del sistema de almacenamiento para descubrir los cambios no deseados en el sistema. Se propone

Capitulo 3. Análisis y diseño del sistema.

51

tener una huella digital realizada por resumen que se almacena en directorios y usar esta información para limitar el análisis a un número pequeño de directorios. Estos datos serán comparados con los almacenados en el directorio correspondiente; obteniendo las diferencias. Si existen, se genera un archivo con los elementos modificados y se almacena en el directorio correspondiente. 3.- Las acciones del sistema. Siempre que una intrusión se descubre, se debe actualizar los cambios registrados en la base de datos. 4.- Generación de reportes. El servidor de monitoreo deberá presentar el estado de los equipos analizados en una interfaz fácil de entender, se podrá solicitar la generación de un archivo de reporte para imprimir la información y contar con evidencia de las intrusiones. Este tipo de documentos permiten conocer el nivel de seguridad que guarda cada equipo y en cierto grado, la seguridad que presenta la red. 5.-Actualización de modificaciones permitidas en el servidor. Si las modificaciones que se presentan no son autorizadas por el administrador, este podrá aislar al sistema, realizar los análisis correspondientes y restaurar el funcionamiento del sistema. Resuelto el problema de la intrusión, se puede solicitar al administrador la restauración del sistema de archivos al último punto fiable conocido; transfiriendo al equipo cliente los datos almacenados como respaldos. Se recomienda construir el directorio de cada cliente inmediatamente después de que su sistema ha sido instalado y actualizado.

3.4.1 Capas de diseño. La construcción de un modelo engloba aspectos que pueden ser separados para facilitar su comprensión y diseño, a continuación se describen los elementos y las capas en que se agruparon: Presentación. El servidor de monitoreo tendrá 2 tipos de comunicación con el administrador. La primera es mediante consola de comandos, la cual permite realizar movimientos, actualizaciones y generación de perfil de usuario. La segunda consiste en una interfaz gráfica de usuario para la actualización y generación de reportes, diseñada para un navegador web, esta basada en el protocolo http. Lógica de aplicación. En esta se definen los objetos que representan funciones de los requisitos de aplicación:

a) Estructura de directorios

b) Integridad de los archivos

c) Permisos de archivos

d) Canal de comunicación

Capitulo 3. Análisis y diseño del sistema.

52

e) Seguridad de la información

f) Motor de búsqueda de diferencias

g) Motor de reportes

h) Interfaz con el sistema de archivos

i) Interfaz con el sistema generador de políticas

j) Interfaz con el sistema generador de reportes

k) Interfaz con el sistema de actualizaciones

Almacenamiento. Se decide tener una estructura de directorios con archivos en texto plano para la etapa de integridad y base de datos fiable. Considerando los aspectos de velocidad y el volumen de almacenamiento. Para el sistema de reporte de cambios se hace uso de un gestor de base de datos el cual permite actualizar los cambios realizados en el sistema en un corto tiempo y generar el estado de los equipos.

3.4.2 Tiempos de respuesta y de análisis. El uso de herramientas de procesamiento electrónico de información reducen notoriamente el tiempo en que se realiza una tarea, la identificación de un cambio en la estructura del sistema podría tardarse horas si no se usa una herramienta como esta. Se considera que el análisis dependerá directamente del volumen de información y el tráfico de la red. El tiempo de respuesta ante un incidente de intrusión baja considerablemente, llegando a ser responsabilidad del administrador el aprovechamiento de la información entregada por el sistema.

3.4.3 Uso de recursos. Los recursos de un equipo de cómputo son muy valiosos, lo anterior, tiene un peso mayor cuando se habla de servidores de aplicación; se analizará el rendimiento del equipo cuando la herramienta de auditoria se está ejecutando. El tráfico en la red es otro aspecto importante a considerar. Las políticas de seguridad bien diseñadas permitirían un desempeño mayor, esto se traduce en programar los análisis cuando los equipos presenten menos carga de trabajo.

3.4.4 Plataformas. Este desarrollo está diseñado para atender una problemática del sistema operativo Linux, en sus distribuciones derivadas de Debían principalmente, derivado de que la estructura que maneja su directorio de archivos es idéntica, la portabilidad a otra distribución dependería de la estructura que manejen y la disposición de sus archivos de configuración.

Capitulo 3. Análisis y diseño del sistema.

53

3.5 Descripción de los procesos.

Una técnica muy útil para determinar el diseño de un sistema es definir los procesos principales que lo componen, haciendo uso de técnicas para el modelado, en la tabla 3.5 se presentan los casos de uso considerados como esenciales.

La funcionalidad nos servirá para dividir el sistema en elementos importantes, las piezas deben mantener un equilibrio entre la colaboración con las demás y una independencia de su funcionamiento. Se recurre en este punto a bosquejar los elementos que interactúan, con el objetivo de establecer la relación de comunicación o dependencia entre ellos. Los siguientes casos de uso describen de manera abstracta para el sistema los participantes y las acciones que realizan.

REFERENCIA FUNCIÓN CATEGORIA

R1.1 El sistema realiza un análisis de la integridad de archivos para un equipo

Evidente

R1.2 El sistema realiza una prueba de disponibilidad del equipo en la red LAN

Oculto

R1.3 El sistema permite diseñar un archivo de políticas para el análisis del equipo

Evidente

R1.4 El sistema utiliza un módulo para realizar la conexión segura entre el cliente y el servidor de monitoreo

Oculta

R1.5 El sistema implementa un módulo para garantizar la autenticación del cliente frente al servidor de monitoreo

Oculta

R1.6 El sistema implementa un módulo para realizar el análisis de integridad de los archivos del sistema del cliente

Oculta

R1.7 El sistema implementa un módulo de búsqueda de modificaciones del análisis del cliente

Oculta

R1.8 El sistema contiene un módulo para actualizar el estado del sistema y los cambios generados en la base de datos.

Oculto

R1.9 El sistema contiene una interfaz de despliegue de resultados para el administrador

Evidente

R1.10 El sistema contiene un módulo de edición y actualización del estado del equipo

Evidente

Tabla 3.5. Procesos principales del IDS propuesto.

CASO DE USO Crear perfil del cliente Tipo Primario Descripción El administrador abre la aplicación y diseña políticas

para el análisis del sistema cliente El sistema registra los parámetros El sistema almacena los perfiles de usuario y deja listo para el análisis

Tabla 3.6. Crear perfil del cliente.

Capitulo 3. Análisis y diseño del sistema.

54

CASO DE USO Instalar perfil de cliente Tipo Primario Descripción El administrador mueve el archivo perfil de usuario al

directorio correspondiente El sistema abre el archivo y lee los parámetros El sistema ejecuta un análisis para generar la arquitectura de almacenamiento del cliente

Tabla 3.7. Instalar perfil del cliente.

CASO DE USO Programación de ejecución Tipo Primario Descripción El administrador programa el intervalo de tiempo en

que se ejecutaran los análisis del sistema El sistema almacena los cambios de los periodos de ejecución y deja listo para efectuarlos

Tabla 3.8. Programación de ejecución.

CASO DE USO Establecer método de autenticación Tipo Primario Descripción El administrador determina el método de

autenticación del sistema cliente El sistema almacena los elementos necesarios para la autenticación y deja listo para efectuarlos

Tabla 3.9. Establecer método de autenticación.

CASO DE USO Establecer método de conexión Tipo Primario Descripción El cliente solicita una conexión al servidor

El servidor solicita autenticación El cliente se autentica de manera correcta El servidor establece un canal de comunicación segura Tabla 3.10. Establecer método de conexión.

CASO DE USO Establecer estructura de análisis Tipo Primario Descripción Se debe establecer el procedimiento para efectuar el

almacenamiento de el análisis del sistema cliente El sistema servidor almacena la información del análisis realizado al cliente Tabla 3.11. Establecer estructura de análisis.

CASO DE USO Establecer métodos de análisis de integridad Tipo Primario Descripción El cliente aplica técnicas compendio a la estructura de

sus archivos El servidor busca diferencias entre su base fiable y el análisis realizado al cliente

Tabla 3.12. Establecer métodos de análisis de integridad.

Capitulo 3. Análisis y diseño del sistema.

55

CASO DE USO Establecer métodos de impresión de los reportes de

análisis Tipo Primario Descripción El usuario solicita al servidor el informe de estado de

un cliente El servidor consulta la base de datos y muestra los resultados El usuario solicita la generación de un archivo en formato de impresión El servidor genera el archivo en formato electrónico.

Tabla 3.13. Establecer métodos de impresión de reportes de análisis.

CASO DE USO Mostrar estado del cliente Tipo Primario Descripción El administrador solicita el estado de un cliente

El servidor despliega el estado del cliente El administrador realiza las consultas de elementos detallados correspondientes. El servidor muestra los informes detallados de los elementos detectados como intrusos

Tabla 3.14. Mostar estado del cliente.

3.6 Modelo funcional. El resultado de este análisis de procedimientos y comunicaciones, produce un esquema del sistema en su nivel más alto, en el cual se pueden distinguir los elementos de software implicados sin especificar su relación.

Figura 3.2. Modelo funcional.

La figura 3.2 muestra los subsistemas que permiten el funcionamiento de la aplicación de monitoreo, almacenamiento, comparación y generación de reportes.

A. Conexión segura B. Análisis de sistema C. Búsqueda de cambios D. Base de datos modificaciones E. Impresión de informes F. Generación de perfil de usuario G. Actualización de cambios H. Sistema de respaldos

Capitulo 3. Análisis y diseño del sistema.

56

Las relaciones entre ellos permiten agruparlos en tres bloques que funcionalmente son enlazados. Para incrementar el nivel de especificación de cada módulo, será importante considerar la figura 3.3, un diagrama que representa la funcionalidad definida en cuatro grandes bloques: el establecimiento de una conexión segura, el análisis de integridad del equipo cliente, un sistema motor de búsquedas de cambios y un generador de informes y reportes impresos.

Figura 3.3. Diagrama de estados

A continuación se describen los subsistemas basándose en los casos de uso y la relación de comunicación y dependencia funcional, utilizando como base los casos de uso y los diagramas de estado. A) Conexión segura. Objetivo: Permitir la comunicación del sistema cliente y el servidor de monitoreo. La tabla 3.15 describe las acciones y respuestas del sistema para establecer la conexión.

Acción Respuesta del sistema

1. Este caso comienza cuando el servidor de monitoreo desea realizar una ejecución de análisis

2.El sistema realiza una prueba de disponibilidad del equipo en la red LAN

3. El servidor de monitoreo solicita una conexión de datos segura

4. El sistema implementa un módulo para garantizar la autenticación del cliente frente al servidor de monitoreo El sistema utiliza un módulo para realizar la conexión segura entre el cliente y el servidor de monitoreo.

5. El servidor de monitoreo puede ejecutar las siguientes acciones:

• Análisis de sistema

• Respaldo de cliente

• Ejecución de comandos

• Cambio de configuración del cliente

6. El sistema ejecuta las acciones seleccionada en el cliente y cierra el canal de comunicación al finalizar

Tabla 3.15. Descripción de Conexión segura.

Capitulo 3. Análisis y diseño del sistema.

57

Figura 3.4. Gráfico de Estados de Conexión Segura.

SISTEMA DE

RESPALDOS

ANALISIS DE

SISTEMA

CLIENTE

ENVIARPETICIÓN

ACEPTARPETICIÓN

ENVIARAUTENTICACIÓN

VALIDARAUTENTICACIÓN

SOLICITARCANAL SEGURO

[CORRECTO]

ABRIRCANAL SEGURO

BUSCARARCHIVOPOLITICA

EJECUTARRESPALDO

EJECUTARANALISIS

DESCRITO EN

"ANALISIS DEL SISTEMA"

DESCRITO EN

"ANALISIS DEL SISTEMA"

SOLICITARCERRARCANAL

CERRARCANAL

RECIBIRNOTIFICACIÓN

CANALCERRADO

SERVIDOR

AUDITORIA

Figura 3.5. Diagrama de actividades del sistema Conexión Segura.

ENVIAR PETICIÓN DECONEXION

ESTABLECERCONEXIÓN

AUTENTICARCLIENTE

LLAVE VALIDAUSUARIO AUTORIZADO

CERRAR CONEXIÓN

CONECTARCANAL SEGURO

[CORRECTA]

ENVIAR ARCHIVOS

RECIBIRARCHIVOS

EJECUTARCOMANDOREMOTO

CAMBIARCONFIGURACIÓN

DESCONECTARCANAL SEGURO

Capitulo 3. Análisis y diseño del sistema.

58

La Figura 3.4 muestra el grafico de estados del proceso comunicación segura, la Figura 3.5 describe el diagrama de actividades y las entidades involucradas en el proceso. Esta parte del sistema no será generada, se deberá hacer uso de elementos que brinden la seguridad de una comunicación de tipo cliente- servidor con los principios de autentificación, integridad y confidencialidad de los datos transmitidos (ver Tabla 3.9). Los procedimientos de conexión entre ambas entidades deberán realizarse de manera automatizada y garantizar un canal de comunicación seguro (ver Tabla 3.10). B) Análisis de sistema cliente. Objetivo: El sistema realiza el análisis de integridad de los archivos del sistema del cliente y lo almacena en el servidor (ver Tabla 3.17).

Acción Respuesta del sistema 1. Este caso comienza cuando el servidor inicia un análisis del cliente 2. El servidor de monitoreo solicita analizar un directorio de acuerdo al archivo de políticas del cliente.

3. El cliente analiza con una herramienta de búsqueda los directorios requeridos por el servidor.

6. El servidor almacena los datos recibidos en la estructura del cliente.

4. El cliente aplica técnicas compendio a la estructura de sus archivos. 5.-El cliente envía la información recolectada al servidor.

7. El análisis termina cuando se ha obtenido el último directorio especificado en la política de seguridad del cliente.

8. El servidor cierra el archivo de políticas del cliente.

Tabla 3.17. Descripción análisis del cliente. Este punto del sistema representa el sensor del IDS, por lo tanto, se encargara de iniciar su labor cuando el servidor lo indique, todos los parámetros de análisis le serán enviados de manera secuencial, realiza los análisis sobre los directorios del cliente y entrega la información obtenida al servidor (ver Figura 3.6).La herramienta de búsqueda no se programara, se considera implementar métodos propios del sistema operativo.

CONSULTARPERFIL DEUSUARIO

REALIZARANÁLISIS

ALMACENARINFORMACIÓNEN SERVIDOR

CERRARPERFIL DE USUARIO

TRANSFERIRINFORMACIÓNDEL CLIENTEA SERVIDORi

Figura 3.6. Gráfico de Estados de Análisis de sistema.

Capitulo 3. Análisis y diseño del sistema.

59

El proceso inicia cuando el servidor abre el archivo de políticas del cliente, lee de manera secuencial las órdenes de análisis que deberá ejecutar el sensor y espera la respuesta de este, almacenando la información en un archivo temporal. La confirmación del estado correcto del sensor se realiza transfiriendo las aplicaciones que realizaran la operación al servidor y comprobando su integridad (ver Figura 3.7).

CLIENTE

BUSCARDIRECTORIODEL CLIENTE

BUSCAR

ARCHIVO DEPOLITICAS

SOLICITARARCHIVOS

DE INTEGRIDAD

ENVIARARCHIVOS DE

INTEGRIDAD

COPIARARCHIVOS

VALIDARINTEGRIDAD

BUSCARARCHIVOPOLITICA

OBTENIDO DE

"GENERACION DE

PERFIL DE

USUARIO"

ESCRIBIRRIESGO

EN REPORTE

ANALIZAR

ESTRUCTURADE DIRECTORIO

GENERAR

FUNCIÓNCOMPENDIO DE LOS ARCHIVOS

SERVIDOR MONITOREO

[CORRECTOS]

ENVIARESTRUCTURA

Y COMPENDIOS

DE ARCHIVOS

GUARDAR EN EL DIRECTORIO

DEL CLIENTE

CERRARARCHIVO DEPOLITICAS

Figura 3.7. Diagrama de actividades del sistema Análisis.

Capitulo 3. Análisis y diseño del sistema.

60

C) Búsqueda de cambios. Objetivo: El sistema implementa un módulo de búsqueda de modificaciones del análisis del cliente, el cual busca diferencias entre su base fiable y el análisis realizado al cliente. La Tabla 3.18 describe la acción que se realiza y la respuesta obtenida del sistema para este proceso.

Acción Respuesta del sistema 1. Este caso se inicia de manera inmediata cuando se termino el análisis de directorio del cliente.

2.El sistema realiza una búsqueda de la estructura del directorio del cliente en el servidor

3. El servidor de monitoreo abre el directorio que obtuvo del análisis

4. El sistema compara directamente archivo del servidor de monitoreo y del cliente en busca de modificaciones 5. Las diferencias encontradas entre los archivos son enviadas a un archivo de reporte. El grado de riesgo que esta modificación representa debe estar categorizado en distintos niveles (ver Tabla 3.1).

6.El servidor de almacena el archivo de reporte obtenido en el directorio del cliente

7. El caso termina cuando el sistema cierra el directorio del cliente y deja listo para actualizar el estado del cliente

Tabla 3.18. Descripción de búsqueda de cambios. Este proceso se realiza tomando como elemento el proceso anterior, en el cual el sensor entrega un reporte al servidor. El servidor localiza el directorio del cliente y extrae el contenido de los directorios correspondientes a la base fiable, compara estos elementos con los entregados por el sensor y genera un reporte de incidencias, describiendo los elementos que difieren, sus parámetros de configuración de archivo (ver Tabla 3.3) y su comprobación de integridad (ver Tabla 3.4). La Figura 3.8 describe los estados de este procedimiento.

BUSCARDIRECTORIO

CLIENTE

BUSCARDIRECTORIO

ANÁLISIS

ANALIZARDIRECTORIO

CLIENTE-ANÁLISIS

ACTUALIZARREPORTES

CLIENTE

Figura 3.8. Gráfico de estados de Búsqueda de cambios.

Capitulo 3. Análisis y diseño del sistema.

61

La Figura 3.9 detalla las actividades que se realizan durante la búsqueda de cambios, los involucrados durante este proceso son el servidor y el motor de base de datos. El servidor realiza el procedimiento de comparación de los archivos y la generación de reporte de elementos, mientras que la base de datos se encargara de registrar la fecha de análisis y el resumen de los elementos entregados por el reporte del servidor. Si existen modificaciones a la estructura, estas serán reportadas y se adoptara la nueva base de datos como elemento fiable (política permisiva), el anterior esquema de referencia será desplazado y renombrado con la fecha del análisis. En este punto, el servidor puede enviar las alarmas correspondientes en base al reporte emitido.

Figura 3.9. Diagrama de actividades del sistema Análisis.

Capitulo 3. Análisis y diseño del sistema.

62

D) Base de datos modificaciones Objetivo: El sistema contiene un módulo para actualizar el estado del sistema considerando los elementos encontrados en el reporte del análisis, posteriormente, actualiza los elementos generados en la base de datos. La Tabla 3.19 describe las acciones que se realizan en este proceso y la respuesta del sistema.

Acción Respuesta del sistema 1. Se inicia cuando se ha terminado la búsqueda de cambios. El sistema de monitoreo abre el archivo de reporte de diferencias.

2.El sistema obtiene todos los elementos modificados y el riego que representan

3. El servidor de monitoreo establece la conexión con el servidor web

4. El sistema compara directamente archivo del servidor de monitoreo y del cliente en busca de modificaciones

4. El servidor web establece la conexión con la base de datos

5. El sistema de base de daros almacena los cambios en el cliente correspondiente El sistema calcula el nivel de riesgo del cliente y actualiza la fecha de análisis del equipo. Se cierra la conexión con la base de datos.

6. El servidor de auditoría actualiza el archivo de reporte.

7. El sistema determina el estado dependiendo del número de elementos afectados y el riesgo de cada uno de acuerdo a la política previamente diseñada

Tabla 3.19. Descripción de base de datos de modificaciones. Este proceso involucra la lectura detallada del reporte almacenado en el directorio del cliente, permite determinar la naturaleza de los elementos identificados y la inclusión de estos dentro de la base de datos de modificaciones (ver Figura 3.10).

BUSCARDIRECTORIODEL CLIENTE

ANALIZARREPORTE

GUARDARCAMBIOS

ADMINISTRADOR

MODIFICAR ARCHIVOS

ACTUALIZARESTADO

DEL CLIENTE

Figura 3.10. Gráfico de estados de Base de datos modificaciones.

Capitulo 3. Análisis y diseño del sistema.

63

Las actividades detectadas sobre el sistema de archivos se restringen en la agregación, eliminación y modificación de alguno de los parámetros de los archivos. Dependiente del número de elementos y el riesgo que representan para la seguridad se determinara la fiabilidad del sistema (ver Figura 3.11). El estado del sistema será definido en base al riesgo que pudieran presentar las intrusiones detectadas. Considerando los siguientes niveles:

• Fiable- Se han detectado elementos de nivel de riesgo bajo.

• Fiabilidad media. Se han detectado elementos de nivel de riesgo medio y de nivel de riesgo bajo.

• Fiabilidad baja. Se han detectado elementos de nivel de riesgo medio y de riesgo bajo, el número total de estos elementos es considerable y requiere atención.

• No fiable. Se ha detectado un elemento de riesgo alto.

Figura 3.11. Diagrama de actividades del sistema Base de datos modificaciones.

Capitulo 3. Análisis y diseño del sistema.

64

E) Impresión de informes. Objetivo: Diseñar una interfaz de usuario que permita el despliegue de resultados del análisis para el administrador y generar un reporte del cliente en formato impreso. La Tabla 3.20 describe las acciones y las respuestas del sistema durante este proceso.

Acción Respuesta del sistema 1. Este caso comienza cuando el administrador solicita un reporte de estado del cliente

2. El sistema busca la información del directorio del clientes

5. El administrador solicita un informe impreso

3. El sistema conecta el servidor web y la base de datos, consulta los datos del cliente. El sistema entrega los datos utilizando la interfaz grafica de usuario. El servidor web genera el archivo en formato electrónico portable (pdf) y lo almacena en la estructura de directorio del cliente.

4. El servidor de monitoreo cierra el archivo de políticas del cliente

7. Termina cuando se ha finalizado la creación del reporte

Tabla 3.20. Descripción de impresión de informes. La generación de reportes consiste en la presentación de los datos de los análisis en un formato fácil de entender, organizado de manera tal que presente un elemento de consulta y respuesta. La aplicación debe ejecutarse directamente sobre un navegador web y utilizando las prestaciones de la base de datos, constituye la interfaz grafica de usuario donde los reportes desplegados por pantalla serán trasladados a un documento electrónico para su posterior impresión (ver Figura 3.12).

Figura 3.12. Gráfico de Estados de Impresión de Informes.

Capitulo 3. Análisis y diseño del sistema.

65

Los elementos involucrados en este proceso son varios, el gestor de base de datos solo será configurado para que se puedan extraer los valores seleccionados por el administrador. La plataforma de consulta esta basada en un servidor de páginas web y el administrador debe interactuar con este elemento por medio de un navegador. La Figura 3.13 detalla las actividades del sistema de generación de informes. Se diseñan solo las consultas que permitan la representación de la información en lenguaje html. La impresión de los informes se puede realizar directamente desde el navegador o la generación de un documento electrónicamente portable.

BASE DE DATOSADMINISTRADOR

INICIANAVEGADOR

INICIAAPLICACIÓNREPORTES

SELECCIONACLIENTE

ENVÍAFORMULARIO

SOLICITAINFORMACIÓNDEL CLIENTE

[EXISTE]

BUSCAREGISTROCLIENTE

ENVÍAINFORMACIÓNDEL CLIENTE

ACTUALIZADIRECTORIODEL CLIENTE

DESPLIEGAINFORMACIÓNDEL CLIENTE

SELECCIONAFORMATOIMPRESO

CREAARCHIVOIMPRESO

ALMACENAREPORTEIMPRESO

DESPLIEGAINFORMACIÓN

NO DISPONIBLE

SERVIDOR WEB

[DISPONIBLE]

SERVIDOR MONITOREO

Figura 3.13. Diagrama de actividades del sistema Impresión de Informes.

Capitulo 3. Análisis y diseño del sistema.

66

F) Generación de perfil de usuario. Objetivo: Diseñar un archivo de políticas para el análisis del sistema cliente, en base a las aplicaciones y los requerimientos o servicios del sistema. Programar el intervalo de análisis y la opción del sistema de respaldos. La Tabla 3.21 describe las acciones correspondientes a este proceso y las respuestas del sistema.

Acción Respuesta del sistema 1. Este caso comienza cuando el administrador solicita el análisis de un equipo, el cual no cuenta con un archivo de políticas de seguridad dentro del sistema de monitoreo El administrador abre la aplicación en una terminal de comandos

2. El sistema presenta una interfaz de tipo comando y abre un archivo predefinido de políticas

3. El administrador diseña políticas para el análisis del sistema cliente. Seleccionando aspectos como: Ip del equipo cliente Directorios supervisados Nivel de riesgo de los directorios Supervisión de programas instalados Estructura de directorios de monitoreo Sistema de respaldo de directorios

4 .El sistema almacena los perfiles de usuario y deja listo para el análisis

4. El administrador mueve el archivo perfil de usuario al directorio correspondiente a las políticas del servidor de monitoreo. Programa los intervalos de ejecución del análisis.

7. El sistema abre el archivo y lee los parámetros El sistema ejecuta un análisis para generar la arquitectura de almacenamiento del cliente. Termina cuando se ha finalizado la creación del reporte.

Tabla 3.21. Descripción de generación de perfil de usuario.

El diseño de políticas requiere conocimiento del entorno y múltiples aspectos de seguridad, para facilitar el trabajo de diseño se cuenta con un archivo previamente definido en el cual solo deberán activarse las líneas correspondientes a los requerimientos. La Figura 3.14 muestra los estados de generación de perfil de usuario.

Figura 3.14.Gráfico de Estados de Generación de perfil de usuarios

Capitulo 3. Análisis y diseño del sistema.

67

La Figura 3.15 muestra los elementos involucrados en este proceso y su interrelación, cabe destacar que en este punto se deben definir los parámetros que sirvan de base de conocimiento. Este archivo de políticas será ejecutado por el sensor del IDS en el equipo cliente, la información entregada por este servirá para construir el árbol de directorios en el servidor. El archivo de políticas de usuario deberá contener parámetros de configuración básicos como:

• Dirección IP del cliente

• Ruta donde se creara la estructura de directorios

• Reglas de análisis de directorios del cliente (Ordenadas de acuerdo al riesgo ver Tabla 3.9)

• Reglas de utilitarios

• Líneas de actualización de reportes y base de datos Los posteriores análisis serán utilizando la misma política generada para el cliente y podrán agregarse o suprimirse funcionalidades.

Figura 3.15. Diagrama de actividades del sistema Impresión de Informes.

Capitulo 3. Análisis y diseño del sistema.

68

G) Administración y actualización de cambios. Objetivo: Implementar un módulo de edición y actualización del estado del sistema cliente. Actualizar las base de datos analizando la información del estado del cliente. La Tabla 3.22 describe las acciones y respuestas del sistema durante este proceso.

Acción Respuesta del sistema 1. Este caso de uso inicia cuando el administrador solicita editar el estado de un cliente. Abre la aplicación web y solicita la acción de actualización de estado del cliente.

2. El servidor presenta una interfaz de tipo WEB, consistente en un formulario.

3. El administrador realiza los cambios De conformidad a la lectura de el tipo de archivo y su riesgo. Determina permitir o negar la modificación detectada

4 .El sistema almacena los perfiles de usuario. Actualiza la base de datos y el directorio del cliente. Determina el nuevo estado del cliente y deja listo para el reporte.

5. El sistema termina cerrando la interfaz de actualización.

Tabla 3.22. Descripción de administración y actualización de cambios. Existen dos métodos para modificar el estado de un cliente: El primero consiste en la actualización automática debido a la detección de intrusos en el cliente, el archivo de reporte es procesado y actualiza la base de datos, la cual genera un nuevo perfil de consideración a los elementos registrados. El segundo consiste en la modificación por parte del administrador, esta interfaz permite el manejo directo de la información, no será desarrollada en este proyecto, por lo que se emplea un manejador de base de datos que permita la gestión de este elemento utilizando una interfaz web. Este procedimiento debe realizarse después de un análisis de los elementos detectados y la restauración del sistema cliente. La Figura 3.16 muestra los estados de la administración y actualización de cambios de un cliente.

Figura 3.16. Gráfico de Estados de Administración y actualización de cambios.

BUSCARARCHIVO DEREPORTE

ACTUALIZARREPORTES ENBASE DE DATOS

EDITARESTADOCLIENTE

ALMACENARCAMBIOS DEL

CLIENTE

ABRIRARCHIVO

[SIN MODIFICACIONES]

Capitulo 3. Análisis y diseño del sistema.

69

La Figura 3.17 detalla las actividades que se realizan durante la actualización de cambios. Es importante resaltar que la restauración del sistema consiste en resolver los problemas de seguridad detectados y la posterior búsqueda de los elementos dentro de la base de datos para su eliminación. La base de datos deberá ser restaurada hasta antes de la intrusión, proceso que conlleva eliminar el archivo actual de referencia y renombrar el archivo referencia fiable anterior (almacenada en la misma carpeta y renombrada con la fecha del análisis).

Figura 3.17. Diagrama de actividades del sistema administración y actualización de cambios.

SERVIDOR

MONITOREO

BASE DE DATOSSERVIDOR WEBADMINISTRADOR

SOLICITA

ACTUALIZAR

CLIENTE

ACEPTA

PETICIÓN

SELECCIONA

CLIENTE

ENVÍA

FORMULARIO

SOLICITA

INFORMACIÓN

DEL CLIENTE

[EXISTE]

BUSCA

INFORME

DE CAMBIOS

ENVÍA

INFORMACIÓN

DEL CLIENTE

ACTUALIZA

DIRECTORIO

DEL CLIENTE

DESPLIEGA

INFORMACIÓN

DEL CLIENTE

SELECCIONA

CAMBIOSPERMITIDOS

ENVÍAACTUALIZACIÓN

DE CAMBIOS

ACTUALIZAREGISTRO

DEL CLIENTE

[OTRO CLIENTE]

DESPLIEGA

INFORMACIÓN

NO DISPONIBLE

Capitulo 3. Análisis y diseño del sistema.

70

H) Sistema de respaldos Objetivo: El sistema de monitoreo permite realizar respaldos de el sistema cliente, almacena directorios en el servidor. Este elemento no es un elemento de monitoreo estrictamente, pero permite la recuperación de información imprescindible para el cliente. La Tabla 3.23 describe las acciones y respuestas durante este proceso.

Acción Respuesta del sistema 1. Este caso de uso inicia cuando el administrador solicita crear respaldos del cliente. Inicia después de un análisis y debe estar especificada en el archivo de políticas.

2. El servidor recibe estructura de directorios definidos para ser respaldados. Aplica un método de compresión y agrupa la estructura en un archivo único. Envía el archivo de respaldo al servidor de monitoreo

3. El servidor de monitoreo almacena el archivo de respaldo en la estructura del directorio del cliente y le asigna la fecha de creación.

4. El sistema termina cuando el archivo de respaldo ha sido almacenado

Tabla 3.23. Descripción del sistema de respaldos. Este elemento forma parte de los utilitarios que puede implementar el sistema, la Figura 3.18 muestra los estados del sistema de respaldos. Este procedimiento fue considerado en esta etapa por ser un elemento muy importante dentro del aspecto de seguridad [12]. El almacenamiento de copias de respaldo en un medio seguro puede permitir la recuperación de información sensible después de haber sufrido algún ataque o pérdida por errores o fallas de hardware.

Figura 3.18. Gráfico de Estados del sistema Respaldos.

La Figura 3.19 detalla las actividades del sistema de respaldos, el sistema debe de comprimir la información para optimizar el uso de los recursos en el servidor y disminuir el tiempo de transferencia entre equipos. La política de almacenamiento deberá diseñarse sobre elementos de información sensibles o de alta importancia (archivos de configuración). Solo se deben especificar las reglas dentro del archivo de políticas y el IDS deberá emplear las aplicaciones del sistema operativo para ejecutarlas. El sistema de respaldos no es el único utilitario que se puede implementar, se pueden realizar extracción de archivos de configuraciones, análisis de paquetes instalados y la obtención del nombre del host cliente para realizar autenticación de servicios de red.

Capitulo 3. Análisis y diseño del sistema.

71

SERVIDOR AUDITORIA

CLIENTE

BUSCAR AUDITORIA DE RESPALDO

BUSCAR ESTRUCTURADE DIRECTORIO

BASE DE DATOS

COMPRIMIR DIRECTORIO

ENVIAR ARCHIVO DE RESPALDO

ALMACENAR ARCHIVODIRECTORIO CLIENTE

ACTUALIZAR FECHARESPALDO

ACTUALIZAR REGISTRODEL CLIENTE

CERRAR ARCHIVODE POLITICAS

[OTR

O D

IREC

TORIO

]

Figura 3.19. Diagrama de actividades del sistema Respaldos.

La descripción de casos de uso permite determinar el grado de interacción existente entre el sistema y los usuarios, el concepto de la herramienta es utilizar la potencialidad del procesamiento electrónico de datos. Por lo tanto, solo las operaciones de configuración y adecuación del sistema son realizadas por el administrador del sistema, todos los demás casos son aplicados de manera independiente por el sistema.

Figura 3.20. Casos de uso del IDS.

El planteamiento anterior sirve como base para el modelado de los subsistemas, los casos antes mencionados describen el método de acción de cada bloque funcional y su relación. Las restricciones propias de cada elemento serán descritas en la implementación.

Capitulo 3. Análisis y diseño del sistema.

72

CLIENTE SERVIDOR

SENSOR

1

DATOS

CONTROL CENTRALIZADO

2 3

75

89

6

CANAL DE COMUNICACIÓN

SEGURO

DETECCION DE MODIFICACIONES

ALERTA

RESPONSABLE DE SEGURIDAD

REPORTE

REPORTEWEB

BASE DE DATOS

DATOS DE FORENCIA

10

4 BITACORA

Figura 3.21. Arquitectura de la metodología propuesta.

Capitulo 4. Implementación del sistema.

73

CAPÍTULO 4. IMPLEMENTACIÓN DEL SISTEMA. En este capítulo se describe la estructura del directorio de aplicaciones, la generación de la base de datos, los esquemas de seguridad utilizados y las especificaciones de los servidores utilizados.

4.1 Estructura de la aplicación. A partir del nombre de la investigación, se determinó asignar a la herramienta el nombre de DAYUSOL y en lo consiguiente se referirá a esta cuando se hable de la aplicación de la metodología del IDS propuesto. En el desarrollo de DAYUSOL, se implementaron varias herramientas como la conexión segura entre equipos, el servidor de páginas WEB, la base de datos y una interfaz grafica web, por mencionar algunos. El sistema puede ser implementado en diferentes ambientes, de hecho, solo es necesario cubrir los aspectos fundamentales del diseño para conseguir que la herramienta funcione. Cabe destacar que el motor de búsqueda, la actualización de los registros de base de datos fiable y la administración del directorio de aplicaciones, constituyen la esencia de la herramienta planteada en el capitulo anterior, el sistema de respaldos y de la generación de reportes son módulos clasificados como utilitarios, ya que no son indispensables para la detección de intrusiones, pero facilitan la presentación de los datos recabados y proporcionan elementos para la restauración del sistema. Basándose en los tres elementos fundamentales, la construcción del entorno del trabajo no ha sido programada completamente, se hace uso de aplicaciones propias del sistema operativo que se encuentran en paquetes disponibles para la distribución Debian. Se implementa un modelo de IDS de host, utiliza un método de detección de intrusiones basado en una estructura de directorio fiable y una base de datos para realizar el análisis. Su patrón de referencia es la integridad de los archivos del sistema, es asíncrono dependiente de los intervalos de tiempo en que se programan los análisis, el sistema de tiene una estructura centralizada, además, de la capacidad del sistema para analizar varios clientes al mismo tiempo. Se tienen tres sistemas dedicados a tareas específicas, el primero de ellos se ha sido nombrado sistema de integridad, contempla aspectos como la seguridad de los datos, la fiabilidad de la comunicación entre el cliente y el servidor y la integridad de los archivos. El segundo es denominado sistema de reporte de integridad y estadísticas, permite al administrador obtener la información de un cliente de DAYUSOL y basa su funcionamiento en el subsistema anterior, proporciona los resultados de los análisis realizados, de forma tal que se notifican las posibles intrusiones y los riesgos que estas representan. Se utiliza un navegador web en este subsistema, debido principalmente, a la flexibilidad que representa el generar contenido independiente de la plataforma donde será desplegado.

Capitulo 4. Implementación del sistema.

74

Por último, el sistema de respaldo, permite hacer copias de los archivos del cliente en el servidor de monitoreo, este utilitario no es considerado fundamental debido a las limitaciones de almacenamiento, pero bien delimitado, será una herramienta muy importante considerando el costo que representa la pérdida de información.

4.2 Sistema de detección de intrusos DAYUSOL. Esta parte constituye la pieza fundamental del IDS, su implementación se basa en algunos bloques funcionales definidos en el capítulo anterior, los cuales interconectados permiten realizar análisis automatizados. Los bloques funcionales utilizados para el funcionamiento de este sistema son:

• Conexión segura

• Análisis de sistema (sensor)

• Detección de modificaciones

• Base de datos

• Generación de perfil de usuario

• Administración y actualización de cambios

CLIENTE SERVIDOR

SENSOR

1

DATOS

CONTROL CENTRALIZADO

23

75

89

6

CANAL DE

COMUNICACIÓN

SEGURO

DETECCION DE

MODIFICACIONES

ALERTA

RESPONSABLE

DE SEGURIDAD

REPORTE

REPORTE

WEB

BASE DE

DATOSDATOS DE

FORENCIA

10

4 BITACORA

Figura 4.1. Arquitectura de DAYUSOL.

La Figura 4.1 describe la arquitectura de DAYUSOL, la intervención del administrador se hace necesaria en algunas partes del sistema, principalmente en las que se refieren a tareas de decisión sobre los aspectos de configuración y actualización. Transfiriendo al responsable del uso de la herramienta la capacidad de definir el desempeño del esquema de seguridad, haciendo recaer al mismo tiempo la responsabilidad que implica identificar los elementos relevantes de la seguridad de cada equipo y la privacidad de los datos manejados en el servidor.

Capitulo 4. Implementación del sistema.

75

4.2.1. Entorno de red. Se requiere implementar un entorno de red donde se cumpla con las especificaciones IEEE 802.3 y la especificación IEEE 802.11. La implementación de DAYUSOL se realizó en el laboratorio de Redes, utilizando la infraestructura propia del edificio del Centro de Investigación en Computación del IPN con las características mostradas en la Tabla 4.1.

Recurso Implementación Características

Tipo de red Red de área local LAN Especificación IEE 802 Tecnología LAN Ethernet

LAN inalámbrica IEEE 802.3 IEEE 802.11

Especificación 1000Base-T

Medio de comunicación UTP categoría 5

Topología Estrella

Norma de cableado EIA/TIA-568-B EIA/TIA 569

Clase de red Clase C Máximo 254 host Protocolos TCP/IP

Servidor (IDS) 23 SSH, 80 HTTP, Puertos Clientes 23 SSH

Tabla 4.1. Especificaciones del entorno de red de DAYUSOL.

Figura 4.2. Diagrama de entorno de red DAYUSOL. La Figura 4.2 muestra el entorno donde se implemento DAYUSOL, la comunicación con el cliente inalámbrico se realizo usando un punto de acceso de tecnología IEEE 802.11.

Capitulo 4. Implementación del sistema.

76

4.2.2. Canal de comunicación seguro. El sistema tiene definida una comunicación entre un servidor de monitoreo y el cliente de análisis, la infraestructura de una red LAN no garantiza un canal libre de ser escuchado. Es decir, la comunicación entre los equipos de la red es en claro, por lo que cualquier usuario podría escuchar la información que se envía por ella y en el peor de los casos, obtener información de archivos que no le pertenecen [9]. Por esta razón, se establece un canal que permita la seguridad de la información, la integridad de ésta y que no exista una suplantación. Para esto se requiere un canal seguro entre ambas partes, un traslado de información cifrada y un método de autenticación del Cliente y el Servidor. Previendo facilidad en la configuración del sistema, se decidió hacer uso de un esquema de seguridad eficiente y de fácil aplicación, el de Shell seguro (SSH). El sistema operativo cuenta con las aplicaciones de OpenSSh cliente y OpenSSh servidor; se encuentran en los repositorios de la distribución y deben ser instaladas como un paquete adicional. Es requisito que los clientes permitan la ejecución de comandos remotos por lo que se instala en ellos el OpenSsh Server y el servidor DAYUSOL será el cliente de la conexión. Para realizar la conexión entre entidades se utiliza el método de llave pública. La parte pública de la llave será almacenada en los servidores-SSH, que en este caso serán los elementos que se desean analizar, mientras que la parte privada de la llave debe guardarse en un directorio seguro del sistema cliente-SSH, en nuestro caso es el servidor de IDS. El tipo de llaves que se pueden generar son RSA y DSA, la llave RSA utilizada es de 1024 bits de longitud. El esquema será el siguiente: un servidor-SSH posee una lista de claves públicas, cada una asociada a un usuario. Cuando uno de dichos usuarios trata de conectarse al servidor-SSH, el servidor comprueba que efectivamente el cliente es quién dice ser mediante un algoritmo de clave pública, de manera que sólo el cliente legítimo que posea la correspondiente clave privada podrá autentificarse. La Tabla 4.2 resume los recursos utilizados para la configuración del modulo que permite establecer el canal de comunicación seguro.

Recurso Implementación Características

Cliente de OpenSsh Servidor de IDS Llave privada /root/.ssh/id_rsa Llave pública id_rsa.pub [DAYUSOL]

Servidores de OpenSsh Clientes de análisis Llave privada /root/.ssh/id_rsa Host permitidos known_hosts/id_rsa.pub [DAYUSOL]

Tabla 4.2. Especificaciones del SSH implementado en DAYUSOL.

Capitulo 4. Implementación del sistema.

77

4.2.3 Análisis de sistema (sensor). Teniendo el canal de comunicación establecido, se procede a la búsqueda y análisis de los directorios dentro de la máquina del cliente. Los parámetros de análisis son configurables y dependen del diseño de las políticas del cliente. El elemento que opera como sensor es un ejecutable, el cual obtiene información del cliente y utiliza el canal de comunicación para enviarla al elemento de control centralizado. Para obtener la información de las características del sistema de archivos el análisis del cliente se realiza en 2 partes:

• Análisis de la estructura de directorios. Se analiza la estructura de los directorios del cliente, verificando parámetros de propietario, usuario, grupo, número de enlaces, entre otros. Los parámetros configurables serán explicados en la sección 4.2.4.4. El árbol de directorios se analiza recursivamente con la función propia del sistema operativo llamada find, para obtener todos los nombres de los archivos y sus propiedades, los resultados son almacenados en un archivo de texto plano. Al finalizar el cliente envía el archivo al servidor DAYUSOL. Se implementa definiendo los parámetros de búsqueda de los archivos ya sea en base a sus permisos, propietario, grupo, fecha de acceso, entre otros. Para el sensor de esta herramienta se plantea el esquema descrito en la tabla 4.3. Elemento Descripción Aplicación Find ( /usr/bin/find) Ruta del directorio de búsqueda Ruta absoluta (/) Criterio de búsqueda Permisos , usuarios, fechas de acceso Tipo de elemento Archivos (f) Información del elemento Permisos (%m)

Enlaces (%n) Usuario (%u) Grupo (%g) Tamaño (%s) Ruta (%p)

Tabla 4.3. Especificaciones de estructura de archivos en DAYUSOL. Un ejemplo de la instrucción quedaría de la siguiente manera: /usr/bin/find / -perm +6111 -type f -printf "%m %n %u %g %s %p\n"

El criterio de búsqueda determinara los elementos que se almacenan y analizan, los parámetros de búsqueda pueden variar y están especificados en el manual de la aplicación find de Linux.

• Análisis de integridad de archivos. Se obtiene una huella digital de los archivos del cliente, aplicándoles un algoritmo de sumatoria o compendio. Para la obtención de huella digital existen varios algoritmos de compendio, el que se utiliza en DAYUSOL es el Md5 (Message-Digest Algorithm 5 o Algoritmo de firma de mensajes 5). Es el algoritmo hash más usado, procesa mensajes de una longitud arbitraria en bloques de 512 bits generando un compendio de 128 bits. Cualquier cambio en el archivo producirá una huella digital diferente.

Capitulo 4. Implementación del sistema.

78

Figura 4.3. Integridad de archivos utilizando funciones compendio.

Para la implementación de DAYUSOL se usan firmas digitales con algoritmo MD5, utilizando un programa del sistema operativo llamado md5sum. El procedimiento es poner como entrada el archivo y obtener una huella de 128 bits, la cual servirá de referencia de integridad (ver Figura 4.3), en un archivo de texto plano se van almacenando el nombre del archivo, su ruta dentro del árbol de directorios y su huella digital. Al finalizar el análisis se cierra el archivo y se envía al servidor. La Tabla 4.4 detalla las especificaciones de compendios para DAYUSOL.

Elemento Descripción Aplicación Find ( /usr/bin/find) Ruta del directorio de búsqueda Ruta absoluta (/) Criterio de búsqueda Permisos , usuarios, fechas de acceso Tipo de elemento Archivos (f) Acción si se encuentra el elemento Generar archivo compendio (md5sum)

Tabla 4.4. Especificaciones de compendios en DAYUSOL.

Un ejemplo de la instrucción quedaría de la siguiente manera: /usr/bin/find / -perm +6111 -type f -exec /usr/bin/md5sum {} \;

Existe también el SHA-1 (Secure Hash Algorithm 1 o Algoritmo de Hash Seguro 1). El cual toma como entrada un mensaje de longitud máxima 264 bits (más de dos mil millones de gigabytes) y produce como salida un compendio de 160 bits. Se puede implementar cambiando la herramienta md5sum por sha1sum o sus variantes de 256 y 512 bits.

Se deben enviar este par de elementos para la obtención de la estructura del sistema de directorios y la obtención de la integridad de la información mediante un compendio. La tabla 4.5 muestra el resumen de los sensores utilizados por DAYUSOL.

Recurso Implementación Características

Estructura de Directorio

Find Se ejecuta en el cliente /usr/bin/find

Búsqueda de archivos y sus propiedades dentro de directorios

md5sum Función Hash (compendio) Se ejecuta en el cliente /usr/bin/md5sum

Huella digital de 128 bits Uso de algoritmo MD5

Integridad de Archivos

SHA-1 Función Hash (compendio) Se ejecuta en el cliente /usr/bin/sha-1

Huella digital de 160 bits Uso de algoritmo SHA-1

Tabla 4.5. Resumen de sensores de DAYUSOL.

Capitulo 4. Implementación del sistema.

79

4.2.4. Directorio de aplicaciones. La información obtenida de los análisis de los clientes es almacenada en archivos de texto plano, entre otros aspectos, debido al número de elementos que se obtienen de cada análisis y la velocidad con la que se pueden hacer las comparaciones. Para facilitar el almacenamiento se utiliza un esquema inherente a la construcción del sistema operativo: jerarquía y clasificación de la información en base a su contenido. Por lo cual se implementa una estructura de directorios, el nivel más alto de ésta será el nombre del cliente de DAYUSOL. La Figura 4.4 muestra la estructura del directorio. Dentro del directorio se tiene un elemento para revisar las herramientas de hash, previendo la fiabilidad de la herramienta de análisis, este elemento se conoce como LOCAL. Otro directorio al mismo nivel es el POLITICAS, donde se almacenan las directivas de análisis aplicables al cliente, pueden diseñarse más de una política para cada uno de los clientes, pero deberá tenerse cuidado de sólo implementar una, debido a que esto cambiará la estructura del directorio. La estructura de almacenamiento de los resultados del análisis del cliente está bajo el directorio denominado REMOTO (B). El cual contiene al directorio ESTRUCTURA (C) y al directorio COMPENDIOS (C). El esquema de directorio DAYUSOL divide el nivel de riesgo asignado a consideración del administrador del sistema, se definieron los niveles ALTO, MEDIO y BAJO (D). Los archivos que almacenan las características del sistema de archivos del cliente y los compendios se almacenan en texto plano (E) (ver Figura 4.5). Los resultados del análisis de integridad de los clientes se almacenan dentro del directorio REPORTES. Los utilitarios del sistema dependen del administrador, las características implementadas en este desarrollo es la identificación de paquetes instalados, pero se puede extender hasta el uso de recursos, el control de usuarios, el traslado de bitácoras para el análisis, por mencionar algunos. La Tabla 4.6 resume la estructura del directorio de aplicaciones de DAYUSOL.

CLIENTE

LOCALREMOTOPOLITICAS REPORTES PAQUETES

Md5sum

Libc.so.6

Ld-linux.so

Cliente.polestructurascompendios

Figura 4.4. Estructura del directorio de usuarios DAYUSOL.

Capitulo 4. Implementación del sistema.

80

Recurso Implementación Características

Almacenamiento de Directorios

Directorio de Usuario Directorio de aplicaciones Directorio LOCAL Directorio REMOTO Directorio POLITICAS Directorio REPORTE

Almacenamiento de utilitarios

Directorio de utilitarios Directorio PAQUETES Directorio RESPALDOS *Directorio BITACORAS *Directorio RECURSOS *Directorio CONFIGURACION

Tabla 4.6. Directorio de aplicaciones de DAYUSOL.

COMPENDIO

CLIENTE

REMOTO

ESTRUCTURA

RIESGO

ALTO

RIESGO

MEDIO

RIESGO

BAJO

RIESGO

ALTO

RIESGO

MEDIO

RIESGO

BAJO

A

B

C

D

E

Figura 4.5. Estructura detallada del directorio REMOTO.

4.2.4.1. Detección de modificaciones. Las modificaciones de los archivos de trabajo son normales: se eliminan, agregan, modifican entre otras cosas, pero los archivos de configuración, de servicios o de mensajes del sistema no debieran cambiar, excepto por el usuario root. Las modificaciones de estos elementos no solo contemplan el contenido de la información, las modificaciones de sus permisos, usuarios propietarios o grupo al que pertenecen producen un ataque en el sistema, es muy probable que el intruso modifique o genere estos archivos para facilitar su entrada en el sistema en una próxima ocasión.

Capitulo 4. Implementación del sistema.

81

Una práctica bastante extendida consiste en modificar el comportamiento de diversas aplicaciones del sistema, de forma que no pueda delatar su presencia o crear shell scripts con el bit SUID activado y ocultarlos entre los archivos del sistema, entre las modificaciones más difíciles de detectar encontramos las que se producen sobre los propios programas del sistema. La única manera de detectar este tipo de modificaciones en los archivos es mantener una base de datos con los datos de los archivos e información adicional como un resumen criptográfico, e ir comparándola periódicamente con los datos de los archivos almacenados actualmente en el sistema servidor DAYUSOL. Se hace evidente que la metodología propuesta e implementada hasta el momento no detectará todas las intrusiones, ya que se conoce la información que envían los sensores, solo se tendrá la capacidad de detectar las intrusiones realizadas directamente sobre archivos de directorios específicos.

Figura 4.6. Búsqueda de modificaciones.

El elemento que realiza la búsqueda de cambios es un script de Shell que utiliza el programa diff, propio del sistema operativo Linux. El archivo diff encuentra diferencias entre dos archivos. La diferencia es clasificada en AGREGADO, MODIFICADO- ACTUALIZADO Y ELIMINADO, cada uno de los cuales es enviado como una línea a un archivo de texto. La Figura 4.6 describe el proceso de revisar los elementos enviados por el sensor con base en los almacenados en el servidor DAYUSOL, si se detecta cualquier variación entre los datos almacenados y los datos enviados por el sensor durante el análisis, es muy probable que un intruso haya modificado algún archivo, considerando la base de datos fiable organizada en el directorio REMOTO, cada uno de los archivos almacenados en el directorio DAYUSOL es abierto y comparado línea por línea en busca de modificaciones, si existen, éstas son enviadas directamente al archivo REPORTE, los eventos que pueden presentarse son: AGREGADO. El archivo no existía, es incluido en la estructura del directorio y se obtiene su huella digital. MODIFICADO. El archivo ya existía pero han sido modificados sus propiedades o su contenido, se registran los cambios, es incluido en la estructura y se obtiene su huella digital.

Capitulo 4. Implementación del sistema.

82

ACTUALIZADO: El archivo que fue modificado se almacena para conocer las propiedades y comparar el tipo de modificaciones realizadas, la información del anterior archivo es retirada de la estructura. ELIMINADO. El archivo existía y ha sido removido, se elimina su registro de la estructura de directorios y se elimina su registro del archivo de compendios. El procedimiento se repite para cada uno de los archivos enviados por el sensor, las modificaciones sobre el directorio son actualizadas, es decir, el archivo enviado por el servidor se considera la nueva base fiable y el archivo del servidor pasara a ser un resguardo del estado anterior con la correspondiente fecha de ejecución de la actualización.

4.2.4.2. Base de datos intrusiones. Motor de comparación de modificaciones, agregaciones y eliminación de archivos. El número de incidentes, el riesgo de cada una de ellas y la determinación del estado de los equipos clientes de DAYUSOL se realiza empleando una base de datos que almacena todos estos aspectos. El módulo de actualización de la base de datos de incidentes permite usar el archivo REPORTE y generar las consultas necesarias para actualizar la base de datos de cada equipo. La primera vez que se genera el Directorio de aplicaciones, también se genera la base de datos de incidentes del cliente. El estado actual del equipo se determina dependiendo del número de elementos detectados en el análisis y el grado de riesgo que representan. Los registros de los elementos detectados deberán ser resueltos por el administrador y actualizada en la base de datos. Posteriormente, el administrador deberá confirmar la información de la base de datos hacia el directorio de aplicaciones, mediante la ejecución de un programa que modifica la estructura del Directorio del cliente DAYUSOL. Se realiza de esta manera para incrementar la fiabilidad de la herramienta.

4.2.4.3. Generación de perfil de usuario La generación de perfil de usuario implica tipificar los elementos que serán objeto de monitoreo y análisis en el equipo cliente, establecer los intervalos de monitoreo, además, la activación de cada usuario y el intercambio de llaves públicas entre el cliente y el servidor de monitoreo.

4.2.4.4. Políticas de análisis de integridad Las políticas son todas las recomendaciones que se establecen para materializar un entorno de seguridad, en nuestro caso, estas reglas serán expresadas en un documento que servirá de guía para el servidor; se establece la ubicación del directorio del cliente, los directorios analizados, el nivel de riesgo de cada uno de los elementos, además de los utilitarios que se pueden implementar. La siguiente tabla muestra el resumen de las características de las políticas de los clientes de DAYUSOL, ésta puede ser editada al criterio del administrador.

Capitulo 4. Implementación del sistema.

83

La base de generación de las reglas corresponde a los criterios expresados en el sistema base de TRIPWIRE [12], los elementos y su correspondiente nivel de riesgo son retomados para la implementación en DAYUSOL los criterios, valores y su correspondiente política están expresados en la Tabla 4.7

Recurso Implementación Características

Directorio de datos /home/dayusol/usuarios Directorio del cliente Riesgos de seguridad

ALTO 5 MEDIO 3 BAJO 1

Niveles de riesgo, dependientes del uso del equipo cliente.

Define los directorios a examinar

000 / Ejecutables, suid,guid 010 /bin 020 /boot 030 /etc 040 /usr 050 /dev 060 /lib 070 /mnt 080 /opt 090 /var 100 /home 110 /proc 120 /sbin 130 /media 140 /custom 150 /user

Estructura de directorios de primer nivel de Linux, capacidad de establecimiento de hasta 10 niveles en cada directorio.

Define las propiedades del archivo analizado.

Permisos %m %n %u %g %s %p

Características del archivo descritas en la Tabla 4.2.

Revisión de paquetes Dpkg Define los paquetes instalados

Tabla 4.7. Estructura de políticas de DAYUSOL. Las reglas a implementarse para los equipos en este trabajo de investigación se proporcionan en el anexo 2, una muestra de la estructura de las reglas se describen en la Tabla 4.8, la Tabla 4.9 resume los directorios del sistema de archivos Linux y los niveles de riesgo asignados..

Regla Implementación

Características /usr/bin/find / -xdev -perm +6111 -type f -printf "%m %n %u %g %s %p\n"

Archivos ejecutables

Huella digital (Md5)

/usr/bin/find / -xdev -perm +6111 -type f -exec /usr/bin/md5sum {} \;

Características /usr/bin/find /bin -type f -perm +666 -printf "%m %n %u %g %s %p\n"

Archivos del directorio /bin

Huella digital (Md5)

/usr/bin/find /bin -type f -perm +666 -exec /usr/bin/md5sum {} \;

Características /usr/bin/find /boot -type f -perm +666 -printf "%m %n %u %g %s %p\n"

Archivos del directorio /boot

Huella digital (Md5)

/usr/bin/find /boot -type f -perm +666 -exec /usr/bin/md5sum {} \;

Tabla 4.8. Estructura de políticas de DAYUSOL.

Capitulo 4. Implementación del sistema.

84

Nivel

de riesgo

Descripción

Aplicaciones (ejecutables)

Propiedad de root Bit suid Bit guid

/bin Programas ejecución root /root Propiedad de root

Archivos del administrador /boot Archivos de arranque /etc Configuración

• Usuarios

• Contraseñas

• Servicios

• Dispositivos

• Red

• Puertos

• Programación de tareas Solo lectura. Ejecución y modificación restringida a root,

/usr Información sobre las aplicaciones de los usuarios

• Código fuente de aplicaciones.

• Manuales de ayuda de las aplicaciones.

• Aplicaciones de root ejecutables por los usuarios no administradores

/lib Librerías. Recursos que son utilizados por las aplicaciones.

ALTO

/sbin Programas de ejecución de los usuarios para el trabajo con Shell. Propiedad del administrador

/media Montaje de dispositivos

• Ópticos de lectura-escritura

• Almacenamiento removible Permitir lectura y escritura

/opt Aplicaciones opcionales de los usuarios. /mnt Igual que el directorio /media (menor uso)

MEDIO

/lost+found Recuperación de archivos. Uso exclusivo de root /var Contenido variable

• Logs del sistema

• Servidor web /proc (no implementado)

Procesos del sistema, variable de acuerdo al comportamiento y lo servicios utilizados. Importante fuente de análisis de comportamiento dinámico

BAJO

/home Carpeta personal de los usuarios Política del sistema operativo (644)

Tabla 4.9. Políticas y riesgo implementados en DAYUSOL. Esta política se diseña con un editor de textos, los criterios de selección de los elementos de cada necesidad se determinan con los parámetros del comando find, las descripción detallada de la implementación de las políticas para los equipos se encuentra en el Anexo 2. La activación del perfil consiste en intercambiar las llaves públicas entre el servidor de SSH y el cliente SSH. Ejecutar manualmente el análisis y mover el archivo de políticas dentro de la estructura de directorios del cliente.

Capitulo 4. Implementación del sistema.

85

La programación de los eventos de análisis se realiza con la herramienta cron, propia del sistema operativo, en el cual se pueden especificar los intervalos de tiempo y el archivo de políticas que se debe de utilizar para el análisis. La programación del análisis de cada equipo se definió en una vez por día y en un horario nocturno, este intervalo de tiempo se puede modificar de acuerdo al entorno, la Tabla 4.10 describe los horarios y la configuración del archivo de programación de tareas.

Programación de ejecución de DAYUSOL

Descripción de la tarea en cron

[Minuto Hora Día Mes Año] Cada 20 minutos de lunes a viernes */20 * 2-5 * * Una vez cada día a las 2 de mañana 0 2 * * *

Tabla 4.10. Programaciones de análisis utilizadas en DAYUSOL. Cabe destacar que esta parte del sistema fue diseñada de modo que el administrador se involucre directamente en la generación de los perfiles y no han sido automatizados los procesos con el objetivo de incrementar la seguridad de DAYUSOL. Para nuestra implementación se seleccionaron todos los directorios de primer nivel, con el fin de monitorear cualquier cambio en la estructura de directorios, pero a consecuencia, el volumen de información manejado es mayor.

4.3 Administración y actualización de cambios. Esta parte de DAYUSOL está encargada de usar los resultados del motor de búsqueda de modificaciones e insertarlos en la base de datos del usuario. La herramienta está escrita en PHP 5, que es un lenguaje de programación con capacidad de ejecución en línea de comandos y en entornos WEB. Inicialmente se toma el archivo denominado REPORTE, se consulta cada una de las líneas de éste y son convertidas en una consulta que permite agregar todos los elementos modificados, así como sus características dentro de la base de datos de cada usuario. La creación de la base de datos se realiza para cada uno de los equipos de acuerdo a sus requerimientos de seguridad. Y los reportes se generan a partir del análisis de la información contenida para cada usuario, el despliegue de resultados se realiza utilizando una interfaz Web.

4.3.1. Base de datos de estadísticas y reportes de incidentes Se tiene una base de datos para la administración de los reportes de incidentes, siguiendo con los principios de entidad- relación y las formas normales del diseño este esquema se muestra en la Figura 4.7. La Tabla 4.11 describe la funcionalidad de la base de datos DAYUSOL. Se almacenan los datos descriptivos de los clientes, las intrusiones detectadas incluyendo los tipos de modificación de cada una, además del estado de cada cliente. Este elemento es el soporte de los procesos de generación del estado y la interfaz grafica de usuario, la administración de la base de datos se realiza con un gestor propio de MySQL5, pero se puede implementar en cualquier gestor que soporte el esquema entidad – relación. En el Anexo 2 se incluye la descripción de la base de datos DAYUSOL.

Capitulo 4. Implementación del sistema.

86

Figura 4.7. Dase de datos Entidad-Relación de DAYUSOL

Recurso Implementación Características

Estructura de la base de datos de cada equipo

Base de datos DAYUSOL2008

Integridad referencial, Implementación en Mysql Determinación de nivel de fiabilidad del equipo cliente

Reporte de análisis de integridad individual

Formulario “Reporte Cliente” y “Fiabilidad Host”

Selección de estado del cliente. Fiabilidad del cliente dependiente del número de elementos detectados y su riesgo.

Reporte de Incidentes Módulo reportes Número de elementos de la red y fiabilidad. Archivo “Reporte Cliente” en formato electrónico de lectura (PDF).

Nivel de riesgos y estado del sistema

Política de seguridad RIESGOS: ALTO, MEDIO, BAJO. Estado del sistema: Fiable, No fiable, indeterminado.

Reporte de Actualización /reparación de cada equipo

Formulario “Actualización de elementos”

Actualiza elementos detectados. Determinación del estado del cliente.

Estadísticas del total de sistemas

Reporte “Reporte de red” Archivo “Reporte de Red” en formato electrónico de lectura (PDF).

Tabla 4.11. Base de datos de estadísticas y reportes de DAYUSOL.

Capitulo 4. Implementación del sistema.

87

4.3.2. Reportes de intrusiones usando correo electrónico. Las intrusiones son reportadas en la base de datos, el administrador de DAYUSOL podrá conocer el estado de los equipos de la red usando los datos almacenados en la base descrita anteriormente. Pero existen casos que podrían considerarse como críticos, situaciones donde la respuesta ante un incidente debe ser lo mas breve posible, por lo que el administrador debe ser notificado justo después de que la intrusión se ha detectado. Para esta situación se implementa una respuesta del sistema después del análisis cuando se detectan elementos de nivel de riesgo ALTO, si un cliente obtiene un estado No fiable después del análisis de DAYUSOL, se envía un correo electrónico al responsable de administrar la herramienta con un resumen general del estado del equipo Este método permite reducir el tiempo de respuesta ante un incidente. Se requiere hacer uso de un servidor de correo que sirva como interfaz de salida para los mensajes generados por la herramienta DAYUSOL.

4.4 Respaldo de archivos Este es un aspecto considerado como utilitario dentro de DAYUSOL, los utilitarios son módulos funcionalmente independientes que pueden ser agregados para incrementar la funcionalidad de la herramienta, pero su implementación no es indispensable. Por consideración de importancia fue implementado este módulo en uno de los clientes y no se aplicó a los demás debido a la infraestructura con la que se cuenta actualmente. El funcionamiento es muy sencillo, la política del cliente es modificada en el apartado “Utilitarios de Linux”, para el sistema de respaldo se deben comprimir los directorios que se desean y recibirlos en el servidor para almacenarlos con la fecha en que se realizan. Se utilizo el comando tar para esta tarea, se le puede aplicar un formato de compresión de tipo gzip con lo que se reduce el tamaño del archivo obtenido del cliente. El criterio de un sistema de respaldos depende de el nivel de importancia de cada elemento del sistema, pero en particular para nuestro caso el directorio de configuraciones toma un alto nivel de importancia, si el sistema es comprometido y se desea restaurar su funcionamiento será indispensable este grupo de archivos. 4.4.1. Políticas de respaldo de información Las políticas quedan definidas con el nombre del directorio y los archivos que se desean respaldar; este conjunto de elementos es comprimido, se almacena en el servidor, pudiendo tener un apartado destinado sólo para el almacenamiento de respaldos. La política queda de la siguiente manera: tar –zcf /tmp/respaldo-etc.tar.gz /etc Se puede hacer respaldo de otros directorios replicando la línea de políticas, cambiando el nombre del archivo y el directorio que se desea respaldar.

Capitulo 4. Implementación del sistema.

88

4.4.2. Respaldo y restauración de datos Los respaldos de información deberán contemplar los archivos de mayor importancia para cada cliente dependiendo de sus necesidades, la restauración de los datos se realiza desde una consola de comandos, consultando los datos que se tienen en el espacio de almacenamiento para el cliente y enviándoles sus archivos desde el servidor. Es importante hacer un análisis de la pérdida de información, ya que los motivos de ésta pudieran ser causados por algún intruso o programa que no ha sido detectado, la restauración de los datos debe hacerse sólo en un sistema cliente fiable.

4.4.3. Espacio y encriptación Debido a las limitaciones de hardware, resulta muy complicado implementar este módulo, en un ambiente con mayor capacidad, es posible implementar un sistema de discos empleados sólo para el fin de respaldos, pudiendo incluso ser en el mejor de los escenarios un servidor de respaldos. La información puede ser encriptada y de este modo mejorar la privacidad de los datos almacenados.

4.5. Comentarios finales. Se han explicado los métodos y las herramientas utilizadas para la implementación de DAYUSOL, también se describieron los requerimientos para garantizar la funcionalidad de la herramienta. Todos los elementos son configurables y por lo tanto adaptables para los diferentes entornos de monitoreo donde se desee implementar. Cabe destacar que el motor de modificaciones de DAYUSOL, el servidor de páginas WEB, la base de datos de cambios de MySQL y el servidor de correo se encuentran instalados dentro del mismo equipo de cómputo.

Capitulo 5. Pruebas del sistema DAYUSOL.

89

CAPÍTULO 5. PRUEBAS DEL SISTEMA DAYUSOL

Este capítulo está enfocado a describir las pruebas a las que fue sometido el sistema DAYUSOL. Cubre los aspectos de fiabilidad de análisis, tipos de detecciones y la carga de trabajo en los clientes.

Es importante hacer un análisis del funcionamiento del sistema en materia de integridad y detección de intrusos, de igual manera, el analizar la cantidad de recursos que requiere para su ejecución, el tiempo empleado para realizar análisis o ejecución de utilitarios, el volumen de información que procesa el servidor, la afectación del rendimiento del equipo cliente y el trafico generado en la red.

5.1 Sistema de directorios del cliente DAYUSOL. El directorio que sirve como base de referencia para el análisis debe ser creado cuando el sistema cliente esta libre de intrusiones, se propone obtener esta referencia justo después de la instalación del sistema operativo. Para la generación de este directorio se debe ejecutar las actividades definidas en el capitulo anterior consistentes diseñar el perfil de usuario. La Figura 5.1 muestra el entorno de red donde se instaló y sirvió como escenario de las pruebas de DAYUSOL.

Figura 5.1. Escenario de pruebas de DAYUSOL.

Se utilizaron los siguientes equipos de cómputo:

• Servidor DAYUSOL. Equipo que funciona como servidor IDS, web y base de datos.

• Router. Equipo router, firewal y cliente 192.168.1.1 de DAYUSOL.

• Cliente 192.168.1.10. y Cliente 192.168.1.11. Equipos interfaz 10/100 Ethernet.

• Cliente inalámbrico. Equipo portátil con interfaz inalámbrica.

Capitulo 5. Pruebas del sistema DAYUSOL.

90

Las políticas utilizadas para cada elemento descrito en el esquema anterior se encuentran en el Anexo 2, la conexión y la configuración de los sistemas de conexión SSH se describen en el Anexo 1, por lo que se parte de tener ya configuradas las llaves de autenticación en los equipos clientes y las políticas de cada uno de ellos en el servidor. Las imágenes y tablas mostradas en este apartado son del equipo router. La primera vez que se ejecuta el análisis, se generan los directorios de referencia y los archivos correspondientes a las estructuras y los compendios, en la Figura 5.2 se muestra la estructura del árbol de directorios generado por la herramienta DAYUSOL.

Figura 5.2. Árbol de directorio de cliente de DAYUSOL.

Figura 5.3. Árbol de directorio de cliente de DAYUSOL después la de detección de intrusos.

Capitulo 5. Pruebas del sistema DAYUSOL.

91

Los análisis posteriores se realizan sin la intervención del administrador, los archivos del directorio de referencia utilizan una política permisiva, es decir, el archivo obtenido durante el análisis que genere modificaciones es establecido como referencia y el anterior es almacenado con el nombre de la fecha en que se realizo el análisis. Si no existen modificaciones solo cambia el archivo de reporte con la fecha en que se realizo el análisis. La Figura 5.3 muestra el árbol de directorios de un cliente después de un análisis donde se habían realizado modificaciones y las cuales fueron detectadas por DAYUSOL. El archivo de reporte se encuentra en la carpeta correspondiente al mismo nombre, cuando se identifican modificaciones entre el archivo del sistema almacenado en el directorio de DAYUSOL y el enviado por el sensor, se agregan líneas describiendo el elemento, sus parámetros y el tipo de modificación. En la figura 5.4 se aprecia una parte del archivo de reporte después del análisis de un equipo al que se le modifico su estructura de archivos.

Figura 5.4. Líneas del archivo de reporte después la de detección de intrusos.

Con estos elementos se comprueba que el sistema funciona en la recolección de la información, el motor de búsquedas de diferencias y la generación de reportes con las respectivas intrusiones detectadas.

5.1.1 Utilitarios del sistema DAYUSOL. Se define para todos los clientes una regla que permite la recolección de información respecto a los paquetes instalados. La Figura 5.5 muestra un extracto del archivo instalados que se encuentra dentro del directorio PAQUETES.

Capitulo 5. Pruebas del sistema DAYUSOL.

92

Figura 5.5. Contenido del archivo instalados.

Este archivo sirve como referencia para la detección de modificaciones de los paquetes instalados en el cliente, la metodología de análisis de este directorio es idéntica a los descritos anteriormente para la integridad del sistema de archivos. Los respaldos son implementados en sustitución, es decir que el sistema genera un directorio RESPALDOS y almacena los datos que le sean indicados en la política del cliente. En cuestiones de seguridad se pretende restaurar la funcionalidad del sistema, por lo que se respalda el contenido del directorio /etc. El respaldo debe desactivarse una vez que se ha generado la estructura de directorios para contar con un punto fiable. Los respaldos pueden hacerse sobre los directorios necesarios, la limitante será el espacio de almacenamiento y el tiempo necesario para realizar este procedimiento. Se recomienda generar una política solo para respaldos considerando que se requiera almacenar información adicional a la recuperación del sistema, esto permitirá establecer periodos diferentes para la realización del respaldo a los análisis de intrusos. En nuestro caso, se diseño la política para lograr la restauración del sistema y se procede a desactivar los respaldos. La figura 5.6 muestra el directorio del cliente donde se aprecia el archivo respaldo.

Figura 5.6. Árbol de directorio de cliente de DAYUSOL con los respaldos de /etc y /usr.

La capacidad de almacenamiento varia dependiendo del equipo, en el caso de extraer del cliente los archivos de los directorios de nivel de riesgo alto proporciona un volumen de aproximadamente de 500 Mbytes.

Capitulo 5. Pruebas del sistema DAYUSOL.

93

5.2. Actualización de cambios de DAYUSOL. La actualización de la base de datos se realiza con los datos que posee el archivo de reporte después de un análisis del cliente. Esta información es trasladada a la base de datos intrusiones donde se agregan los registros correspondientes, cabe destacar que este proceso se realiza de manera automática por lo que no se requiere de la intervención del usuario. Lo realiza el sistema Base de datos modificaciones. Las consultas generadas son manejadas por la base de datos instalada en el equipo servidor y almacenadas en DAYUSOL 2008. La generación del estado del cliente depende de la cantidad de archivos detectados como intrusión y el riesgo de cada una de ellas, se almacenan también la fecha y hora del análisis. La Figura 5.7 muestra la consulta realizada para ver el estado de los clientes y la fecha de su último análisis.

Figura 5.7. Consulta del estado de los clientes en DAYUSOL2008.

Las intrusiones detectadas son almacenadas dentro de la base de datos dependiendo si es de estructura o compendio, el riesgo y el tipo de modificación. La Figura 5.8 muestra las tablas que componen la base de datos DAYUSOL2008.

Figura 5.8. Tablas de la base de datos DAYUSOL208.

La actualización de los elementos se realiza automáticamente después del análisis, en caso de que se realicen modificaciones de restauración de un equipo o la revisión de elemento son intrusivos pero detectados, se deberá realizar por parte del administrados con el uso de un gestor de base de datos. En nuestro caso se utilizo la aplicación Phpmyadmin, la cual utiliza una interfaz web.

5.3. Interfaz grafica de usuario y reportes. En este punto se muestran los resultados de los elementos diseñados para la presentación de los datos obtenidos por DAYUSOL en el directorio del servidor y enviados a la base de datos DAYUSOL2008, la función de este elemento es proporcionar un resumen de la información de manera sencilla y entendible para el usuario.

Capitulo 5. Pruebas del sistema DAYUSOL.

94

Se generan interfaces graficas de usuario en un entorno web, por lo tanto estas son almacenadas como paginas de un servidor. Para nuestro caso se utilizo Apache 2.0 y un preprocesador de texto PHP para realizar las consultas con la base de datos, la presentación de las graficas y los datos dinámicos. Se generan tres pantallas diferentes para mostrar de manera ordenada los datos y facilitar su interpretación, se describen las características a continuación.

• REPORTE DE RED (ver Figura 5.9):

1. Numero de equipos clientes 2. Resumen de fiabilidad de los clientes 3. Gráfica del estado de la red 4. Tabla de resumen de análisis de los clientes de DAYUSOL.

a. Número de cliente b. Nombre de Host c. Número de archivos (intrusión) d. Número de modificaciones de paquetes e. Fecha y hora del último análisis f. La fiabilidad del cliente g. Enlace para conocer detalles (Pagina REPORTE DE HOST)

Figura 5.9. Interfaz REPORTE DE RED.

Capitulo 5. Pruebas del sistema DAYUSOL.

95

12 3

4c4b4a 4d 4e

45

Figura 5.10. Interfaz REPORTE DE HOST.

• REPORTE DE HOST (ver Figura 5.10):

1. Datos generales del cliente 2. Resumen de elementos detectados clasificados por el nivel de riesgo 3. Gráfica del estado del cliente 4. Tabla de resumen de elementos detectados (integridad)

a. Nivel de riesgo b. Archivos agregados c. Archivos eliminados d. Archivos modificados e. Archivos actualizados

5. Tabla de resumen de elementos detectados (estructura)

• REPORTE DE HOST (ver Figura 5.11):

1. Datos generales del cliente 2. Tabla de directorio descriptiva de elementos detectados y el riesgo

a. Nombre del elemento b. Modificación c. Características d. Fecha de detección

3. La tabla de resumen se repite para cada uno de los directorio que se encuentran en ese nivel de riesgo

Capitulo 5. Pruebas del sistema DAYUSOL.

96

1

2a

3

2

2b 2c 2c

Figura 5.11. Interfaz REPORTE DETALLADO.

Los reportes impresos en formato electrónico portable (PDF) se generan directamente desde el navegador Firefox-3 con la opción del menú Archivo/Imprimir. Estos formatos corresponden a lo mostrado en las páginas web de la interfaz para DAYUSOL, por lo que su generación es sencilla. La figura 5.11 muestra los iconos de los archivos en formato PDF.

Figura 5.12. Reportes en formato electrónico (.PDF).

5.3.1. Alarma de DAYUSOL mediante correo electrónico. Las alarmas que maneja DAYUSOL son pasivas, la primera esta reflejada en los reportes descritos anteriormente, la segunda es el envió de un correo electrónico al administrador de DAYUSOL, se aplica cuando el cliente presenta un estado de no fiabilidad.

Capitulo 5. Pruebas del sistema DAYUSOL.

97

Se hace uso de un sistema de alarma mediante un servidor de correo y un mensaje de resumen de los elementos detectados en el último análisis. La Figura 5.13 muestra la bandeja de entrada de la cuenta [email protected], la cual fue habilitada para registrar los reportes de DAYUSOL. La Figura 5.14 muestra el resumen de las intrusiones detectadas enviado como contenido del mensaje de correo.

Figura 5.13. Bandeja de entrada de correo electrónico con los reportes de DAYUSOL.

Figura 5.14. Contenido del correo electrónico enviado por DAYUSOL.

Las pruebas de funcionamiento se han descrito y se han mostrado los resultados obtenidos desde el sensor hasta la generación de reportes en formatos impresos las alarmas de correo electrónico. Los siguientes elementos a considerarse son la capacidad de análisis de información y los recursos utilizados por cada equipo durante la operación de DAYUSOL.

5.4. Análisis de fiabilidad e integridad de los sistemas DAYUSOL Se diseño un banco de pruebas para analizar la fiabilidad y los elementos que puede detectar DAYUSOL, el monitoreo de los recursos utilizados por los equipos clientes y servidor se realizo con la herramienta top, el monitoreo del tráfico de la red se realizó utilizando la herramienta munin [30].

5.4.1. Técnicas utilizadas para la evaluación de detección de intrusos. Se realizó el análisis en tres etapas diferentes: detección de todas las modificaciones, la detección de modificaciones mediante la instalación de paquetes y la detección de intrusos.

Capitulo 5. Pruebas del sistema DAYUSOL.

98

5.4.1.1. Modificaciones DAYUSOL. Esta etapa estaba enfocada a determinar todas las modificaciones que podía reconocer DAYUSOL, para logra este cometido se generaron políticas que permitan analizar todos lo elementos del sistema de archivos excepto el directorio /proc. Eliminación, modificación y agregación de archivos: La manipulación directa de los archivos se puede realizar desde la interfaz de la línea de comandos, mediante la interfaz gráfica o la ejecución de scripts; Se realizaron modificaciones directas de los usuarios dentro de su directorio (/home/usuario). Las aplicaciones que se utilizaron para cada equipo fueron Open Office Suite, Gaim y Mozilla Firefox (Descargas), seleccionadas por ser las que muestran un uso mayor dentro de los entornos Linux. Las pruebas consistían en la manipulación de los archivos sin cambio de los permisos o de propietarios, se ejecutaron 5 scripts de Shell que permitían realizar cambios de la estructura de los directorios en los equipos clientes. DAYUSOL fue programado para realizar análisis de cada uno de los clientes en intervalos de una hora, el tamaño de la muestra corresponde a un mes de trabajo de los equipos.

• Cliente 192.168.1.1 Nombre: Router.

Tabla 5.1. Resumen de modificaciones en el cliente Router.

Figura 5.15. Elementos detectados por DAYUSOL en el cliente Router.

Consola

Comando Script

Aplicaciones

Agregados 35 20 43

Eliminados 35 40 86

Modificados 35 20 82

Total 105 80 211

DAYUSOL 105 80 208

Capitulo 5. Pruebas del sistema DAYUSOL.

99

La Tabla 5.1 muestra las modificaciones realizadas en el cliente Router para esta prueba, se muestran tambien los elementos detectados por DAYUSOL. La Figura 5.15 describe el comportamiento de DAYUSOL frente a las modificacioes realizadas. El proceso de análisis se realizó sin detener la carga de trabajo a los equipos clientes, en el caso del equipo cliente Router, se detectó una variación de los elementos mientras se utilizaba la aplicación Open Office Writer, la cual tenía abiertos archivos y la modificación de éstos no fue reportada. Existe una diferencia de 3 elementos entre los archivos modificados por las aplicaciones y los detectados por DAYUSOL, esto se debe a que las aplicaciones manejan archivos temporales y durante este tiempo la modificacion se realiza sobre una copia del archivo, posteriormente se refleja de manera real sobre el archivo.

• Cliente 192.168.1.10 Nombre: Moniton

La Tabla 5.2 muestra las modificaciones realizadas en el cliente Router para esta prueba, se muestran tambien los elementos detectados por DAYUSOL. La Figura 5.16 describe el comportamiento de DAYUSOL frente a las modificacioes realizadas.

Tabla 5.2. Resumen de modificaciones en el cliente Moniton.

Figura 5.16 Elementos detectados por DAYUSOL en el cliente Moniton

Consola

Comando Script

Aplicaciones

Agregados 10 20 22

Eliminados 50 40 18

Modificados 10 20 43

Total 70 80 83

DAYUSOL 70 80 83

Capitulo 5. Pruebas del sistema DAYUSOL.

100

• Cliente 192.168.1.11 Nombre: Alexin

La Tabla 5.3 muestra las modificaciones realizadas en el cliente Router para esta prueba, se muestran tambien los elementos detectados por DAYUSOL. La Figura 5.17 describe el comportamiento de DAYUSOL frente a las modificacioes realizadas.

Tabla 5.3. Resumen de modificaciones en el cliente Alexin.

Figura 5.17. Elementos detectados por DAYUSOL en el cliente Alexin.

Análisis de resultados. Las graficas muestran la capacidad de detectar modificaciones por parte de DAYUSOL, los archivos que se detectan pueden ser incluso archivos ocultos o temporales.

5.4.1.2. Instalación de software mediante gestores de paquetes. Esta etapa permitiría bosquejar el comportamiento de DAYUSOL frente a una tarea administrativa poco frecuente como lo es la instalación o desinstalación de paquetes. Si el procedimiento es realizado por el administrador del equipo cliente debería ser considerada como un procedimiento permitido, en caso contrario, la instalación de software se convierte en un procedimiento intrusivo.

Consola

Comando Script Aplicaciones

Agregados 40 30 36

Eliminados 36 40 3

Modificados 15 18 45

Total 91 88 84

DAYUSOL 91 88 84

Capitulo 5. Pruebas del sistema DAYUSOL.

101

Se hicieron pruebas de instalación y desinstalación de algunas aplicaciones, éstas requieren de instalación de otros elementos o tienen dependencia funcional, por lo que el número de archivos detectados en los reportes es bastante alto. Los reportes de análisis de DAYUSOL muestran todos los cambios realizados mediante la herramienta APT sin importar la interfaz utilizada. La Tabla 5.4 muestra los detalles de las modificaciones detectadas en esta prueba... Las siguientes líneas muestran los paquetes instalados en el equipo cliente Alexin mediante Synaptic.

• Stealth versión 1.46-l, Tamaño: 782 kb. Prioridad opcional Dependencias: libbobcat1, libc6, libgcc1, libstdc++6

• Bluefish 1.0.7-2 Tamaño 6918 kB. Prioridad opcional Dependencias: libart-2.0-2, libaspell15, libatk1.0-0, libbonobo2-0, libbonoboui2-0, libc6, libcairo2, libconfig, libconf2-4, libglib2.0-0, libgnome-keyring0, libgnome2.0-0, libgnomecanvas2-0, libgnomeui-0, libgnomevfs2, libgtk2.0-0, libice6, liborbit2, libpango, libpcre, libpopt0, libsm6, libx11-6, libxcursor1, libxetx6, libfixies3, libxis6, libxinerama1, librandr2, librender1, xpdf-reader, gv, tetex-bin, tofrodos.

DIRECTORIOS

Ejecutables etc usr home

Agregados 9 0 103 0

Eliminados 0 0 0 0

Modificados 0 1 5 3

Total 9 1 108 3

DAYUSOL 9 1 108 5 Tabla 5.4. Resumen de modificaciones con la instalación de paquetes.

Figura 5.18. Elementos detectados por DAYUSOL en la instalación de paquetes con APT.

Capitulo 5. Pruebas del sistema DAYUSOL.

102

Este es un ejemplo de la instalación de dos paquetes, la mayoría de las instalaciones realizan un trabajo de copia, compilación y modificación de archivos que superan la capacidad humana de revisarlos de manera minuciosa. Este análisis refleja todos los cambios realizados por la instalación de los paquetes stealth, Bluefish y sus dependencias (ver Figura 5.18), el directorio del usuario muestra archivos temporales que estaban siendo utilizados durante la ejecución de DAYUSOL, razón por la que la detección de elementos dentro del directorio /home es de 2 elementos más que no estaban considerados durante la instalación. Se comprueba que el análisis entrega el resultado de la modificación de la estructura de directorios cuando se instalan programas o se desinstalan mediante el método de APT. Las siguientes líneas son el resultado del reporte generado por DAYUSOL y la Figura 5.19 muestra la consulta realizada a la base de datos DAYUSOL2008 después de la instalación de los paquetes. ADD: Checker < ii stealth 1.46-1 A stealthy File Integrity Checker ADD: editor < ii bluefish 1.0.7-2 advanced Gtk+ HTML editor ADD: library < ii libbobcat1 1.15.0-1 run-time (shared) Bobcat library

Figura 5.19. Registros de DAYUSOL 2008 de los paquetes instalados con APT.

El modelo de permisos reduce a un usuario que no es administrador la capacidad de instalar nuevos programas o la eliminación de éstos, pero no impide que código malicioso pueda hacerlo. Los directorios de configuración y de instalación de programas están determinados en un nivel de riesgo ALTO, el usuario que tiene acceso a la instalación de software en el equipo debe contar con privilegios de administrador (root). Estos programas se almacenan regularmente en tres rutas diferentes: El directorio del código fuente, el directorio de los archivos ejecutables y de configuración y por último, el directorio de la documentación y tutoriales.

5.4.1.3. Modificación de permisos, usuario, grupo, guid. Una de las razones de existencia de DAYUSOL es la revisión de los permisos que posee cada archivo dentro de la estructura de directorios, este aspecto es considerado como el eje de nuestro desarrollo. La estructura que maneja el sistema operativo restringe el uso, lectura, escritura, ejecución de los archivos de acuerdo a los permisos que posee para el propietario, grupo y otros (ver Tabla 2.1); cualquier modificación de estos aspectos puede implicar un riesgo de seguridad o alguna intrusión cuando se evalúan los directorios de configuración, servicios o aplicaciones. Los directorios con un nivel de riesgo ALTO dentro de DAYUSOL son revisados para notificar de la manera más breve al administrador las modificaciones, debido a que los archivos poseen como propietario al usuario root en la mayoría de los casos, es común que los intrusos intenten obtener archivos de este propietario o se intenta introducir archivos con estas características.

Capitulo 5. Pruebas del sistema DAYUSOL.

103

Los intrusos también buscan ejecutar aplicaciones con privilegios de administrador, para obtenerlo suelen pasar antes por otros usuarios, aprovechan hacer un escalamiento de privilegios y llegar a su objetivo. Por esta razón, se analizaron algunos scripts que modifican permisos, propietarios o grupos de los archivos del sistema; éstos fueron diseñados en Shell y ejecutados en el equipo cliente Alexin para mostrar la capacidad de detección de DAYUSOL y los resultados que presentaban los reportes de integridad. Las políticas implementadas se describen en el Anexo 2. Herramientas instaladas:

• Zeus. Genera procesos a partir de los existentes para reducir el rendimiento del sistema, requiere privilegios de root y archivo ejecutable.

• Remote-Shell. Permite la ejecución de una terminal con privilegios de administrador desde cualquier sistema utilizando una interfaz web. Requiere un servidor web y el modulo de php con la ejecución de comandos activada. El archivo se almacena dentro de la carpeta de publicación del servidor con propietario root

Estas herramientas son intrusiones, fueron instaladas mediante una memoria usb directamente sobre el equipo, podrían ser instaladas por intrusos haciendo uso de cualquier técnica de acceso al equipo. Las Figura 5.20, 5.21 y 5.22 muestran el detalle de la intrusión detectada por DAYUSOL después del análisis realizado al cliente Alexin y de haber instalado Zeus y Remote-Shell.

Capitulo 5. Pruebas del sistema DAYUSOL.

104

Figura 5.20. Reporte de RED de DAYUSOL posterior a la intrusión Zeus y Remote-Shell.

Capitulo 5. Pruebas del sistema DAYUSOL.

105

Figura 5.21. Reporte de HOST de DAYUSOL posterior a la intrusión Zeus y Remote-Shell.

Figura 5.22. Reporte DETALLADO de DAYUSOL posterior a la intrusión Zeus y Remote-Shell.

Debido a que son elementos ejecutables, son detectados como nivel de riesgo ALTO, por esta razón se modifica el estado de fiabilidad del cliente (ver Figura 5.20) y se envía el correo correspondiente al administrador de DAYUSOL notificando la intrusión (ver Figura 5.23). Destaca la importancia de la detección de otros elementos a la misma hora de la intrusión, los correspondientes al directorio /media. Se encuentra la detección del montaje de la unidad usb (ver Figura 5.24), lo cual permitiría reducir las probables vías de acceso por el cual el sistema fue penetrado. Este aspecto corresponde más a la forencia informática, pero no deja de ser una contribución para la seguridad del sistema.

Figura 5.23. Correo electrónico recibido debido a la intrusión Zeus y Remote-Shell.

Capitulo 5. Pruebas del sistema DAYUSOL.

106

Figura 5.24. Detección del montaje de dispositivos en el mismo análisis de la intrusión Zeus y

Remote-Shell. El cliente fue probado con una aplicación que se situaba en el directorio /home, con darle permisos de ejecución este se copio y obtuvo permisos de administrador. La tarea siguiente fue correr varios sripts que le permitían buscar puertos, aplicaciones con la intención de generar procesos y cuando un proceso real de la maquina se lanza, este intruso genera otros de idéntico nombre solo para generar carga en el cliente y posteriormente denegación de servicio. Es en este punto, donde se considera una opción poco fiable que la evaluación del estado de un sistema sea realizada por herramientas que se ejecutan sobre el mismo, si una herramienta intrusiva cambia los programas de diagnostico, DAYUSOL recurre a un cliente y una entidad para realizar el análisis, con lo cual se logra una fiabilidad mayor de los resultados obtenidos.

5.5. Pruebas de rendimiento para DAYUSOL en el cliente Realizar el análisis de un equipo implica hacer uso de sus recursos de hardware del cliente, los del servidor y del medio que se utiliza para el transporte de los datos entre estas dos entidades. Este aspecto se considera de importancia y se recomienda efectuar el análisis de los equipos clientes durante los periodos de actividad baja, pero en algunos lugares esto resulta imposible de implementar y debe realizarse cuando el equipo cliente tiene carga de trabajo o se encuentra en producción en el caso de un servidor. La tecnología que se utiliza para la transmisión de los datos es un aspecto del cual no se tiene control, es dependiente del entorno donde se implementa y los equipos de conmutación disponibles. La red estaba diseñada únicamente para la comunicación de DAYUSOL, lo que implica que el tráfico interno de la red era casi nulo, todos los equipos tenían salida hacia internet por medio de un Router implementado en Linux, permitiendo las actualizaciones de los programas y la instalación de software cuando se requería.

Capitulo 5. Pruebas del sistema DAYUSOL.

107

Los recursos de hardware del cliente que considerados durante el análisis con DAYUSOL son los siguientes:

• Uso de procesador

• Memoria RAM

• Volumen de información analizado

• Tiempo requerido para el análisis Los análisis de rendimiento fueron tomados de manera manual durante 10 días diferentes y se realizó el promedio de estos, se utilizaron las herramientas de monitoreo de recursos cacti y munin.

5.5.1. Pruebas de rendimiento para el cliente 192.168.1.1

192.168.1.1 Router Procesador

Memoria

RAM Memoria

swap Tiempo de

análisis Pentium IV 700 Mhz

255.76 Mbytes

433.77 Mbytes. 18.52 seg.

Directorios (Mbytes) Ejecutables 2100

bin 3.6 boot 6.5

etc 23 usr 1400

dev 216 lib 58 mnt 4

opt 4 sbin 3600

media 12 home 74 Total 7501.1

Tabla 5.5. Características de hardware del cliente Router.

Capitulo 5. Pruebas del sistema DAYUSOL.

108

Figura 5.25 Recursos utilizados por DAYUSOL en cliente Router.

La Tabla 5.5 describe los recursos de hardware del cliente Router y la Figura 5.25 muestra el porcentaje de uso de la memoria RAM, procesador y tiempo empleado para el análisis con DAYUSOL. El cliente esta habilitado como ruteador, cortafuegos, servidor de páginas web Apache 2.0 y servidor de Base de datos MySQL.

5.5.2. Utilización de recursos en el cliente 192.168.1.10 La Tabla 5.6 describe los recursos de hardware del cliente Miniton y la Figura 5.26 muestra el porcentaje de uso de la memoria RAM, procesador y el tiempo empleado para el análisis con DAYUSOL.

192.168.1.10 Miniton

Procesador

Memoria RAM

Memoria swap

Tiempo de análisis

Pentium IV 2.4 Ghz

255.736 Mbytes

971.924 Mbytes. 12.30 seg.

Directorios (Mbytes) Ejecutables 2300 bin 4.8

boot 18 etc 9.7

usr 1800 dev 0.064

lib 154 mnt 4 opt 4

sbin 6.8 media 12

home 128 Total 4441.364

Tabla 5.6. Características de hardware del cliente Miniton.

Capitulo 5. Pruebas del sistema DAYUSOL.

109

Figura 5.26 Recursos utilizados por DAYUSOL en cliente Moniton.

5.4.3. Utilización de recursos en el cliente 192.168.1.11 La Tabla 5.7 describe los recursos de hardware del cliente Alexin y la Figura 5.27 muestra el porcentaje de uso de la memoria RAM, procesador y el tiempo empleado para el análisis con DAYUSOL.

192.168.1.11 Alexin Procesador

Memoria

RAM Memoria

swap Tiempo de

análisis Pentium IV

1.7 Ghz 516.688 Mbytes

1180.696 Mbytes 13 seg.

Directorios (Mbytes) Ejecutables 2600 bin 3.6

boot 12 etc 24

usr 1800 dev 224 lib 58

mnt 4 opt 4

sbin 3.6 media 12

home 8.8 Total 4754

Tabla 5.7. Características de hardware del cliente Alexin.

Capitulo 5. Pruebas del sistema DAYUSOL.

110

Figura 5.27 Recursos utilizados por DAYUSOL en cliente Alexin.

5.4.3. Utilización de recursos en el cliente 192.168.1.20

192.168.1.20 Alex-lap-hp Procesador

Memoria

RAM Memoria

swap Tiempo de

análisis Centrino 2 Duo 1.83 Ghz

1025.752 Mbytes

967.672 Mbytes 20.25 seg.

Directorios (Mbytes) Ejecutables 9910 bin 5.2

boot 46 etc 17

usr 2400 dev 132

lib 300 mnt 4 opt 4

sbin 6.9 media 954

home 6900 Total 20679.1

Tabla 5.8. Características de hardware del cliente Alex-lap-hp.

La Tabla 5.8 describe los recursos de hardware del cliente Alexin y la Figura 5.28 muestra el porcentaje de uso de la memoria RAM, procesador y el tiempo empleado para el análisis con DAYUSOL. El cliente utiliza una interfaz inalámbrica para la comunicación con la red, tiene instalado un servidor de páginas web y una maquina virtual. Los resultados obtenidos prueban el funcionamiento de DAYUSOL con el estándar “IEEE802.11 g”.

Capitulo 5. Pruebas del sistema DAYUSOL.

111

Figura 5.28 Recursos utilizados por DAYUSOL en cliente Alex-lap-hp.

Figura 5.28 Carga de trabajo durante el análisis con DAYUSOL en cliente Alex-lap-hp.

La Figura 5.28 muestra el promedio de la carga de trabajo del equipo Alex-lap-hp durante el análisis de DAYUSOL, esta carga es relativamente baja. La grafica fue tomada de los reportes de monitoreo de comportamiento con la herramienta cacti. 5.5. Comentarios finales. Se utilizaron varias herramientas para la obtención de los datos mostrados en las gráficas. Cabe destacar que los análisis muestran una diferencia en el tiempo requerido y los recursos utilizados para llevarlo a cabo, dependiente del hardware con que cuenta cada cliente, por lo cual resulta muy complicado determinar un valor estándar de volumen de información por unidad de tiempo. El conjunto de pruebas realizadas para el sistema DAYUSOL estuvieron enfocadas a la demostración de sus capacidades en cuestión de detección de intrusiones, velocidad de actualización de la información, recursos utilizados, tiempo y carga de trabajo en cada cliente.

Capitulo 6. Conclusiones y trabajos a futuro.

111

CAPÍTULO 6. CONCLUSIONES Y TRABAJOS A FUTURO

En este capitulo se analizan los objetivos planteados al principio de el proyecto y se describen los logros alcanzados con el sistema DAYUSOL, de igual manera, se dejan planteados proyectos que complementen o fortalezcan esta herramienta.

6.1. Conclusiones La información que se almacena en los sistemas de cómputo se ha convertido en el elemento más valioso que estos poseen y está expuesto a un número grande de amenazas, es por eso que las herramientas de seguridad han cobrado gran importancia. Se analizaron los principios de funcionamiento de las amenazas informáticas existentes y los métodos de detección aplicados actualmente, con base en estos aspectos se reviso la estructura del sistema de archivos de Linux y la metodología que aplica para la seguridad de sus elementos. Con base en los desarrollos comerciales como Tripwire, se propone una metodología de análisis de intrusos y preservación de la integridad mediante técnicas criptográficas. Este desarrollo se reflejo en la obtención e implementación de los siguientes elementos:

• Un sistema de directorios constituido por la información del sistema de archivos, organizada de manera jerárquica y almacenada en un servidor central.

• Una metodología de detección de intrusiones basadas en las propiedades de los archivos y la integridad de la información que almacenan.

• Una base de datos relacional con la capacidad de almacenar las intrusiones detectadas, actualizable de manera automática después de cada análisis del cliente.

• Una interfaz grafica que presenta los resultados de los análisis de los equipos de manera breve, clara y en un corto tiempo.

La herramienta DAYUSOL fue el resultado de la implementación de los conceptos de los detectores de intrusos, proporciona a los usuarios administradores de sistemas un método de detección de intrusos, basado en herramientas propias del sistema operativo y algoritmos de encriptación de datos. La arquitectura del IDS es centralizado, basado en monitoreo de integridad y de respuesta pasiva; la flexibilidad de la herramienta permite, la adecuación de los niveles de riesgo y la configuración de los directorios dependiente del sistema que se desea monitorear. Es escalable dentro de un entorno de red, su diseño le permite agregar nuevos usuarios de manera sencilla. El tiempo en que se realiza el análisis del cliente de DAYUSOL depende directamente de la infraestructura donde se implemente el sistema, son fundamentales en este aspecto, la velocidad del procesador, la capacidad de memoria RAM, el volumen de información analizado y el tráfico en la red.

Capitulo 6. Conclusiones y trabajos a futuro.

112

Los tiempos entregados por los clientes actuales, muestran una rápida velocidad en la detección de modificaciones, se puede conocer el estado de un equipo de acuerdo al número de elementos y el riesgo que éstos representan para la seguridad del sistema. Dejando al administrador la puesta en marcha de un procedimiento de revisión de los elementos detectados y las acciones correspondientes. El sistema de respaldos, es un utilitario de DAYUSOL que puede ser implementado en un entorno con la infraestructura suficiente, es considerable el costo de un sistema de almacenamiento dedicado al respaldo de la información de los clientes, por un lado se tienen que utilizar espacios de almacenamiento bastante grandes para las copias de información comprimida, en contraparte, se debe estimar el valor de la información y la sensibilidad que representa la pérdida de este elemento. Debido a nuestras limitaciones de hardware, no se habilitó esta capacidad para todos los usuarios, pero se comprobó su correcta aplicación para los directorios de restauración del sistema y se reporto su funcionamiento en el capitulo 5. Los beneficios obtenidos de la aplicación de este trabajo de investigación se pueden resumir en que DAYUSOL realiza la detección de intrusos, cumple satisfactoriamente con proporcionar estadísticas del estado de los equipos clientes, generar reportes individuales de los elementos detectados en cada análisis, permitir un conocimiento oportuno, práctico y fiable al administrador del sistema operativo Linux.

6.2. Trabajos a futuro Las capacidades de DAYUSOL han sido expuestas a lo largo de esta investigación; no obstante es posible agregar funcionalidad o compatibilidad con otros sistemas Linux.

• Extender la funcionalidad de la herramienta para transladar los archivos de configuración de los equipos clientes al servidor y poder determinar cual fue el cambio realizado, sobre todo en lo referente a los puertos y servicios.

• Otro desarrollo propuesto es la creación de un sistema que permita la búsqueda en internet o la descripción de cada uno de los elementos encontrados durante el análisis; es común actualizar sistemas y encontrar un volumen muy grande de archivos detectados, la capacidad de determinar si es un elemento permitido o no recae en el administrador; contando con una base de datos descriptora de características de los archivos, se reduciría la carga de trabajo del administrador durante las tareas de actualización e instalación de paquetes.

• La inclusión del esquema obtenido en DAYUSOL con el servicio de directorios implementado para la restricción, autenticación y validación de clientes en un entorno de red de servicios distribuidos.

Bibliografía

113

BIBLIOGRAFÍA

[1] Bandel David A, Linux Security Toolkit. Met Books. Estados Unidos 2000.

[2] Departamento de informática. Estado del arte: Sistemas de Detección

de Intrusos. Mondragón Escuela Politécnica Superior, 2004.

[3] Contador de Linux, Linux Counter Machine Report.

http://i18n.counter.li.org

[4] Proctor Paul E., Practical Intrusion Detection Handbook. Prentice Hall Hispanoamericana S.A. México 2005.

[5] Garnacho A. Ribagorda & Gallardo Ortiz M. Angel, Seguridad en Unix

Sistemas abiertos e Internet. Editorial Paraninfo, 1996.

[6] Korn Peter, Maxima Seguridad en Linux.

Editorial McGraw Hill 2004.

[7] Baluja García Walter, Los sistemas detectores de intrusos. Instituto Superior Politécnico José Antonio Echeverría. Facultad de ingeniería Eléctrica, Ciudad de la Habana, Cuba 2005.

[8] Zurita Rafael Ignacio, Auditoria de seguridad.

Universidad Nacional del Comahue, Facultad de Economía y Administración, Licenciatura en Ciencias de la Computación. Buenos Aires, Argentina, Mayo 2001.

[9] Anónimo. Linux Hacker.

MacGraw Hill Mexico 2002.

[10] Villalón Huerta Antonio, Seguridad en Unix y redes. Versión 1.2, México 2000.

[11] Snort. Open source network intrusion prevention and detection system. http://www.snort.org/

[12] Tripwire. Change Management & Auditing

http://www.tripwire.com/

[13] Inotify. Monitor Linux file system events with inotify http://www.kernel.org/pub/linux/kernel/people/rml/inotify/README

[14] Bace Rebecca & Mell Peter. NIST Special Publication on Intrusion

Detection Systems Intrusion Detection Systems.2003. National Institute of Standards and Technology. Computer Security

Division

Bibliografía

114

[15] Garfinkel Simson, Spafford Gene and Shwartz Alan, Practical unix & internet security. O’Reilly. Tercera Edición 2003.

[16] Cheswick B. and Bellovin S., Firewalls and Internet Security: Repelling

the Wily Hacker. Addison-Wesley, Estados Unidos 1994

[17] Lehtinen Rick, Rusell Deborah and Gangemi G.T., Computer Security

Basics. Editorial O´Reilly, Estados Unidos 2006.

[18] Nombela Juan Jose, Seguridad Informática.

Praninfo y Thomson Editores España 1997.

[19] Hatch Brian and Lee James, Secretos y soluciones para la seguridad de Linux, Hackers en Linux. Mc Graw Hill /Interamericana de España 2004.

[20] Stamp Mark, Information Security, Pinciples and Practice.

Wiley -interscience 2006.

[21] McClure Stuart, Scambray Joel y Kurtz George. Hackers, Secretos y soluciones para la seguridad de redes. Osborne, McGraw-Hill 2000.

[22] Barret Daniel J. and Silverman Richard E., SSH The Secure Shell The

Definitive Guide. O´Reilly, Estados Unidos 2001.

[23] Escamilla Terry, Intrusion Detection: Network security beyond the

firewall. Wiley Computer Publishing 1998.

[24] Stallings William, Operating Systems.

Second Edition. Prentice Hall. 2004

[25] McCarty Bill. Learning Debian GNU/Linux. O’Reilly Estados Unidos 1999.

[26] Linux.org. A free Unix-type operative system.

http://www.linux.org

[27] GNU. Fundacion para el software libre (FSF). http://www.gnu.org/home.es.html

[28] Tansley David, Linux and Unix Shell Programming.

Addison-Wesley Pearson Education 2000.

[29] Northcutt Stephen, Cooper Mark, Fearnow Matt and Frederick Karen, Intrusion Signatures and Analisis. New Riders Publishing 2001.

Bibliografía

115

[30] Ristic Ivan, Apache Security. O´Reilly, Estados Unidos 2005.

[31] Stones Richard and Matthew Neil, Beginning Linux Programming.

2nd Edition. Wrox Press Ltd. 1999.

[32] Larman Craig, UML y patrones, Introduccion al analisis y diseño orientado a objetos. Prentice Hall primera edicion 1999.

[33] Quigley Ellie, Linux Shells By Examples.

Prentice Hall Estados Unidos 2000.

[34] Newham Cameron and Rosenblatt Bill, Learning the Bash Shell. Editorial O´Reilly. Estados Unidos 1998.

[35] Sklar David and Trachtenberg Adam, PHP Coookbook 2nd Edition.

Editorial O´Reilly, Estados Unidos 2006.

[36] Sanchez Sebastián, Unix y Linux Guía Práctica. Editorial Alfaomega, 2000.

[37] Gilmore W. Jason, Beginning PHP and MySQL 5 From novice to

professional. Editorial Appres 2006.

[38] Mako Hill Benjamin, Harris David B. and Vyas Jaldhar, Debian

GNU/Linux 3.1 Bible. Wiley Publishing, Estados Unidos 2005.

[39] CERT. Computer Emergency Response Team. http://www.cert.org/cert/

Bibliografía

116

GLOSARIO Autenticación. Métodos o técnicas implementadas para la determinación de la identidad de un recurso informático, se hace uso de técnicas de conocimiento, posesión de algún elemento o resolución de un desafío para comprobar que la entidad es quien dice ser. Autorización. Definición granular de permisos de acceso concedidos a un determinado usuario, dispositivo o sistema, habitualmente implementado mediando listas de control de acceso (ACL). Base Segura de Cómputo. Estructura de elementos que conforman una referencia para los elementos de control de acceso, integridad de información y los IDS. Implementado como la plataforma de los sistemas de monitoreo y auditoria, Blowfish. Codificador de bloques simétricos, diseñado por Bruce Schneier en 1993 e incluido en un gran número de conjuntos de codificadores y productos de cifrado Cifrado. Técnicas que permiten la secrecía de la información utilizando métodos matemáticos, que proporcionan la ocultación de la información para usuarios no autorizados. La capacidad de los algoritmos de cifrado es dependiente de la capacidad de cómputo que se tenga y el tiempo empleado para su ruptura. Caballo de Troya. Programa que aparentemente, o realmente, ejecuta una función útil, pero oculta un subprograma dañino que abusa de los privilegios concedidos para la ejecución del citado programa. Cifrado. Transformación criptográfica de datos para producir un criptograma o texto cifrado. El cifrado puede ser irreversible, en cuyo caso no puede realizarse el proceso de descifrado correspondiente Colisión. Situación que se produce cuando una función hash, operando sobre entradas distintas, genera una misma salida. Puede ser de dos tipos:

• Débil: Cuando dado un mensaje se encuentra otro que produce el mismo hash. • Fuerte: Cuando se encuentra una pareja de mensajes que producen el mismo

hash. CRC. Código de redundancia cíclica, técnicas de cifrado por medio de bloques de manera recursiva, el tamaño de los bloques puede ser de 16 o 32 bits DAC. Discretionary Access Control, Control de acceso discrecional. Debian. Distribución de Sistema Operativo Linux diseñada para servidores, la versión más reciente es nombrada Edgy y corresponde a la versión número 4. Detección de sucesos. Capacidad para la percepción tanto de acciones normales como de aparente violación de un sistema de información Función hash o Función resumen (digest). Función de un solo sentido que calcula, a partir de una cadena de bits de longitud arbitraria, otra, aparentemente aleatoria, de longitud fija.

Bibliografía

117

Gusano. Es un programa similar a un virus que se diferencia de éste en su forma de realizar las infecciones. Mientras que los virus intentan infectar a otros programas copiándose dentro de ellos, los gusanos realizan copias de ellos mismos, infectan a otros ordenadores y se propagan automáticamente en una red independientemente de la acción humana. Huella digital. Se denomina al elemento entregado por un algoritmo de cifrado en bloques, el cual realizará la función resumen de un archivo. Permite la identificación de la integridad del contenido de un archivo. Información sensible. Aquella, así definida por su propietario, que debe ser especialmente protegida, pues si revelación, alteración, pérdida o destrucción puede producir daños importantes a alguien o algo. IPv4. Internet Protocol v4, protocolo de internet versión 4, elemento que permite la comunicación de equipos en un entorno de red. Dependiente de la pila de protocolos TCP/IP, esta capa proporciona los elementos de enrutamiento, la versión se caracteriza por utilizar un conjunto de 28 bits para la identificación de los equipos. IPv6. Internet Protocol v6, protocolo de internet versión 6, sustituye al protocolo versión 4, incrementa funcionalidades de seguridad y calidad del servicio, la identificación del equipo se realiza por agrupamientos de 128 bits. IDS. Sistema Detector de Intrusos, agente informático que permite identificar elementos considerados un riesgo o anomalía del funcionamiento del equipo. Implementan diversas técnicas para la identificación de intrusos y se clasifican principalmente en los de red y los de host. LDAP (Lightweight Directory Access Protocol). Es un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos (aunque su sistema de almacenamiento puede ser diferente) al que pueden realizarse consultas. Es un protocolo de acceso unificado a un conjunto de información sobre una red. Linux. Núcleo del sistema operativo basado en la plataforma UNIX, se denomina a los Sistemas que utilizan el kernel desarrollado por Linus Torvalds en la década de los 90s. MD5. Algoritmo de cifrado en bloques, genera un resumen único de tamaño fijo de un archivo. Objetivo de seguridad. Declaración de la intención de contrarrestar las amenazas identificadas y/o de cumplir las políticas e hipótesis de seguridad identificadas de la organización Penetración. Violación de un sistema de seguridad, lo que permite acceder a los recursos supuestamente protegidos. Política de seguridad basada en reglas. Política de seguridad basada en reglas globales impuestas a todos los usuarios. Estas reglas suelen depender de una comparación de la sensibilidad de los recursos a los que se accede con los atributos correspondientes de los usuarios, de un grupo de usuarios o de entidades que actúan en nombre de los usuarios

Bibliografía

118

SHA-1. Algoritmo hash diseñado por el National Institute for Standards and Technology (NIST) y la National Security Agency (NSA) estadounidense para aplicaciones gubernamentales que emplean el algoritmo de firma digital DSA. Proporciona una salida de 160 bits y basa su diseño en la función MD4. Scheduler. Panificador de CPU, modulo del sistema operativo que se encarga de la modificación del estado de los procesos y la programación de la ejecución de acuerdo a la prioridad y los tipos de ejecución que implementa Shell. Capa de la estructura del sistema operativo Linux que permite la comunicación entre las aplicaciones y el núcleo o kernel. Permite la realización de labores como la modificación de la estructura de directorios, procesos o recursos, su interfaz con el usuario es la línea de comandos, nivel desde el cual el usuario puede ejecutar programas o comandos propios de cada distribución. SSH cliente (Secure Shell client). Cliente de shell seguro. Equipo que obtiene recursos de un servidor implementando un canal seguro, técnicas de cifrado y autenticación entre ambas entidades. Se utiliza principalmente para realizar tareas administrativas de manera remota en los servidores. Implementan técnicas de autenticación por password, frase encriptada o esquemas de llave pública. SSH servidor (Secure Shell client). Servidor de Shell seguro. Equipo que proporciona recursos a un cliente remoto mediante un canal seguro. Actualmente se utiliza la versión 2 del protocolo SSH. UBUNTU. Distribución de Sistema Operativo Linux, cuenta con versiones para escritorio, servidores y de tipo educativo. Se ejecuta con entornos gráficos KDE y Gnome, debido a su facilidad de instalación y configuración de hardware, es actualmente la versión más utilizada en el mundo.

Anexo 1. Manual de usuario.

119

ANEXO 1. MANUAL DE USUARIO.

La implementación de la metodología presentada en esta tesis fue denominada DAYUSOL, el entorno donde se implemento la herramienta es una red de área local, por lo que se omite la descripción de configuración de las interfaces de red y los equipos de conmutación.

� Instalación El entorno debe cumplir con las recomendaciones de la implementación presentadas en el capitulo 4, se requiere contar con un mínimo de 2 equipos.

• Equipo 1. Servidor DAYUSOL: Interfaz de red configurada para trabajo en red (IP fija) Sistema operativo Linux

• Desde la línea de comandos se puden agregar los paquetes necesarios en esta

etapa. Se requiere instalas el servidor Apache2, los módulos correspondientes para la integración con PHP y MYSQL además de cliente de SSH, también se puede utilizar cualquier gestor de paquetes disponible en Linux.

• Equipo 2. Cliente: Cliente DAYUSOL: Interfaz de red configurada para trabajo en red (IP fija) Sistema operativo Linux. En cada uno de los clientes que se desee ejecutar análisis de DAYUSOL se debe instalar el servidor de SSH. Se puede realizar desde la línea de comandos o desde el gestor de paquetes. Se requiere la generación de una llave pública y una llave privada, en nuestro caso se hace uso de una llave de tipo RSA, por lo que se procede a generarlas

� Configuración de SSH

1. Se generan un par de claves de tipo RSA en el cliente (ssh-keygen) 2. El sistema solicita una frase que servirá de semilla para la generación de llaves

• Esta frase será requerida siempre que se pida el uso de la llave, puesto que es la base de la encriptación.

• Se puede dejar en blanco la frase, lo que generara una llave que no está encriptada. El riesgo de no encriptar el elemento tiene como ventaja la automatización de las conexiones.

3. El sistema entrega una llave pública y una llave privada en el directorio del usuario para el que fueron creadas.

• id_rsa es la llave privada. • id_rsa.pub es la llave pública.

Anexo 1. Manual de usuario.

120

• known_hosts son las claves públicas de los servidores conocidos. 4. Cambiar los permisos a estos archivos para evitar que sean modificados, dejando la lectura y escritura sólo para el usuario. 5. Copiar la llave pública en el servidor que se va a conectar.

• La llave pública debe almacenarse en el directorio del cliente al que se desea conectar. En nuestro caso el usuario es root, por lo que la llave pública deberá quedar almacenada en /root/.ssh/ known_hosts

6. Almacenar la llave privada en un lugar del directorio con seguridad suficiente para evitar su robo

� Configuración del servidor DAYUSOL. El servidor deberá crear automáticamente la estructura d directorio de cada uno de los clientes, por lo que es necesario realizar una ejecución de análisis de manera manal. Se puede copiar el archivo basicas.pol de políticas que viene con la aplicación y que tiene las características de Tipwire para la determinación de reglas. Es necesario modificar los parámetros del cliente en la sección correspondiente del archivo básicas.pol. Se debe colocar la ruta donde será almacenada la estructura del cliente y la ip asignada al equipo #Archivo de Políticas del cliente DAYUSOL # Crear definiciones # Directorio de datos de los usuarios DEFINE HOME /home/dayusol/usuarios # IP o Hostname auditado DEFINE TARGET 192.168.1.1

Realizada la configuración correspondiente al archivo de políticas, se procede a la generación del usuario en la base de datos, se deben llenar campos muy básicos con la información que describan al cliente de DAYUSOL y permitan el almacenamiento de su información. Se puede utilizar en este punto una interfaz que facilite este trabajo, en nuestro caso se utilizo Phpmyadmin, se muestra en la figura los campos necesarios para agregar un nuevo cliente mediante este método. Se puede hacer uso del programa clientebase.php, el cual puede ser empleado desde la línea de comandos y deberá ser configurado con los parámetros necesarios para generar al cliente tales como. $clientemysql= “nombre”; $passwdmysql=”passwd”; $base =”DAYUSOL” $clienteDAYUSOL= 20; $ipcliente= 192.168.1.20; $hostname = “Alex-lap-hp”; $descripcion = “'Equipo portatil cliente de DAYUSOL”;

Desde la línea de comandos se deberá teclear:

php clientebase.php

Anexo 1. Manual de usuario.

121

Este procedimiento se repite para la inclusión de cada uno de los clientes de DAYUSOL. Por ultimo, se debe programar la ejecución de tareas mediante el demonio cron del sistema, se debe generar en el directorio /etc/cron.d un archivo llamado DAYUSOL, el cual contenga en cada línea una programación del análisis de cada uno de los clientes. El contenido del archivo debe quedar como se muestra en el ejemplo:

� Reportes de clientes de DAYUSOL La herramienta solo requiere de un navegador web para desplegar la información, por lo que se puede utilizar cualquiera de estos elementos que se tengan, se recomienda restringir el acceso al equipo servidor DAYUSOL para el servidor web y solo sea consultado de manera local. En el navegador se debe colocar lo siguiente en el url:

http://localhost/dayusol/REPORTERED.php

Con lo que se desplegara la información disponible de todos los clientes actuales de DAYUSOL. La información resumida de los clientes se presenta en una tabla en la parte inferior de la pagina web, El vinculo de la pagina nos permite mostrar la información detallada del equipo cliente, enviándonos directamente a la pagina REPORTEHOST que nos muestra la información de los elementos detectados por DAYUSOL para un solo cliente.

REPORTE DE RED

Anexo 1. Manual de usuario.

122

REPORTE DE HOST

La pagina de reporte del host muestra un resumen de los elementos detectados

clasificada de acuerdo a la estructura y al los compendios. Las tablas situadas en la parte

inferior permiten mostrar los elementos agrupados de acuerdo al nivel de riesgo. Los

vinculos , y nos permiten navegar a la pagina REPORTE DETALLADO

en la que se pueden apreciar los datos específicos de todas las intrusiones detectadas,

agrupadas en tablas por directorios. Cada vínculo muestra todos los elementos

detectados por nivel de riesgo.

Anexo 2. Políticas y código fuente.

123

ANEXO 2. POLITICAS Y CODIGO FUENTE.

GENERACION DE POLITICAS La estructura de cada política por directorio es la siguiente: ETIQUETA EN EL REPORTE LABEL \n5 000 E UID-GUI Archivos con el bit uid or gid en el cliente pertenecen a root Etiqueta para el reporte LABEL \n- Nivel de riesgo 5 Directorio 000 Tipo de elemento E. Estructura de archivo / H.Compendio Descripción del elemento UID-GUI Archivos con el bit.

RUTA Y NOMBRE DE ARCHIVO DE ALMACENAMIENTO CHECK ${ALTO}/estructura.ejecutables Directorio dentro del cliente ${ALTO} Nombre de archivo /estructura.ejecutables CRITERIO DE BUSQUEDA Y ACCION /usr/bin/find / -xdev -perm +6111 -type f -printf "%m %n %u %g %s %p\n" Comando /usr/bin/find Directorio de búsqueda / Criterio de búsqueda -xdev -perm +6111 -type f Acción para elementos -printf "%m %n %u %g %s %p\n" Encontrados

POLITICAS DE PRUEBA DE RECONOCIMIENTO. La política que se muestra a continuación fue aplicada a los clientes de DAYUSOL durante las pruebas de reconocimiento de modificaciones, se revisan todos los archivos del sistema excepto los del directorio /proc. Esta política sirve para hacer las pruebas en el sistema cuando se modifican los archivos y para la prueba de instalación de paquetes con APT.

Cliente Router 192.168.1.1

###################################################################### #Archivo de Políticas del cliente DAYUSOL # Crear definiciones # Directorio de datos de los usuarios DEFINE HOME /home/dayusol/usuarios # IP o Hostname auditado DEFINE TARGET 192.168.1.1 #Riesgos de seguridad # 9 PAQUETES # 5 ALTO # 3 MEDIO # 1 BAJO DEFINE ALTO ALTO DEFINE MEDIO MEDIO DEFINE BAJO BAJO

Anexo 2. Políticas y código fuente.

124

#Define los directorios a examinar # 000 / uid o guid root # 010 /bin # 020 /boot # 030 /etc # 040 /usr # 050 /dev # 060 /lib # 070 /mnt # 080 /opt # 090 /var # 100 /home # 110 /proc # 120 /sbin # 130 /media # 140 /custom # 150 /user # Establecer variables personales # Directorio de Usuario analizado USE BASE ${HOME}/${TARGET} # Definicion de ssh-key para la conexion DEFINE CLIENT root@${TARGET} # Conectarse al cliente mediante ssh USE SSH /usr/bin/ssh root@${TARGET} -q ############################################## # Traer y revisar el md5sum y sus librerias # desde el cliente y revisarlas localmente. ############################################## LOCAL mkdir -p tmp # Crear directorio temporal LOCAL scp ${CLIENT}:/usr/bin/md5sum tmp # Copiar md5sum LOCAL scp ${CLIENT}:/lib/libc.so.6 tmp # y sus librerias LOCAL scp ${CLIENT}:/lib/ld-linux.so.2 tmp ##################################################### # Revisar la integridad de los archivos descargados # Y si es satisfactoria usar md5sum del cliente ##################################################### LABEL \nRevision de el programa md5sum y sus librerias LOCAL CHECK local/md5sum /usr/bin/md5sum tmp/* LOCAL rm -rf tmp # Borrar los archivos temporales ######################################################## # Generar la estructura. # Revisar todos los archivos ejecutables en el equipo cliente ######################################################## LABEL \n5 000 E UID-GUI Archivos con el bit uid or gid en el cliente pertenecen a root CHECK ${ALTO}/estructura.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -printf "%m %n %u %g %s %p\n" LABEL \n5 000 H UID-GUI HASH Archivos con el bit uid or guid en el cliente pertenecen a root CHECK ${ALTO}/HASH.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -exec /usr/bin/md5sum {} \;

Anexo 2. Políticas y código fuente.

125

######################################################## # Revisar los archivos no ejecutables riesgo alto # ######################################################## #Archivos en el directorio /bin LABEL \n5 010 E Estructura de archivos en /bin CHECK ALTO/estructura.bin \ /usr/bin/find /bin -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 010 H Funcion de integridad en /bin CHECK ALTO/HASH.bin \ /usr/bin/find /bin -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /boot LABEL \n5 020 E Estructura de archivos en /boot CHECK ALTO/estructura.boot \ /usr/bin/find /boot -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 020 H Funcion de integridad en /boot CHECK ALTO/HASH.boot \ /usr/bin/find /boot -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /etc LABEL \n5 030 E Estructura de archivos en /etc CHECK ALTO/estructura.etc \ /usr/bin/find /etc -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 030 H Funcion de integridad en /etc CHECK ALTO/HASH.etc \ /usr/bin/find /etc -type f -not -perm +111-exec /usr/bin/md5sum {} \; # Archivos en el directorio /etc # LABEL \n5 031 E Estructura de archivos en /etc # CHECK ALTO/estructura.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -printf "%m %n %u %g %s %p\n" # LABEL \n5 031 H Funcion de integridad en /etc # CHECK ALTO/md5.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -exec /usr/bin/md5sum {} \; # #Archivos en el directorio /usr LABEL \n5 040 E Estructura de archivos en /usr CHECK ALTO/estructura.usr \ /usr/bin/find /usr -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 040 H Funcion de integridad en /boot CHECK ALTO/HASH.usr \ /usr/bin/find /usr -type f -not -perm +111-exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/local ## Archivos en el directorio /usr/share # Archivos en el directorio /usr/X11R6/lib #LABEL \n5 041 E Estructura de archivos en /usr/X11R6/lib #CHECK ALTO/estructura.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -printf "%m %n %u %g %s %p\n" #LABEL \n5 041 H Funcion de integridad en /usr.X11R6/lib #CHECK ALTO/md5.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \

Anexo 2. Políticas y código fuente.

126

# -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/lib #LABEL \n5 042 E Estructura de archivos en /usr/lib #CHECK ALTO/estructura.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 \ # -printf "%m %n %u %g %s %p\n" #LABEL \n5 042 H Funcion de integridad en /usr/lib #CHECK ALTO/md5.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/sbin # Archivos en el directorio /lib LABEL \n5 060 E Estructura de archivos en /lib CHECK MEDIO/estructura.lib \ /usr/bin/find /lib -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 060 H Funcion de integridad en /lib CHECK MEDIO/HASH.lib \ /usr/bin/find /lib -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /sbin LABEL \n5 120 E Estructura de archivos en /sbin CHECK MEDIO/estructura.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 120 H Funcion de integridad en /sbin CHECK MEDIO/HASH.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo medio # ######################################################## #Archivos en el directorio /dev LABEL \n3 050 E Estructura de archivos en /dev CHECK MEDIO/estructura.dev \ /usr/bin/find /dev -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n3 050 H Funcion de integridad en /dev CHECK MEDIO/HASH.dev \ /usr/bin/find /dev -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /mnt LABEL \n3 070 E Estructura de archivos en /mnt CHECK MEDIO/estructura.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 070 H Funcion de integridad en /mnt CHECK MEDIO/HASH.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /opt LABEL \n3 080 E Estructura de archivos en /opt CHECK MEDIO/estructura.opt \ /usr/bin/find /opt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 080 H Funcion de integridad en /opt CHECK MEDIO/HASH.opt \ /usr/bin/find /opt -type f -not -perm +111 -exec /usr/bin/md5sum {} \;

Anexo 2. Políticas y código fuente.

127

#Archivos en el directorio /media LABEL \n3 130 E Estructura de archivos en /media CHECK MEDIO/estructura.media \ /usr/bin/find /media -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 130 H Funcion de integridad en /media CHECK MEDIO/HASH.media \ /usr/bin/find /media -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo bajo # ######################################################## #Archivos en el directorio /var LABEL \n1 090 E Estructura de archivos en /var CHECK BAJO/estructura.var \ /usr/bin/find /var -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 090 H Funcion de integridad en /var CHECK BAJO/HASH.var \ /usr/bin/find /var -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /home LABEL \n1 100 E Estructura de archivos en /home CHECK BAJO/estructura.home \ /usr/bin/find /home -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 100 H Funcion de integridad en /home CHECK BAJO/HASH.home \ /usr/bin/find /home -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /proc #LABEL \n1 110 E Estructura de archivos en /proc #CHECK BAJO/estructura.proc \ # /usr/bin/find /proc -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" #LABEL \n1 110 H Funcion de integridad en /proc #CHECK BAJO/HASH.proc \ # /usr/bin/find /proc -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revision de paquetes instalados ######################################################## LABEL \n9 REVISION DE PAQUETES INSTALADOS CHECK PAQUETES/instalados \ /usr/bin/dpkg -l '*' | grep 'ii'

Cliente Miniton 192.168.1.10

###################################################################### #Archivo de Políticas del cliente DAYUSOL # Crear definiciones # Directorio de datos de los usuarios DEFINE HOME /home/dayusol/usuarios # IP o Hostname auditado DEFINE TARGET 192.168.1.10 #Riesgos de seguridad

Anexo 2. Políticas y código fuente.

128

# 9 PAQUETES # 5 ALTO # 3 MEDIO # 1 BAJO DEFINE ALTO ALTO DEFINE MEDIO MEDIO DEFINE BAJO BAJO #Define los directorios a examinar # 000 / uid o guid root # 010 /bin # 020 /boot # 030 /etc # 040 /usr # 050 /dev # 060 /lib # 070 /mnt # 080 /opt # 090 /var # 100 /home # 110 /proc # 120 /sbin # 130 /media # 140 /custom # 150 /user # Establecer variables personales # Directorio de Usuario analizado USE BASE ${HOME}/${TARGET} # Definicion de ssh-key para la conexion DEFINE CLIENT root@${TARGET} # Conectarse al cliente mediante ssh USE SSH /usr/bin/ssh root@${TARGET} -q ############################################## # Traer y revisar el md5sum y sus librerias # desde el cliente y revisarlas localmente. ############################################## LOCAL mkdir -p tmp # Crear directorio temporal LOCAL scp ${CLIENT}:/usr/bin/md5sum tmp # Copiar md5sum LOCAL scp ${CLIENT}:/lib/libc.so.6 tmp # y sus librerias LOCAL scp ${CLIENT}:/lib/ld-linux.so.2 tmp ##################################################### # Revisar la integridad de los archivos descargados # Y si es satisfactoria usar md5sum del cliente ##################################################### LABEL \nRevision de el programa md5sum y sus librerias LOCAL CHECK local/md5sum /usr/bin/md5sum tmp/* LOCAL rm -rf tmp # Borrar los archivos temporales ######################################################## # Generar la estructura. # Revisar todos los archivos ejecutables en el equipo cliente ######################################################## LABEL \n5 000 E UID-GUI Archivos con el bit uid o gid en el cliente pertenecen a root CHECK ${ALTO}/estructura.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \

Anexo 2. Políticas y código fuente.

129

-type f -printf "%m %n %u %g %s %p\n" LABEL \n5 000 H UID-GUI HASH Archivos con el bit uid o guid en el cliente pertenecen a root CHECK ${ALTO}/HASH.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo alto # ######################################################## #Archivos en el directorio /bin LABEL \n5 010 E Estructura de archivos en /bin CHECK ALTO/estructura.bin \ /usr/bin/find /bin -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 010 H Funcion de integridad en /bin CHECK ALTO/HASH.bin \ /usr/bin/find /bin -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /boot LABEL \n5 020 E Estructura de archivos en /boot CHECK ALTO/estructura.boot \ /usr/bin/find /boot -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 020 H Funcion de integridad en /boot CHECK ALTO/HASH.boot \ /usr/bin/find /boot -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /etc LABEL \n5 030 E Estructura de archivos en /etc CHECK ALTO/estructura.etc \ /usr/bin/find /etc -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 030 H Funcion de integridad en /etc CHECK ALTO/HASH.etc \ /usr/bin/find /etc -type f -not -perm +111-exec /usr/bin/md5sum {} \; # Archivos en el directorio /etc # LABEL \n5 031 E Estructura de archivos en /etc # CHECK ALTO/estructura.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -printf "%m %n %u %g %s %p\n" # LABEL \n5 031 H Funcion de integridad en /etc # CHECK ALTO/md5.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -exec /usr/bin/md5sum {} \; # #Archivos en el directorio /usr LABEL \n5 040 E Estructura de archivos en /usr CHECK ALTO/estructura.usr \ /usr/bin/find /usr -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 040 H Funcion de integridad en /boot CHECK ALTO/HASH.usr \ /usr/bin/find /usr -type f -not -perm +111-exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/local ## Archivos en el directorio /usr/share # Archivos en el directorio /usr/X11R6/lib

Anexo 2. Políticas y código fuente.

130

#LABEL \n5 041 E Estructura de archivos en /usr/X11R6/lib #CHECK ALTO/estructura.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -printf "%m %n %u %g %s %p\n" #LABEL \n5 041 H Funcion de integridad en /usr.X11R6/lib #CHECK ALTO/md5.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/lib #LABEL \n5 042 E Estructura de archivos en /usr/lib #CHECK ALTO/estructura.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 \ # -printf "%m %n %u %g %s %p\n" #LABEL \n5 042 H Funcion de integridad en /usr/lib #CHECK ALTO/md5.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/sbin # Archivos en el directorio /lib LABEL \n5 060 E Estructura de archivos en /lib CHECK MEDIO/estructura.lib \ /usr/bin/find /lib -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 060 H Funcion de integridad en /lib CHECK MEDIO/HASH.lib \ /usr/bin/find /lib -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /sbin LABEL \n5 120 E Estructura de archivos en /sbin CHECK MEDIO/estructura.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 120 H Funcion de integridad en /sbin CHECK MEDIO/HASH.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo medio # ######################################################## #Archivos en el directorio /dev LABEL \n3 050 E Estructura de archivos en /dev CHECK MEDIO/estructura.dev \ /usr/bin/find /dev -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n3 050 H Funcion de integridad en /dev CHECK MEDIO/HASH.dev \ /usr/bin/find /dev -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /mnt LABEL \n3 070 E Estructura de archivos en /mnt CHECK MEDIO/estructura.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 070 H Funcion de integridad en /mnt CHECK MEDIO/HASH.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /opt LABEL \n3 080 E Estructura de archivos en /opt

Anexo 2. Políticas y código fuente.

131

CHECK MEDIO/estructura.opt \ /usr/bin/find /opt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 080 H Funcion de integridad en /opt CHECK MEDIO/HASH.opt \ /usr/bin/find /opt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /media LABEL \n3 130 E Estructura de archivos en /media CHECK MEDIO/estructura.media \ /usr/bin/find /media -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 130 H Funcion de integridad en /media CHECK MEDIO/HASH.media \ /usr/bin/find /media -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo bajo # ######################################################## #Archivos en el directorio /var LABEL \n1 090 E Estructura de archivos en /var CHECK BAJO/estructura.var \ /usr/bin/find /var -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 090 H Funcion de integridad en /var CHECK BAJO/HASH.var \ /usr/bin/find /var -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /home LABEL \n1 100 E Estructura de archivos en /home CHECK BAJO/estructura.home \ /usr/bin/find /home -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 100 H Funcion de integridad en /home CHECK BAJO/HASH.home \ /usr/bin/find /home -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /proc #LABEL \n1 110 E Estructura de archivos en /proc #CHECK BAJO/estructura.proc \ # /usr/bin/find /proc -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" #LABEL \n1 110 H Funcion de integridad en /proc #CHECK BAJO/HASH.proc \ # /usr/bin/find /proc -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revision de paquetes instalados ######################################################## LABEL \n9 REVISION DE PAQUETES INSTALADOS CHECK PAQUETES/instalados \ /usr/bin/dpkg -l '*' | grep 'ii'

Cliente Alexin 192.168.1.11

###################################################################### #Archivo de Políticas del cliente DAYUSOL

Anexo 2. Políticas y código fuente.

132

# Crear definiciones # Directorio de datos de los usuarios DEFINE HOME /home/dayusol/usuarios # IP o Hostname auditado DEFINE TARGET 192.168.1.11 #Riesgos de seguridad # 9 PAQUETES # 5 ALTO # 3 MEDIO # 1 BAJO DEFINE ALTO ALTO DEFINE MEDIO MEDIO DEFINE BAJO BAJO #Define los directorios a examinar # 000 / uid o guid root # 010 /bin # 020 /boot # 030 /etc # 040 /usr # 050 /dev # 060 /lib # 070 /mnt # 080 /opt # 090 /var # 100 /home # 110 /proc # 120 /sbin # 130 /media # 140 /custom # 150 /user # Establecer variables personales # Directorio de Usuario analizado USE BASE ${HOME}/${TARGET} # Definicion de ssh-key para la conexion DEFINE CLIENT root@${TARGET} # Conectarse al cliente mediante ssh USE SSH /usr/bin/ssh root@${TARGET} -q ############################################## # Traer y revisar el md5sum y sus librerias # desde el cliente y revisarlas localmente. ############################################## LOCAL mkdir -p tmp # Crear directorio temporal LOCAL scp ${CLIENT}:/usr/bin/md5sum tmp # Copiar md5sum LOCAL scp ${CLIENT}:/lib/libc.so.6 tmp # y sus librerias LOCAL scp ${CLIENT}:/lib/ld-linux.so.2 tmp ##################################################### # Revisar la integridad de los archivos descargados # Y si es satisfactoria usar md5sum del cliente ##################################################### LABEL \nRevision de el programa md5sum y sus librerias LOCAL CHECK local/md5sum /usr/bin/md5sum tmp/* LOCAL rm -rf tmp # Borrar los archivos temporales ########################################################

Anexo 2. Políticas y código fuente.

133

# Generar la estructura. # Revisar todos los archivos ejecutables en el equipo cliente ######################################################## LABEL \n5 000 E UID-GUI Archivos con el bit uid o gid en el cliente pertenecen a root CHECK ${ALTO}/estructura.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -printf "%m %n %u %g %s %p\n" LABEL \n5 000 H UID-GUI HASH Archivos con el bit uid o guid en el cliente pertenecen a root CHECK ${ALTO}/HASH.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo alto # ######################################################## #Archivos en el directorio /bin LABEL \n5 010 E Estructura de archivos en /bin CHECK ALTO/estructura.bin \ /usr/bin/find /bin -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 010 H Funcion de integridad en /bin CHECK ALTO/HASH.bin \ /usr/bin/find /bin -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /boot LABEL \n5 020 E Estructura de archivos en /boot CHECK ALTO/estructura.boot \ /usr/bin/find /boot -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 020 H Funcion de integridad en /boot CHECK ALTO/HASH.boot \ /usr/bin/find /boot -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /etc LABEL \n5 030 E Estructura de archivos en /etc CHECK ALTO/estructura.etc \ /usr/bin/find /etc -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 030 H Funcion de integridad en /etc CHECK ALTO/HASH.etc \ /usr/bin/find /etc -type f -not -perm +111-exec /usr/bin/md5sum {} \; # Archivos en el directorio /etc # LABEL \n5 031 E Estructura de archivos en /etc # CHECK ALTO/estructura.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -printf "%m %n %u %g %s %p\n" # LABEL \n5 031 H Funcion de integridad en /etc # CHECK ALTO/md5.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -exec /usr/bin/md5sum {} \; # #Archivos en el directorio /usr LABEL \n5 040 E Estructura de archivos en /usr CHECK ALTO/estructura.usr \ /usr/bin/find /usr -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 040 H Funcion de integridad en /boot CHECK ALTO/HASH.usr \ /usr/bin/find /usr -type f -not -perm +111-exec /usr/bin/md5sum {} \;

Anexo 2. Políticas y código fuente.

134

## Archivos en el directorio /usr/local ## Archivos en el directorio /usr/share # Archivos en el directorio /usr/X11R6/lib #LABEL \n5 041 E Estructura de archivos en /usr/X11R6/lib #CHECK ALTO/estructura.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -printf "%m %n %u %g %s %p\n" #LABEL \n5 041 H Funcion de integridad en /usr.X11R6/lib #CHECK ALTO/md5.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/lib #LABEL \n5 042 E Estructura de archivos en /usr/lib #CHECK ALTO/estructura.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 \ # -printf "%m %n %u %g %s %p\n" #LABEL \n5 042 H Funcion de integridad en /usr/lib #CHECK ALTO/md5.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/sbin # Archivos en el directorio /lib LABEL \n5 060 E Estructura de archivos en /lib CHECK MEDIO/estructura.lib \ /usr/bin/find /lib -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 060 H Funcion de integridad en /lib CHECK MEDIO/HASH.lib \ /usr/bin/find /lib -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /sbin LABEL \n5 120 E Estructura de archivos en /sbin CHECK MEDIO/estructura.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 120 H Funcion de integridad en /sbin CHECK MEDIO/HASH.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo medio # ######################################################## #Archivos en el directorio /dev LABEL \n3 050 E Estructura de archivos en /dev CHECK MEDIO/estructura.dev \ /usr/bin/find /dev -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n3 050 H Funcion de integridad en /dev CHECK MEDIO/HASH.dev \ /usr/bin/find /dev -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /mnt LABEL \n3 070 E Estructura de archivos en /mnt CHECK MEDIO/estructura.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 070 H Funcion de integridad en /mnt CHECK MEDIO/HASH.mnt \

Anexo 2. Políticas y código fuente.

135

/usr/bin/find /mnt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /opt LABEL \n3 080 E Estructura de archivos en /opt CHECK MEDIO/estructura.opt \ /usr/bin/find /opt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 080 H Funcion de integridad en /opt CHECK MEDIO/HASH.opt \ /usr/bin/find /opt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /media LABEL \n3 130 E Estructura de archivos en /media CHECK MEDIO/estructura.media \ /usr/bin/find /media -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 130 H Funcion de integridad en /media CHECK MEDIO/HASH.media \ /usr/bin/find /media -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo bajo # ######################################################## #Archivos en el directorio /var LABEL \n1 090 E Estructura de archivos en /var CHECK BAJO/estructura.var \ /usr/bin/find /var -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 090 H Funcion de integridad en /var CHECK BAJO/HASH.var \ /usr/bin/find /var -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /home LABEL \n1 100 E Estructura de archivos en /home CHECK BAJO/estructura.home \ /usr/bin/find /home -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 100 H Funcion de integridad en /home CHECK BAJO/HASH.home \ /usr/bin/find /home -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /proc #LABEL \n1 110 E Estructura de archivos en /proc #CHECK BAJO/estructura.proc \ # /usr/bin/find /proc -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" #LABEL \n1 110 H Funcion de integridad en /proc #CHECK BAJO/HASH.proc \ # /usr/bin/find /proc -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revision de paquetes instalados ######################################################## LABEL \n9 REVISION DE PAQUETES INSTALADOS CHECK PAQUETES/instalados \ /usr/bin/dpkg -l '*' | grep 'ii'

Anexo 2. Políticas y código fuente.

136

POLITICAS DE PRUEBA DE INTRUSIONES. La política que se muestra a continuación fue aplicada a los clientes de DAYUSOL durante las pruebas de intrusiones, se revisan todos los archivos de riesgo ALTO, las políticas para los deriesgo MEDIO y de riesgo BAJO se describen en la tabla 4.9, no se implemento la revisión del directorio /proc. Esta política sirve para hacer las pruebas en el sistema para detectar intrusiones. Se detalla la aplicada al sistema Router pero la misma fue aplicada a todos los elementos clientes de DAYUSOL.

Cliente Router 192.168.1.1

###################################################################### #Archivo de Políticas del cliente DAYUSOL # Crear definiciones # Directorio de datos de los usuarios DEFINE HOME /home/dayusol/usuarios # IP o Hostname cliente DAYUSOL DEFINE TARGET 192.168.1.1 #Riesgos de seguridad # 9 PAQUETES # 7 RESPALDO # 5 ALTO # 3 MEDIO # 1 BAJO DEFINE ALTO ALTO DEFINE MEDIO MEDIO DEFINE BAJO BAJO #Define los directorios a examinar # 000 / uid o guid root # 010 /bin # 020 /boot # 030 /etc # 040 /usr # 050 /dev # 060 /lib # 070 /mnt # 080 /opt # 090 /var # 100 /home # 110 /proc # 120 /sbin # 130 /media # 140 /custom # 150 /user # Establecer variables personales # Directorio de Usuario analizado USE BASE ${HOME}/${TARGET} # Definicion de ssh-key para la conexion DEFINE CLIENT root@${TARGET} # Conectarse al cliente mediante ssh USE SSH /usr/bin/ssh root@${TARGET} -q ############################################## # Traer y revisar el md5sum y sus librerias # desde el cliente y revisarlas localmente. ############################################## LOCAL mkdir -p tmp # Crear directorio temporal

Anexo 2. Políticas y código fuente.

137

LOCAL scp ${CLIENT}:/usr/bin/md5sum tmp # Copiar md5sum LOCAL scp ${CLIENT}:/lib/libc.so.6 tmp # y sus librerias LOCAL scp ${CLIENT}:/lib/ld-linux.so.2 tmp ##################################################### # Revisar la integridad de los archivos descargados # Y si es satisfactoria usar md5sum del cliente ##################################################### LABEL \nRevision de el programa md5sum y sus librerias LOCAL CHECK local/md5sum /usr/bin/md5sum tmp/* LOCAL rm -rf tmp # Borrar los archivos temporales ######################################################## # Generar la estructura. # Revisar todos los archivos ejecutables en el equipo cliente ######################################################## LABEL \n5 000 E UID-GUI Archivos con el bit uid or gid en el cliente pertenecen a root CHECK ${ALTO}/estructura.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -printf "%m %n %u %g %s %p\n" LABEL \n5 000 H UID-GUI HASH Archivos con el bit uid or guid en el cliente pertenecen a root CHECK ${ALTO}/HASH.ejecutables \ /usr/bin/find / -xdev -perm +6111 \( -user root -o -group root \) \ -type f -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo alto # ######################################################## #Archivos en el directorio /bin LABEL \n5 010 E Estructura de archivos en /bin CHECK ALTO/estructura.bin \ /usr/bin/find /bin -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 010 H Funcion de integridad en /bin CHECK ALTO/HASH.bin \ /usr/bin/find /bin -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /boot LABEL \n5 020 E Estructura de archivos en /boot CHECK ALTO/estructura.boot \ /usr/bin/find /boot -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 020 H Funcion de integridad en /boot CHECK ALTO/HASH.boot \ /usr/bin/find /boot -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /etc LABEL \n5 030 E Estructura de archivos en /etc CHECK ALTO/estructura.etc \ /usr/bin/find /etc -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n5 030 H Funcion de integridad en /etc CHECK ALTO/HASH.etc \ /usr/bin/find /etc -type f -not -perm +111-exec /usr/bin/md5sum {} \; # Archivos en el directorio /etc # LABEL \n5 031 E Estructura de archivos en /etc # CHECK ALTO/estructura.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \

Anexo 2. Políticas y código fuente.

138

# -printf "%m %n %u %g %s %p\n" # LABEL \n5 031 H Funcion de integridad en /etc # CHECK ALTO/md5.etc \ # /usr/bin/find /etc -type f -not -perm +6111 \ # -not -regex "/etc/\(adjtime\|mtab\|hosts\.deny\)" \ # -exec /usr/bin/md5sum {} \; # #Archivos en el directorio /usr LABEL \n5 040 E Estructura de archivos en /usr CHECK ALTO/estructura.usr \ /usr/bin/find /usr -type f -perm 644 -printf "%m %n %u %g %s %p\n" LABEL \n5 040 H Funcion de integridad en /boot CHECK ALTO/HASH.usr \ /usr/bin/find /usr -type f -perm 644 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/local ## Archivos en el directorio /usr/share # Archivos en el directorio /usr/X11R6/lib #LABEL \n5 041 E Estructura de archivos en /usr/X11R6/lib #CHECK ALTO/estructura.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -printf "%m %n %u %g %s %p\n" #LABEL \n5 041 H Funcion de integridad en /usr.X11R6/lib #CHECK ALTO/md5.usr.X11R6.lib \ # /usr/bin/find /usr/X11R6/lib -type f \ # -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/lib #LABEL \n5 042 E Estructura de archivos en /usr/lib #CHECK ALTO/estructura.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 \ # -printf "%m %n %u %g %s %p\n" #LABEL \n5 042 H Funcion de integridad en /usr/lib #CHECK ALTO/md5.usr.lib \ # /usr/bin/find /usr/lib -type f -not -perm +6111 -exec /usr/bin/md5sum {} \; ## Archivos en el directorio /usr/sbin # Archivos en el directorio /lib LABEL \n5 060 E Estructura de archivos en /lib CHECK MEDIO/estructura.lib \ /usr/bin/find /lib -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 060 H Funcion de integridad en /lib CHECK MEDIO/HASH.lib \ /usr/bin/find /lib -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /sbin LABEL \n5 120 E Estructura de archivos en /sbin CHECK MEDIO/estructura.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n5 120 H Funcion de integridad en /sbin CHECK MEDIO/HASH.sbin \ /usr/bin/find /sbin -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo medio # ########################################################

Anexo 2. Políticas y código fuente.

139

#Archivos en el directorio /dev LABEL \n3 050 E Estructura de archivos en /dev CHECK MEDIO/estructura.dev \ /usr/bin/find /dev -type f -not -perm +111-printf "%m %n %u %g %s %p\n" LABEL \n3 050 H Funcion de integridad en /dev CHECK MEDIO/HASH.dev \ /usr/bin/find /dev -type f -not -perm +111-exec /usr/bin/md5sum {} \; #Archivos en el directorio /mnt LABEL \n3 070 E Estructura de archivos en /mnt CHECK MEDIO/estructura.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 070 H Funcion de integridad en /mnt CHECK MEDIO/HASH.mnt \ /usr/bin/find /mnt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /opt LABEL \n3 080 E Estructura de archivos en /opt CHECK MEDIO/estructura.opt \ /usr/bin/find /opt -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 080 H Funcion de integridad en /opt CHECK MEDIO/HASH.opt \ /usr/bin/find /opt -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /media LABEL \n3 130 E Estructura de archivos en /media CHECK MEDIO/estructura.media \ /usr/bin/find /media -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n3 130 H Funcion de integridad en /media CHECK MEDIO/HASH.media \ /usr/bin/find /media -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revisar los archivos no ejecutables riesgo bajo # ######################################################## #Archivos en el directorio /var LABEL \n1 091 E Estructura de archivos en /var/log CHECK BAJO/estructura.var.log \ /usr/bin/find /var/log -type f -not -perm +037 -printf "%m %n %u %g %s %p\n" LABEL \n1 091 H Funcion de integridad en /var/log CHECK BAJO/HASH.var.log \ /usr/bin/find /var/log -type f -not -perm +037 -exec /usr/bin/md5sum {} \; ##SERVIDOR APACHE EN WWW LABEL \n1 092 E Estructura de archivos en /var/www CHECK BAJO/estructura.var.www \ /usr/bin/find /var/www -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" LABEL \n1 092 H Funcion de integridad en /var/www CHECK BAJO/HASH.var.www \ /usr/bin/find /var/www -type f -not -perm +111 -exec /usr/bin/md5sum {} \; #Archivos en el directorio /home LABEL \n1 101 E Estructura de archivos en /home CHECK BAJO/estructura.home.ruteador \

Anexo 2. Políticas y código fuente.

140

/usr/bin/find /home/ruteador -type f -not -perm +111-perm +022, -user ruteador -printf "%m %n %u %g %s %p\n" LABEL \n1 101 H Funcion de integridad en /home/ruteador CHECK BAJO/HASH.home.ruteador \ /usr/bin/find /home/ruteador -type f -not -perm +111 -perm +022, -user ruteador -exec /usr/bin/md5sum {} \; #Archivos en el directorio /proc #LABEL \n1 110 E Estructura de archivos en /proc #CHECK BAJO/estructura.proc \ # /usr/bin/find /proc -type f -not -perm +111 -printf "%m %n %u %g %s %p\n" #LABEL \n1 110 H Funcion de integridad en /proc #CHECK BAJO/HASH.proc \ # /usr/bin/find /proc -type f -not -perm +111 -exec /usr/bin/md5sum {} \; ######################################################## # Revision de paquetes instalados ######################################################## LABEL \n9 REVISION DE PAQUETES INSTALADOS CHECK PAQUETES/instalados \ /usr/bin/dpkg -l '*' | grep 'ii' ############################################################ # #Mover el archivo de reporte # ########################################################### #LABEL \n #CHECK REPORTES/usuarios hostname LOCAL mv ${HOME}/${TARGET}/report ${HOME}/${TARGET}/REPORTES/reporte LOCAL chmod -R 750 ${HOME}/${TARGET}/ LOCAL php ${HOME}/${TARGET}/REPORTES/basedayusol.php ############################ #Realizar respaldos de clientes ############################# # #Agregar los directorios a continuacion de la linea de respaldos LABEL \n7 700 R RESPALDO DE INFORMACION CHECK RESPALDOS/registrados tar -zcf /tmp/respaldo.tar.gz /etc /bin /boot LOCAL scp ${CLIENT}:/tmp/respaldo.tar.gz ${HOME}/${TARGET}/RESPALDOS/respaldo.tar.gz rm /tmp/respaldo.tar.gz

Anexo 2. Políticas y código fuente.

141

Ejemplo de política de tripwire para Linux [12] # /proc changes a lot, so we'll grab what we can =/proc E+pugi # Capture these directories /tmp @@DIR /mnt @@DIR /mnt/cdrom @@DIR /mnt/floppy @@DIR /mnt/disk @@DIR /net @@DIR /misc @@DIR # root's home - won't change like /home /root @@READ # critical boot resources including kernel (/boot/vmlinuz) /boot @@READ # Critical configuration directories and files # We capture most things with CONFIG & modify # the resto # /etc @@CONFIG /etc/inetd.conf @@READ /etc/rc.d @@READ /etc/exports @@READ /etc/mtab @@LOGS /etc/motd @@LOGS /etc/group @@READ /etc/passwd @@LOGS /etc/shadow @@LOGS /etc/security @@READ /etc/pam.d @@READ /etc/fstab @@READ /etc/cron.d @@READ /etc/cron.daily @@READ /etc/cron.hourly @@READ /etc/cron.monthly @@READ /etc/cron.weekly @@READ /etc/ftpusers @@READ /etc/hosts @@READ /etc/hosts.allow @@READ /etc/hosts.deny @@READ /etc/login.defs @@READ /etc/logrotate.conf @@READ /etc/logrotate.d @@READ /etc/securetty @@READ /etc/sendmail.cf @@READ /etc/ssh @@READ /etc/sysconfig @@READ # truncate home - lots of changes in the directory =/home @@READ # var tree = /var/spool @@LOGS /var/log @@LOGS /var/spool/cron @@LOGS /var/spool/mqueue @@LOGS /var/spool/mail @LOGS # critical binaries /sbin @@READ /bin @@READ /lib @@READ /usr @@READ # device files /dev @@DEV /usr @@READ

Anexo 2. Políticas y código fuente.

142

CODIGO FUENTE ______________________________________________________________

ACTUALIZA.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN Descripción: Programa que abre el archivo del reporte del Cliente de DAYUSOL Actualiza la base de datos insertando los valores de fecha, archivos agregado, editados, Modificados y eliminados. Inserta los datos de la estructura y la integridad. */ // Niveles de fiabilidad FIABLE = 1; FIABILIDAD-MEDIA=2; FIABILIDAD-BAJA =3; NO-FIABLE =4; /* Abrir el archivo de reporte del usuario y cargarlo en una variable desplegarlo línea por línea. */ // Abrir archivo del reporte // REVISAR EL PATH Y LOS PERMISOS. DEBE SER 755 Y UN USUARIO DISTINTO DE ROOT $fh =fopen('/var/www/reporteador/reporte','r') or die("no se pudo_:$php_errormsg"); $numerohost=10; while (!feof($fh)){ // separar el texto del archivo en lineas $line = fgets($fh); // Eliminar los espacios en blanco del principio y final de cada linea $lineas= trim ($line); // Separar las palabras de cada linea cada espacio en blanco // para obtener una matriz de columnas por cada linea $palabras = split(" ", $lineas); // Imprimir cada una de las palabras del renglon separadas por un tabulador if ($palabras !=""){ $casilla =0; // echo "<tr>"; foreach ($palabras as $actual) { $actual2= trim ($actual); if ($actual2 !=" ") { /* Generar un arreglo multidimensional con los valores de cada elemento el procesado contiene el archivo reporte en un arreglo sin espacios*/ if ($actual2 == "<"){ $procesado[$renglon][$casilla]= "agregado"; } else if ($actual2 == ">"){ $procesado[$renglon][$casilla]= "eliminado"; } else{ $procesado[$renglon][$casilla]= (string) $actual2 ; } $casilla = $casilla +1 ; } } $renglon= $renglon +1;

Anexo 2. Políticas y código fuente.

143

} } /* Cerrar el archivo de reporte de stealth */ fclose($fh); //contador de numero de lineas de la matriz $procesado $numeros = count($procesado); /* Decision del tipo de accion para ejecutar de acuerdo al primer campo del renglon de la matriz $procesado */ for ($revisados =0; $revisados <= $numeros; $revisados++){ // Asignar el valor del arreglo al primer campo// $accion= (string) $procesado[$revisados][0]; echo $accion; switch ( $accion ){ case "STEALTH" : include 'conexion.php'; echo " Agregar entrada a base de datos con la fecha"; $meses=$procesado[$revisados][5]; switch ( $meses ){ case "Jan" : $mesnumero ="1"; break; case "Feb" : $mesnumero ="2"; break; case "Mar" : $mesnumero ="3"; break; case "Apr" : $mesnumero ="4"; break; case "May" : $mesnumero ="5"; break; case "Jun" : $mesnumero ="6"; break; case "Jul" : $mesnumero ="7"; break; case "Aug" : $mesnumero ="8"; break; case "Sep" : $mesnumero ="9"; break; case "Oct" : $mesnumero ="10"; break; case "Nov" : $mesnumero ="11";

Anexo 2. Políticas y código fuente.

144

break; case "Dec" : $mesnumero ="12"; break; } $dias=$procesado[$revisados][6]; $horas= $procesado[$revisados][7]; $alos=$procesado[$revisados][8]; $fechaanalisis = $alos . '-' . $mesnumero . '-' . $dias; settype($fechaanalisis, "string"); echo $fechaanalisis; echo $horas; $sql = "INSERT INTO `ESTADOHOST`

(`CLIENTES_IDHOST`, `FIABILIDAD_TIPO`, `ALTOS`, `BAJOS` , `MEDIOS`, `TOTAL`, `FECHAULTIMO`, `HORAULTIMO`)

VALUES ('10','','','','','','$fechaanalisis','$horas' )"; mysql_query($sql); echo "<br>"; break; case "5" : /* OBTENER EL NIVEL DE RIESGO, CLAVE DEL DIRECTORIO SI ES ESTRUCTURA O HASH */ $riesgo= $procesado[$revisados][0]; $ClaveDir=$procesado[$revisados][1]; $Elemento= $procesado[$revisados][2]; $revisados = $revisados +1; $cice= $procesado[$revisados][0]; echo $riesgo. $ClaveDir. $Elemento. $revisados. $cice ;

while ( $cice == "ADDED:" || $cice == "REMOVED:" || $cice == "MODIFIED:"){

if ($Elemento == "E"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo =4; $revisados = $revisados +1; $permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

Anexo 2. Políticas y código fuente.

145

mysql_query($insertando); echo $revisados . "" . "############" . $metodo ."<br>" ; echo $permisos; echo $ligas; echo $usuario; echo $grupo; echo $tamano; echo $nombreyruta; $metodo=3; break; } $revisados = $revisados +1; $permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

mysql_query($insertando); echo $revisados . "" . $metodo ."<br>" ; echo $permisos; echo $ligas; echo $usuario; echo $grupo; echo $tamano; echo $nombreyruta; } else if ($Elemento == "H"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo = 4; $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3]; $insertar = "INSERT INTO `COMPENDIOS`

(`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

Anexo 2. Políticas y código fuente.

146

mysql_query($insertar); echo $revisados . "" . $metodo ."<br>" ; echo $nombrearchivo; echo $sumatoria; $metodo=3; break; } $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3]; $insertar = "INSERT INTO `COMPENDIOS`

(`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertar); echo $revisados . "" . $metodo ."<br>" ; echo $nombrearchivo; echo $sumatoria; } $revisados = $revisados +1; $cice= $procesado[$revisados][0]; } break; case "3" : /* OBTENER EL NIVEL DE RIESGO, CLAVE DEL DIRECTORIO SI ES ESTRUCTURA O HASH */ $riesgo= $procesado[$revisados][0]; $ClaveDir=$procesado[$revisados][1]; $Elemento= $procesado[$revisados][2]; $revisados = $revisados +1; $cice= $procesado[$revisados][0]; while ( $cice == "ADDED:" || $cice == "REMOVED:" || $cice == "MODIFIED:"){ if ($Elemento == "E"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo =4; $revisados = $revisados +1; $permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

Anexo 2. Políticas y código fuente.

147

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

mysql_query($insertando); $metodo=3; break; } $revisados = $revisados +1; $permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

mysql_query($insertando); } else if ($Elemento == "H"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo = 4; $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3]; $insertar = "INSERT INTO `COMPENDIOS`

(`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertar); $metodo=3; break; } $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3];

Anexo 2. Políticas y código fuente.

148

$insertar = "INSERT INTO `COMPENDIOS` (`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertar); } $revisados = $revisados +1; $cice= $procesado[$revisados][0]; } break; case "1" : /* OBTENER EL NIVEL DE RIESGO, CLAVE DEL DIRECTORIO SI ES ESTRUCTURA O HASH */ $riesgo= $procesado[$revisados][0]; $ClaveDir=$procesado[$revisados][1]; $Elemento= $procesado[$revisados][2]; $revisados = $revisados +1; $cice= $procesado[$revisados][0]; echo $riesgo. $ClaveDir. $Elemento. $revisados. $cice ; while ( $cice == "ADDED:" || $cice == "REMOVED:" || $cice == "MODIFIED:"){ if ($Elemento == "E"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo =4; $revisados = $revisados +1; $permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

mysql_query($insertando); $metodo=3; break; } $revisados = $revisados +1;

Anexo 2. Políticas y código fuente.

149

$permisos=$procesado[$revisados][1]; $ligas=$procesado[$revisados][2]; $usuario =$procesado[$revisados][3]; $grupo =$procesado[$revisados][4]; $tamano =$procesado[$revisados][5]; $nombreyruta =$procesado[$revisados][6]; $insertando = "INSERT INTO `ESTRUCTURA`

(`NOMBREE`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `USUARIO`, `GRUPO`, `TAMANO`, `PERMISOS`, `ENLACES`, `NIVELRIESGO`, `FECHACAMBIO`, `HORA`, `CLAVEDIRECT`) VALUES ('$nombreyruta', '$numerohost', '1', '$metodo', '$usuario', '$grupo', '$tamano', '$permisos', '$ligas', '$riesgo', '$fechaanalisis','$horas', '$ClaveDir')";

mysql_query($insertando); } else if ($Elemento == "H"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo = 4; $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3]; $insertar = "INSERT INTO `COMPENDIOS`

(`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertar);

$metodo=3; break; } $revisados = $revisados +1; $sumatoria=$procesado[$revisados][1]; $nombrearchivo=$procesado[$revisados][3]; $insertar = "INSERT INTO `COMPENDIOS`

(`NOMBREHAS`, `CLIENTES_IDHOST`, `ESTADOS_TIPO`, `MODIFICACION`, `COMPENDIO`, `CLAVEDIRECT`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrearchivo', '$numerohost', '1', '$metodo', '$sumatoria', '$ClaveDir','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertar); } $revisados = $revisados +1; $cice= $procesado[$revisados][0]; } break;

Anexo 2. Políticas y código fuente.

150

case "9": //OBTENER EL NIVEL DE RIESGO, CLAVE DEL DIRECTORIO $riesgo= $procesado[$revisados][0];

$ClaveDir=$procesado[$revisados][1]; $Elemento= $procesado[$revisados][2]; $revisados = $revisados +1; $cice= $procesado[$revisados][0]; echo $riesgo." ". $ClaveDir." ". $Elemento." ". $revisados." ". $cice ;

while ( $cice == "ADDED:" || $cice == "REMOVED:" || $cice == "MODIFIED:"){

if ($Elemento == "P"){ $acciones = $procesado[$revisados][0]; switch ($acciones){ case "ADDED:" : $metodo = 1; break; case "REMOVED:" : $metodo = 2; break; case "MODIFIED:" : $metodo = 4; $revisados = $revisados +1; unset ($PAQUETES); for ($paquetin =0; $paquetin <= 100 ; $paquetin++){ $simple= trim ($procesado[$revisados][$paquetin]); //settype($simple, "string"); if ($simple == ""){ } else { $PAQUETES[]=$procesado[$revisados][$paquetin]; } } $nombrepaquete=$PAQUETES[2]; $verpaquete=$PAQUETES[3];

$descripcion1=$PAQUETES[4] . " " . $PAQUETES[5] ." " .$PAQUETES[6] . " " .$PAQUETES[7] . " " .$PAQUETES[8];

settype($descripcion1, "string"); $estadopaquete=$PAQUETES[1]; $estadopaquete= trim ($estadopaquete); if ($estadopaquete == "ii"){ $edopaquete =1; } else { $edopaquete =2; } $insertando = "INSERT INTO `PAQUETES`

(`PNOMBRE`, `CLIENTES_IDHOST`, `ESTADOPAQ_TIPO`, `MODIFICACION`, `DESCRIPCION`, `TIPO`, `VERSION`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrepaquete', '$numerohost', '$edopaquete', '$metodo', '$descripcion1', '$tipopaquete','$verpaquete','$riesgo', '$fechaanalisis','$horas')";

Anexo 2. Políticas y código fuente.

151

mysql_query($insertando);

$metodo =3; break; } $tipopaquete=$procesado[$revisados][1]; $revisados = $revisados +1; unset ($PAQUETES); for ($paquetin =0; $paquetin <= 100 ; $paquetin++){

$simple= trim ($procesado[$revisados][$paquetin]); //settype($simple, "string"); if ($simple == ""){ } else { $PAQUETES[]=$procesado[$revisados][$paquetin]; } } $nombrepaquete=$PAQUETES[2]; $verpaquete=$PAQUETES[3];

$descripcion1=$PAQUETES[4] ." " . $PAQUETES[5] . " " .$PAQUETES[6]." " .$PAQUETES[7]." " .$PAQUETES[8];

settype($descripcion1, "string"); $estadopaquete=$PAQUETES[1]; $estadopaquete= trim ($estadopaquete); if ($estadopaquete == "ii"){ $edopaquete =1; } else { $edopaquete =2; } $insertando = "INSERT INTO `PAQUETES`

(`PNOMBRE`, `CLIENTES_IDHOST`, `ESTADOPAQ_TIPO`, `MODIFICACION`, `DESCRIPCION`, `TIPO`, `VERSION`, `RIESGO`, `FECHA`, `HORA`) VALUES ('$nombrepaquete', '$numerohost', '$edopaquete', '$metodo', '$descripcion1', '$tipopaquete','$verpaquete','$riesgo', '$fechaanalisis','$horas')";

mysql_query($insertando); } $revisados = $revisados +1; $cice= $procesado[$revisados][0]; } break; default:

break; } } Include estado-host.php; ?>

Anexo 2. Políticas y código fuente.

152

___________________________________________________________________________________ BASEDAYUSOL.php <? /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Después de actualizar el sistema con las modificaciones detectadas, se edita el perfil del cliente de acuerdo a los elementos que tiene y el nivel de riesgo.

*/ // Revisar el numero de elementos insertados y // Actualizar la base de datos considerando // el nivel de riesgo $sql = " SELECT COMPENDIOS.CLIENTES_IDHOST FROM COMPENDIOS WHERE COMPENDIOS.CLIENTES_IDHOST = '$numerohost' AND COMPENDIOS.RIESGO = 5 AND COMPENDIOS.FECHA = '$fechaanalisis' AND COMPENDIOS.HORA = '$horas' "; $reso= mysql_query($sql); $numeral = mysql_num_rows($reso); echo $numeral; $sqlest = " SELECT ESTRUCTURA. * FROM ESTRUCTURA WHERE ESTRUCTURA.CLIENTES_IDHOST = '$numerohost' AND ESTRUCTURA.NIVELRIESGO = 5 AND ESTRUCTURA.FECHACAMBIO = '$fechaanalisis' AND ESTRUCTURA.HORA = '$horas' "; $rese= mysql_query($sqlest); $numerale = mysql_num_rows($rese); echo $numerale; $numaltos = $numeral + $numerale; $sql = " SELECT COMPENDIOS.CLIENTES_IDHOST FROM COMPENDIOS WHERE COMPENDIOS.CLIENTES_IDHOST = '$numerohost' AND COMPENDIOS.RIESGO = 3 AND COMPENDIOS.FECHA = '$fechaanalisis' AND COMPENDIOS.HORA = '$horas' "; $reso= mysql_query($sql); $numeral = mysql_num_rows($reso); echo $numeral; $sqlest = " SELECT ESTRUCTURA. * FROM ESTRUCTURA WHERE ESTRUCTURA.CLIENTES_IDHOST = '$numerohost' AND ESTRUCTURA.NIVELRIESGO = 3 AND ESTRUCTURA.FECHACAMBIO = '$fechaanalisis' AND ESTRUCTURA.HORA = '$horas' "; $rese= mysql_query($sqlest); $numerale = mysql_num_rows($rese); echo $numerale; $nummedios = $numeral + $numerale;

Anexo 2. Políticas y código fuente.

153

$sql = " SELECT COMPENDIOS.CLIENTES_IDHOST FROM COMPENDIOS WHERE COMPENDIOS.CLIENTES_IDHOST = '$numerohost' AND COMPENDIOS.RIESGO = 1 AND COMPENDIOS.FECHA = '$fechaanalisis' AND COMPENDIOS.HORA = '$horas' "; $reso= mysql_query($sql); $numeral = mysql_num_rows($reso); $sqlest = " SELECT ESTRUCTURA. * FROM ESTRUCTURA WHERE ESTRUCTURA.CLIENTES_IDHOST = '$numerohost' AND ESTRUCTURA.NIVELRIESGO = 1 AND ESTRUCTURA.FECHACAMBIO = '$fechaanalisis' AND ESTRUCTURA.HORA = '$horas' "; $rese= mysql_query($sqlest); $numerale = mysql_num_rows($rese); echo $numerale; $numbajos = $numeral + $numerale; $totelementos = $numaltos + $nummedios + $numbajos; if ($numaltos >0){ $fiabilidad =1; } else if ($numaltos == 0 || $nummedios > 0){ $fiabilidad =2; } else if ($numaltos == 0 || $nummedios ==0 || $numbajos > 0){ $fiabilidad =3; } else if ($numaltos == 0 || $nummedios < 20 || $numbajos <= 30){ $fiabilidad =4; } $perfilhost = " UPDATE `DAYUSOL2008`.`ESTADOHOST` SET `FIABILIDAD_TIPO` = '$fiabilidad', `ALTOS` = '$numaltos', `BAJOS` = '$numbajos', `MEDIOS` = '$nummedios', `TOTAL` = '$totelementos' WHERE `ESTADOHOST`.`CLIENTES_IDHOST` = '$numerohost' AND `ESTADOHOST`.`FECHAULTIMO` = '$fechaanalisis' AND `ESTADOHOST`.`HORAULTIMO` = '$horas' "; mysql_query($perfilhost); ?> ___________________________________________________________________________________ CONEXIÓN.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Permite la conexión con el manejador de base de datos, selecciona la base DAYUSOL, entrega el usuario y contraseña para validarse.

$conex= mysql_pconnect("localhost","root","debian") or DIE ("ERROR EN LA CONEXION"); $db= mysql_select_db("DAYUSOL2008"); ?>

Anexo 2. Políticas y código fuente.

154

___________________________________________________________________________________ DETALLEHASH.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Realizar consultas a la base de datos y mostrar en el navegador las características del detalle de los elementos encontrados para el cliente de DAYUSOL y los elementos separados por directorio de acuerdo al riesgo.

*/ $idcli=$_GET['usuario']; $nivriesgo =$_GET['riesgo']; // // CODIGO PARA LA TABLA DE CARACTERISTICAS $conex= mysql_pconnect("localhost","root","alejandro2463") or DIE ("ERROR EN LA CONEXION"); $db= mysql_select_db("DAYUSOL2008"); $sql = " SELECT CLIENTES.*, REDDAYUSOL.FECHAULTIMO, REDDAYUSOL.HORAULTIMO FROM CLIENTES, REDDAYUSOL WHERE ((CLIENTES.IDHOST ='$idcli') AND (REDDAYUSOL.CLIENTES_IDHOST = CLIENTES.IDHOST))"; $respuesta = mysql_query($sql); while($row = mysql_fetch_row($respuesta) ) { foreach ($row as $registro){ $caracteristicas[]=$registro ; } } mysql_free_result($respuesta); // codigo para el detalle de compendios..... if ($nivriesgo == 5){ $despliegue = " ALTO";

} else if ($nivriesgo == 3){ $despliegue = " MEDIO";

} else { $despliegue = " BAJO"; } // Obtener un arreglo para el indice de directorios // con riesgo alto. nota.... puede aplicarse para ver los de otro // Nivel de riesgo cambiando el valor por variable. $sqlDIR = "SELECT DIRECTORIOS.CLAVEDIRECT , DIRECTORIOS.DIRECTORIO FROM DIRECTORIOS WHERE ( DIRECTORIOS.NIVEL_RIESGO = '$nivriesgo' ) ORDER BY DIRECTORIOS.CLAVEDIRECT ASC "; $respDIR = mysql_query($sqlDIR); $d =0; while($reng = mysql_fetch_row($respDIR) )

{

Anexo 2. Políticas y código fuente.

155

foreach ($reng as $indice){ $guiaDIR[$d][]=$indice ;

} $d=$d+1; } $numDIR = mysql_num_rows($respDIR); mysql_free_result($respDIR); $sqlDOBLE = "SELECT DIRECTORIOS.CLAVEDIRECT FROM DIRECTORIOS WHERE ( DIRECTORIOS.NIVEL_RIESGO = '$nivriesgo' ) ORDER BY DIRECTORIOS.CLAVEDIRECT ASC "; $respDOBLE = mysql_query($sqlDOBLE); $dos =0; while($ALE = mysql_fetch_row($respDOBLE) ) { foreach ($ALE as $indica){ $indiceDIR[]=$indica ; } $dos=$dos+1; } $numDOBLE = mysql_num_rows($respDOBLE); mysql_free_result($respDOBLE); ?> <?PHP $enterado=0; while ($enterado < $numDOBLE){ // OBTENER LOS DATOS DEL COMPENDIO Y LAS FECHAS DE MODIFICACION // ASI COMO EL TIPO DE MODIFICACION...

echo '<table width="100%" border="3" bordercolor="#CCCCCC">'; echo '<tr>'; echo '<td colspan="3"><div align="center"><strong><font color="#000000">'; echo "DIRECTORIO " . $guiaDIR[$enterado][1];

echo '</font></strong></div></td>'; echo '<td colspan="3"><strong>'; echo "RIESGO " . $despliegue ; echo '</strong> </td> </tr>' ;

echo '<tr> <td width="377"><font color="#000000" size="2">NOMBRE</font></td> <td width="169"><font color="#000000" size="2">MODIFICACION</font></td> <td colspan="1"><font size="2">HASH (MD5)</font></td> <td width="113"><font size="2">FECHA</font></td> <td width="113"><font size="2">HORA</font></td> </tr>'; $sqlCOMP = "SELECT COMPENDIOS.NOMBREHAS ,TIPOMODIFICACION.DESCRIPCION , COMPENDIOS.COMPENDIO ,COMPENDIOS.FECHA , COMPENDIOS.HORA FROM COMPENDIOS , TIPOMODIFICACION WHERE ( ( COMPENDIOS.CLIENTES_IDHOST = '$idcli') AND ( COMPENDIOS.ESTADOS_TIPO = 1 ) AND ( COMPENDIOS.CLAVEDIRECT = '$indiceDIR[$enterado]') AND ( COMPENDIOS.RIESGO = '$nivriesgo')

AND ( COMPENDIOS.MODIFICACION = TIPOMODIFICACION.OPERACION ) )

Anexo 2. Políticas y código fuente.

156

ORDER BY COMPENDIOS.FECHA ASC "; $respCOMP = mysql_query($sqlCOMP); $permitido = mysql_num_rows($respCOMP); while($reng = mysql_fetch_row($respCOMP) ) { foreach ($reng as $indice){ echo '<td colspan="1"><div align="left"><font color="#000000"><font size="2">'; echo $indice ; echo '</font></font></div></td>'; } echo '</tr>'; } $enterado = $enterado+1; echo '</table>'; echo "<br>"; echo "<br>"; } ?> __________________________________________________________________________________ DETALLEESTRUCTURA.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Realizar consultas a la base de datos y mostrar en el navegador las características del detalle de los elementos de la estructura encontrados para el cliente de DAYUSOL y los elementos separados por directorio de acuerdo al riesgo

*/ $idcli=$_GET['usuario']; $nivriesgo =$_GET['riesgo']; // // CODIGO PARA LA TABLA DE CARACTERISTICAS Include conexión.php; $sql = " SELECT CLIENTES.*, REDDAYUSOL.FECHAULTIMO, REDDAYUSOL.HORAULTIMO FROM CLIENTES, REDDAYUSOL WHERE ((CLIENTES.IDHOST ='$idcli') AND (REDDAYUSOL.CLIENTES_IDHOST = CLIENTES.IDHOST))"; $respuesta = mysql_query($sql); while($row = mysql_fetch_row($respuesta) ) { foreach ($row as $registro){ $caracteristicas[]=$registro ; } } mysql_free_result($respuesta); if ($nivriesgo == 5){ $despliegue = " ALTO"; }

Anexo 2. Políticas y código fuente.

157

else if ($nivriesgo == 3){ $despliegue = " MEDIO"; } else { $despliegue = " BAJO"; } // Obtener un arreglo para el indice de directorios // con riesgo alto. nota.... puede aplicarse para ver los de otro // nivel de riesgo cambiando el valor por variable. $sqlDIR = "SELECT DIRECTORIOS.CLAVEDIRECT , DIRECTORIOS.DIRECTORIO FROM DIRECTORIOS WHERE ( DIRECTORIOS.NIVEL_RIESGO = '$nivriesgo' ) ORDER BY DIRECTORIOS.CLAVEDIRECT ASC "; $respDIR = mysql_query($sqlDIR); $d =0; while($reng = mysql_fetch_row($respDIR) ) { foreach ($reng as $indice){ $guiaDIR[$d][]=$indice ; // echo $indice; } $d=$d+1; } //echo "<br>"; $numDIR = mysql_num_rows($respDIR); mysql_free_result($respDIR); $sqlDOBLE = "SELECT DIRECTORIOS.CLAVEDIRECT FROM DIRECTORIOS WHERE ( DIRECTORIOS.NIVEL_RIESGO = '$nivriesgo' ) ORDER BY DIRECTORIOS.CLAVEDIRECT ASC "; $respDOBLE = mysql_query($sqlDOBLE); $dos =0; while($ALE = mysql_fetch_row($respDOBLE) ) { foreach ($ALE as $indica){ $indiceDIR[]=$indica ; } $dos=$dos+1; } $numDOBLE = mysql_num_rows($respDOBLE); mysql_free_result($respDOBLE); ?> <?PHP $enterado=0; while ($enterado < $numDOBLE){ // OBTENER LOS DATOS DE LA ESTRUCTURA Y LAS FECHAS DE MODIFICACION // ASI COMO EL TIPO DE MODIFICACION.. echo '<table width="100%" border="3" bordercolor="#CCCCCC">'; echo '<tr>'; echo '<td colspan="5"><div align="center"><strong><font color="#000000">'; echo "DIRECTORIO " . $guiaDIR[$enterado][1]; echo '</font></strong></div></td>'; echo '<td colspan="5"><strong>'; echo "RIESGO " . $despliegue ; echo '</strong> </td> </tr>' ;

Anexo 2. Políticas y código fuente.

158

echo '<tr> <td width="377"><font color="#000000" size="2">NOMBRE</font></td> <td width="169"><font color="#000000" size="2">MODIFICACION</font></td>

<td width="113"><font size="2">USUARIO</font></td> <td width="113"><font size="2">GRUPO</font></td> <td width="113"><font size="2">TAMAÑO</font></td>

<td width="113"><font size="2">PERMISOS</font></td> <td width="113"><font size="2">ENLACES</font></td> <td width="113"><font size="2">FECHA</font></td> <td width="113"><font size="2">HORA</font></td> </tr>';

$sqlCOMP = "SELECT ESTRUCTURA.NOMBREE , TIPOMODIFICACION.DESCRIPCION, ESTRUCTURA.USUARIO, ESTRUCTURA.GRUPO , ESTRUCTURA.TAMANO, ESTRUCTURA.PERMISOS, ESTRUCTURA.ENLACES,

ESTRUCTURA.FECHACAMBIO, ESTRUCTURA.HORA FROM ESTRUCTURA , TIPOMODIFICACION WHERE ( ( ESTRUCTURA.CLIENTES_IDHOST = '$idcli' ) AND ( ESTRUCTURA.ESTADOS_TIPO = 1 ) AND ( ESTRUCTURA.MODIFICACION = TIPOMODIFICACION.OPERACION ) AND ( ESTRUCTURA.NIVELRIESGO = '$nivriesgo' ) AND ( ESTRUCTURA.CLAVEDIRECT = '$indiceDIR[$enterado]' ) ) ORDER BY ESTRUCTURA.FECHACAMBIO ASC "; $respCOMP = mysql_query($sqlCOMP); $permitido = mysql_num_rows($respCOMP); while($reng = mysql_fetch_row($respCOMP) ) { echo '<tr>'; foreach ($reng as $indice){ echo '<td colspan="1"><div align="left"><font color="#000000"><font size="2">'; echo $indice ; echo '</font></font></div></td>'; } echo '</tr>';

} $enterado = $enterado+1; echo '</table>'; echo "<br>"; echo "<br>"; } ?> ___________________________________________________________________________________ REPORTERED.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Realizar consultas a la base de datos y mostrar en el navegador las características del la red DAYUSOL, mostrar la grafica del estado de fiabilidad del la red.

*/ / // CODIGO PARA LA TABLA DE CARACTERISTICAS Include conexión.php // datos de la estadística de host //

Anexo 2. Políticas y código fuente.

159

// OBTENER UN ARREGLO CON TODOS LOS ELEMENTOS DE FIABILIDAD Y // CONTARLOS PARA SABER EL NUMERO DE ELEMENTOS.. // RECORRER ESTO DENTRO DE UN CICLO FOR PARA REVISAR LOS NIVELES // DESDE EL MAYOR HASTA EL MENOR.... O AL REVES 1-4 FOR ($niveles =1 ; $niveles <5; $niveles ++) { $sqlRED = "SELECT REDDAYUSOL.FIABILIDAD_TIPO, REDDAYUSOL.CLIENTES_IDHOST FROM REDDAYUSOL WHERE ( REDDAYUSOL.FIABILIDAD_TIPO= '$niveles' ) "; $respRED = mysql_query($sqlRED); $estadisticas[] = mysql_num_rows($respRED); mysql_free_result($respRED); } $total=$estadisticas[0] +$estadisticas[1]+$estadisticas[2]+$estadisticas[3]; // EL TOTAL DE ELEMENTOS FUE OBTENIDO EN LA CONSULTA ANTERIOR..... //PASAR ESTOS VALORES PARA LA GRAFICA QUE TENDRA EL NIVEL DE RIESGO DE // LOS HOST COMO ENTRADA // OBTENER UNA ARREGLO CON LOS ID DE HOST REPORTADOS $sqlIND = "SELECT REDDAYUSOL.CLIENTES_IDHOST FROM REDDAYUSOL ORDER BY REDDAYUSOL.CLIENTES_IDHOST ASC "; $respIND = mysql_query($sqlIND); while($renglon = mysql_fetch_row($respIND) ) { foreach ($renglon as $indice){ $guiahost[]=$indice ; } } mysql_free_result($respIND); // CONTAR LOS ELEMENTOS DEL ARRAY PARA OBTENER EL TOTAL DE HOST //REALIZAR UN CICLO FOR PARA REALIZAR CONSULTAS CAMBIANDO EL ID_HOST // DE ACUERDO A LOS OBTENIDOS EN EL ARREGLO ANTERIOR... //IR ALMACENANDO TODOS LOS VALORES EN UNA MATRIZ BIDIMENSIONAL.. $conteo =0; while ($conteo < $total) {

$sqlDATOS = "SELECT REDDAYUSOL.CLIENTES_IDHOST , CLIENTES.HOSTNAME , REDDAYUSOL.TOTAL , REDDAYUSOL.PAQUETES , REDDAYUSOL.FECHAULTIMO , REDDAYUSOL.HORAULTIMO , FIABILIDAD.DESCRIPCION

FROM REDDAYUSOL , CLIENTES , FIABILIDAD WHERE ( ( REDDAYUSOL.CLIENTES_IDHOST = '$guiahost[$conteo]' ) AND ( CLIENTES.IDHOST = REDDAYUSOL.CLIENTES_IDHOST ) AND ( FIABILIDAD.TIPOFIABLE = REDDAYUSOL.FIABILIDAD_TIPO ) ) "; $respDATOS = mysql_query($sqlDATOS);

$renglon = mysql_fetch_row($respDATOS); foreach($renglon as $datos){ $matriz [$conteo][]=$datos ; } $conteo = $conteo +1 ; }

Anexo 2. Políticas y código fuente.

160

////INCLUIR EL RECORRIDO AUTOMATICO DE TABLAS DENTRO DEL ESQUEMA DE LA // TABLA GENERADA AL FINAL DEL ARCHIVO....... $contador = count ($matriz); ?> <?php $recorrido =0; while ($recorrido < $contador){ echo '<tr>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][0] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][1] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][2] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][3] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][4] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][5] . '</font>'.'</td>'; echo ' <td>' . '<font color="#000000" size="2">'. $matriz[$recorrido][6] . '</font>'.'</td>'; echo ' <td><font color="#000000" size="2"><a href="REPORTEHOST.php?idhost='.$matriz[$recorrido][0].'">ver detalles</a></td>'; echo '</tr>'; $recorrido = $recorrido +1; } ?> ___________________________________________________________________________________ REDGRAFICA-.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Utilizar la librería jplib para generar graficas de tipo pastel del estado de la red DAYUSOL

*/ include ("/usr/share/jpgraph/jpgraph.php"); include ("/usr/share/jpgraph/jpgraph_pie.php"); include ("/usr/share/jpgraph/jpgraph_pie3d.php"); $var=$_GET['alto']; $var2=$_GET['medio']; $var3=$_GET['bajo']; $var4=$_GET['paquetes']; $data = array($var,$var2,$var3,$var4); $graph = new PieGraph(450,350,"auto"); $graph->img->SetAntiAliasing(); $graph->SetMarginColor('white'); $graph->SetShadow(); $graph->SetColor("#ffffff"); // Setup margin and titles $graph->title->Set("ELEMENTOS REPORTADOS"); // $graph->title->SetFont(FF_VERDANA, FS_BOLD, 14); $p1 = new PiePlot3D($data); $p1->SetSize(0.30); $p1->SetCenter(0.5,0.6); $p1->SetAngle(70); // $p1->SetTheme('water'); $p1->SetSliceColors(array('red','blue','gray','white')); // $p1->SetSliceColors(array('#E0E0F8','#EFFBEF','white','#F5EFFB')); // Setup slice labels and move them into the plot // $p1->value->SetFont(FF_FONT1,FS_BOLD); // $p1->value->SetColor("black");

Anexo 2. Políticas y código fuente.

161

$nombres=array("ALTO","MEDIO","BAJO","PROGRAMAS"); $p1->SetLegends($nombres); // Explode all slices $p1->ExplodeAll(10); $graph->Add($p1); $graph->Stroke(); ?> ___________________________________________________________________________________ REPORTEHOST.php <?php /* Autor: Manuel Alejandro Soto Ramos Fecha: 12-08-07 Centro de Investigación en Computación IPN

Descripción: Realizar consultas a la base de datos y mostrar en el navegador las características del cliente de DAYUSOL, mostrar la grafica del estado de los elementos detectados en el cliente.

*/ $idcliente=$_GET['idhost']; // CODIGO PARA LA TABLA DE CARACTERISTICAS $conex= mysql_pconnect("localhost","root","alejandro2463") or DIE ("ERROR EN LA CONEXION"); $db= mysql_select_db("DAYUSOL2008"); $sql = " SELECT CLIENTES.*, REDDAYUSOL.FECHAULTIMO, REDDAYUSOL.HORAULTIMO FROM CLIENTES, REDDAYUSOL WHERE ((CLIENTES.IDHOST ='$idcliente') AND (REDDAYUSOL.CLIENTES_IDHOST = CLIENTES.IDHOST))"; $respuesta = mysql_query($sql); while($row = mysql_fetch_row($respuesta) ) { foreach ($row as $registro){ $caracteristicas[]=$registro ; } } mysql_free_result($respuesta); // CODIGO PARA LA TABLA DEL ESTADO $sql2 = " SELECT FIABILIDAD.DESCRIPCION , REDDAYUSOL.ALTOS , REDDAYUSOL.MEDIOS,

REDDAYUSOL.BAJOS , REDDAYUSOL.TOTAL, REDDAYUSOL.PAQUETES FROM FIABILIDAD, REDDAYUSOL

WHERE ( ( REDDAYUSOL.CLIENTES_IDHOST = '$idcliente' ) AND ( REDDAYUSOL.FIABILIDAD_TIPO = FIABILIDAD.TIPOFIABLE ) )"; $respuest = mysql_query($sql2); while($rowi = mysql_fetch_row($respuest) ) { foreach ($rowi as $registr){ $estadohost[]=$registr ; } } mysql_free_result($respuest);

Anexo 2. Políticas y código fuente.

162

$renglon = 0; for ($i =1; $i < 6; $riesgo = $i){

for ($n= 1; $n < 5; $reno = $n ){

$sql3 = "SELECT COMPENDIOS.CLIENTES_IDHOST , COMPENDIOS. ESTADOS_TIPO , COMPENDIOS.MODIFICACION

FROM COMPENDIOS WHERE ( ( COMPENDIOS.CLIENTES_IDHOST = '$idcliente' ) AND ( COMPENDIOS.ESTADOS_TIPO = 1 ) AND (COMPENDIOS.MODIFICACION = '$n' ) AND ( COMPENDIOS.RIESGO = '$i' ) )"; $respuesta = mysql_query($sql3); $numerale[$renglon][] = mysql_num_rows($respuesta); $n = $n+1 ; mysql_free_result($respuesta); } $i= $i + 2 ; $renglon = $renglon +1; } // Obtener datos de la estructura // modificacion y nivel de riesgo $reng = 0; for ($l =1; $l < 6; $ries = $l){ for ($m= 1; $m < 5; $renos = $m ){

$sql4 = "SELECT ESTRUCTURA.ESTADOS_TIPO , ESTRUCTURA.MODIFICACION , ESTRUCTURA.NIVELRIESGO

FROM ESTRUCTURA WHERE ( ( ESTRUCTURA.CLIENTES_IDHOST = '$idcliente' ) AND (ESTRUCTURA.ESTADOS_TIPO = 1 ) AND (ESTRUCTURA.MODIFICACION = '$m' ) AND (ESTRUCTURA.NIVELRIESGO = '$l' ) ) "; $respestruc = mysql_query($sql4); $numeral[$reng][] = mysql_num_rows($respestruc); $m = $m+1 ; mysql_free_result($respestruc); } $l= $l + 2 ; $reng = $reng +1; } ?> <table width="100%" border="3" bordercolor="#CCCCCC"> <tr> <td colspan="5"><div align="center"><strong><font color="#000000">INTEGRIDAD DE INFORMACION (HASH-MD5)</font></strong></div></td> </tr> <tr> <td width="12%">&nbsp;</td> <td width="18%"><font color="#000000" size="2">AGREGADOS</font></td> <td width="22%"><font size="2">ELIMINADOS</font></td> <td width="23%"><font size="2">MODIFICADOS</font></td>

Anexo 2. Políticas y código fuente.

163

<td width="25%"><font size="2">ACTUALIZADOS</font></td> </tr> <tr> <?PHP echo '<td><font color="#CCCCCC"></font><a href="detalleshash.php?riesgo=1&usuario='.$idcliente.'">BAJO</a> </font></td>'; ?> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numerale[0][0];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numerale[0][1];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numerale[0][2];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numerale[0][3];?></font></div></td> </tr> <tr> <?PHP echo '<td><font color="#CCCCCC"></font><a href="detalleshash.php?riesgo=3&usuario='.$idcliente.'">MEDIO</a> </font></td>'; ?> <td><div align="right"><font color="#0000FF"><?PHP echo $numerale[1][0];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numerale[1][1];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numerale[1][2];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numerale[1][3];?></font></div></td> </tr> <tr> <?PHP echo '<td><font color="#CCCCCC"></font><a href="detalleshash.php?riesgo=5&usuario='.$idcliente.'">ALTO</a> </font></td>'; ?> <td><div align="right"><font color="#FF0000"><?PHP echo $numerale[2][0];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numerale[2][1];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numerale[2][2];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numerale[2][3];?></font></div></td> </tr> </table> <table width="100%" border="3" bordercolor="#CCCCCC"> <tr> <td colspan="5"><div align="center"><strong><font color="#000000">PERMISOS, TAMA&Ntilde;O, ENLACES, USUARIOS Y GRUPO</font></strong></div></td> </tr> <tr> <td width="12%">&nbsp;</td> <td width="18%"><font color="#000000" size="2">AGREGADOS</font></td> <td width="22%"><font size="2">ELIMINADOS</font></td> <td width="23%"><font size="2">MODIFICADOS</font></td> <td width="25%"><font size="2">ACTUALIZADOS</font></td> </tr> <tr> <?PHP echo '<td><font color="#CCCCCC"></font><a href="detallesest.php?riesgo=1&usuario='.$idcliente.'">BAJO</a> </font></td>'; ?> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numeral[0][0];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numeral[0][1];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numeral[0][2];?></font></div></td> <td><div align="right"><font color="#CCCCCC"><?PHP echo $numeral[0][3];?></font></div></td> </tr> <tr> <?PHP echo '<td><font color="#CCCCCC"></font><a href="detallesest.php?riesgo=3&usuario='.$idcliente.'">MEDIO</a> </font></td>'; ?> <td><div align="right"><font color="#0000FF"><?PHP echo $numeral[1][0];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numeral[1][1];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numeral[1][2];?></font></div></td> <td><div align="right"><font color="#0000FF"><?PHP echo $numeral[1][3];?></font></div></td> </tr> <tr>

Anexo 2. Políticas y código fuente.

164

<?PHP echo '<td><font color="#CCCCCC"></font><a href="detallesest.php?riesgo=5&usuario='.$idcliente.'">ALTO</a> </font></td>'; ?> <td><div align="right"><font color="#FF0000"><?PHP echo $numeral[2][0];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numeral[2][1];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numeral[2][2];?></font></div></td> <td><div align="right"><font color="#FF0000"><?PHP echo $numeral[2][3];?></font></div></td> </tr> </table> __________________________________________________________________________________ GENERACION DE BASE DE DATOS DAYUSOL2008 Servidor: localhost -- Tiempo de generación: 18-06-2008 a las 03:32:40 -- Versión del servidor: 5.0.38 -- Versión de PHP: 5.2.1 -- -- Base de datos: `DAYUSOL2008` -------------------------------------------------------- -- Estructura de tabla para la tabla `CLIENTES` CREATE TABLE `CLIENTES` ( `IDHOST` int(3) unsigned NOT NULL, `IPV4` varchar(15) NOT NULL default '', `HOSTNAME` varchar(15) default NULL, `DESCRIPCION` varchar(70) NOT NULL, PRIMARY KEY (`IDHOST`), UNIQUE KEY `IPV4` (`IPV4`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `COMPENDIOS` CREATE TABLE `COMPENDIOS` ( `NOMBREHAS` varchar(70) NOT NULL, `CLIENTES_IDHOST` int(3) NOT NULL, `ESTADOS_TIPO` int(1) NOT NULL, `MODIFICACION` int(1) NOT NULL, `COMPENDIO` varchar(40) NOT NULL default '', `CLAVEDIRECT` int(3) NOT NULL, `RIESGO` int(1) NOT NULL, `FECHA` date NOT NULL, `HORA` time NOT NULL, PRIMARY KEY (`NOMBREHAS`,`CLIENTES_IDHOST`,`MODIFICACION`,`COMPENDIO`,`CLAVEDIRECT`,`FECHA`,`HORA`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `DIRECTORIOS` CREATE TABLE `DIRECTORIOS` ( `CLAVEDIRECT` int(2) NOT NULL, `NIVEL_RIESGO` int(1) NOT NULL, `DIRECTORIO` varchar(30) NOT NULL, PRIMARY KEY (`CLAVEDIRECT`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `ESTADOHOST` CREATE TABLE `ESTADOHOST` ( `CLIENTES_IDHOST` int(3) NOT NULL, `FIABILIDAD_TIPO` int(1) NOT NULL, `ALTOS` int(10) unsigned NOT NULL, `BAJOS` int(10) unsigned default NULL, `MEDIOS` int(10) unsigned default NULL,

Anexo 2. Políticas y código fuente.

165

`TOTAL` int(10) unsigned default NULL, `PAQUETES` int(3) NOT NULL, `FECHAULTIMO` date NOT NULL, `HORAULTIMO` time NOT NULL, PRIMARY KEY (`CLIENTES_IDHOST`,`FECHAULTIMO`,`HORAULTIMO`), KEY `ESTADOHOST_FKIndex1` (`CLIENTES_IDHOST`), KEY `ESTADOHOST_FKIndex2` (`FIABILIDAD_TIPO`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `ESTADOPAQ` CREATE TABLE `ESTADOPAQ` ( `TIPOP` int(1) unsigned NOT NULL, `DESCRIPCION` varchar(15) default NULL, PRIMARY KEY (`TIPOP`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `ESTADOS` CREATE TABLE `ESTADOS` ( `TIPOE` int(1) unsigned NOT NULL, `DESCRIPCION` varchar(15) default NULL, PRIMARY KEY (`TIPOE`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `ESTRUCTURA` CREATE TABLE `ESTRUCTURA` ( `NOMBREE` varchar(70) NOT NULL, `CLIENTES_IDHOST` int(3) unsigned NOT NULL, `ESTADOS_TIPO` int(1) unsigned NOT NULL, `MODIFICACION` int(1) NOT NULL, `USUARIO` varchar(30) default NULL, `GRUPO` varchar(30) default NULL, `TAMANO` int(10) default NULL, `PERMISOS` int(4) unsigned default NULL, `ENLACES` int(2) unsigned default NULL, `NIVELRIESGO` int(1) default NULL, `FECHACAMBIO` date NOT NULL default '0000-00-00', `HORA` time NOT NULL, `CLAVEDIRECT` int(3) NOT NULL, PRIMARY KEY (`NOMBREE`,`CLIENTES_IDHOST`,`MODIFICACION`,`FECHACAMBIO`,`HORA`,`CLAVEDIRECT`), KEY `ESTRUCTURA_FKIndex1` (`CLIENTES_IDHOST`), KEY `ESTRUCTURA_FKIndex2` (`ESTADOS_TIPO`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `FIABILIDAD` CREATE TABLE `FIABILIDAD` ( `TIPOFIABLE` int(1) unsigned NOT NULL, `DESCRIPCION` varchar(30) default NULL, PRIMARY KEY (`TIPOFIABLE`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `PAQUETES` CREATE TABLE `PAQUETES` ( `PNOMBRE` varchar(30) NOT NULL, `CLIENTES_IDHOST` int(3) unsigned NOT NULL, `ESTADOPAQ_TIPO` int(1) unsigned NOT NULL, `MODIFICACION` int(1) NOT NULL, `DESCRIPCION` varchar(30) default NULL, `TIPO` varchar(10) NOT NULL, `VERSION` varchar(8) NOT NULL, `RIESGO` int(1) NOT NULL, `FECHA` date NOT NULL,

Anexo 2. Políticas y código fuente.

166

`HORA` time NOT NULL, PRIMARY KEY (`PNOMBRE`,`CLIENTES_IDHOST`,`MODIFICACION`,`FECHA`,`HORA`), KEY `PAQUETES_FKIndex1` (`ESTADOPAQ_TIPO`), KEY `PAQUETES_FKIndex2` (`CLIENTES_IDHOST`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `REDDAYUSOL` CREATE TABLE `REDDAYUSOL` ( `CLIENTES_IDHOST` int(3) NOT NULL, `FIABILIDAD_TIPO` int(1) NOT NULL, `ALTOS` int(10) unsigned NOT NULL, `BAJOS` int(10) unsigned default NULL, `MEDIOS` int(10) unsigned default NULL, `TOTAL` int(10) unsigned default NULL, `PAQUETES` int(3) NOT NULL, `FECHAULTIMO` date NOT NULL, `HORAULTIMO` time NOT NULL, PRIMARY KEY (`CLIENTES_IDHOST`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; -- -------------------------------------------------------- -- Estructura de tabla para la tabla `TIPOMODIFICACION` CREATE TABLE `TIPOMODIFICACION` ( `OPERACION` int(1) NOT NULL, `DESCRIPCION` varchar(10) NOT NULL, PRIMARY KEY (`OPERACION`,`DESCRIPCION`), UNIQUE KEY `OPERACION` (`OPERACION`,`DESCRIPCION`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;