View/Open - Instituto Politécnico Nacional

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 TA
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.
Í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
I
Índice.
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……………………………………………
2.3 Entorno de trabajo del servidor de monitoreo………………….…….
42
43
2.3.1 Servidor de páginas web…………………………………………... 43
2.3.2 Servidor de base de datos………………………………………...
43
2.4 Comentarios finales……………………………………………………...
44
II
Índice.
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
III
Índice.
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
IV
Índice.
Pág.
BIBLIOGRAFÍA…...…………………………………..……………………………..… 113
GLOSARIO………………………………………………..………………………….… 115
ANEXO 1. Manual de usuario……………………………………………………….. 119
ANEXO 2. Políticas y código fuente…………………………………………..…. 123
V
Índice de figuras.
Índice de figuras
Nombre
Pág
Figura 1.1. Tipos de intrusiones…………………………………………………..
Figura 1.2. Clasificación de los IDS………………………………………………
Figura 1.3. Estado de arte de los IDS…………………………………………….
Figura 1.4. Diagrama de flujo de Tripwire………………………………………..
Figura 1.5. Generacion de reportes de Tripwire…………………………………
Figura 1.6. Reportes de Tripwire Enterprise……………………………………..
4
7
12
15
16
16
Figura 2.1. Arquitectura cliente-servidor de SSH………………………………..
Figura 2.2. Arquitectura de SSH…………………………………………………..
Figura 2.3. Canal de comunicación cifrado usando SSH………………………
Figura 2.4. Autenticación de SSH usando llaves públicas……………………..
Figura 2.5. Sistema de directorio de archivos Linux.……………………………
Figura 2.6. Arquitectura del sistema operativo Linux…………………………...
24
25
26
26
33
37
Figura 3.1. Esquema general del sistema………………………………………..
Figura 3.2. Modelo funcional………………………………………………………
Figura 3.3. Diagrama de estados…………………………………………………
Figura 3.4. Gráfico de Estados de Conexión Segura…………………………...
Figura 3.5. Diagrama de actividades del sistema Conexión Segura………….
Figura 3.6. Gráfico de Estados de Análisis de sistema…………………………
Figura 3.7. Diagrama de actividades del sistema Análisis……………………..
Figura 3.8. Gráfico de estados de Búsqueda de cambios……………………..
Figura 3.9. Diagrama de actividades del sistema Análisis……………………..
Figura 3.10. Gráfico de estados de Base de datos modificaciones…………...
Figura 3.11. Diagrama de actividades del sistema Base de datos
modificaciones………………………………………………………..……………..
Figura 3.12. Gráfico de Estados de Impresión de Informes…………………...
Figura 3.13. Diagrama de actividades del sistema Impresión de Informes…..
Figura 3.14. Gráfico de Estados de Generación de perfil de usuarios………..
Figura 3.15. Diagrama de actividades del sistema Impresión de Informes.....
Figura 3.16. Gráfico de Estados de Administración y actualización de
cambios………………………………………………………………………………
Figura 3.17. Diagrama de actividades del sistema administración y
actualización de cambios…………………………………………………………..
Figura 3.18. Gráfico de Estados del sistema Respaldos……………………….
Figura 3.19. Diagrama de actividades del sistema Respaldos………………...
Figura 3.20. Casos de uso del IDS……………………………………………….
Figura 3.21. Arquitectura de la metodología propuesta………………………...
48
55
56
57
57
58
59
60
61
62
Figura 4.1. Arquitectura de DAYUSOL…………………………………………..
Figura 4.2. Diagrama de entorno de red DAYUSOL…………………………...
Figura 4.3. Integridad de archivos utilizando funciones compendio…………..
Figura 4.4. Estructura del directorio de usuarios DAYUSOL…………………..
Figura 4.5. Estructura detallada del directorio REMOTO………………………
Figura 4.6. Búsqueda de modificaciones………………………………………...
Figura 4.7. Dase de datos Entidad-Relación de DAYUSOL…………………...
74
75
76
79
80
81
86
63
64
65
66
67
68
69
70
71
71
72
VI
Índice de figuras.
Nombre
Figura 5.1. Escenario de pruebas de 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……………………………………………………………….
Figura 5.4. Líneas del archivo de reporte después la de detección de
intrusos……………………………………………………………………………….
Figura 5.5. Contenido del archivo instalados…………………………………….
Figura 5.6. Árbol de directorio de cliente de DAYUSOL con los respaldos de
/etc y /usr…………………………………………………………………………….
Figura 5.7. Consulta del estado de los clientes en DAYUSOL2008…………..
Figura 5.8. Tablas de la base de datos DAYUSOL208…………………………
Figura 5.9. Interfaz REPORTE DE RED…………………………………………
Figura 5.10. Interfaz REPORTE DE HOST………………………………………
Figura 5.11. Interfaz REPORTE DETALLADO………………………………….
Figura 5.12. Reportes en formato electrónico (.PDF)…………………………..
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………
Figura 5.15. Elementos detectados por DAYUSOL en el cliente Router……..
Figura 5.16 Elementos detectados por DAYUSOL en el cliente Moniton…….
Figura 5.17. Elementos detectados por DAYUSOL en el cliente Alexin……...
Figura 5.18. Elementos detectados por DAYUSOL en la instalación de
paquetes con APT…………………………………………………………………..
Figura 5.19. Registros de DAYUSOL 2008 de los paquetes instalados con
APT……………………………………………………………………….................
Figura 5.20. Reporte de RED de DAYUSOL posterior a la intrusión Zeus y
Remote Shell….………………………………………………………………….....
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……………………………………………………………….
Figura 5.23. Correo electrónico recibido debido a la intrusión Zeus y
Remote-Shell………………………………………………………………………..
Figura 5.24. Detección del montaje de dispositivos en el mismo análisis de
la intrusión Zeus y Remote-Shell………………………………………………….
Figura 5.25 Recursos utilizados por DAYUSOL en cliente Router……………
Figura 5.26 Recursos utilizados por DAYUSOL en cliente Moniton…………..
Figura 5.27 Recursos utilizados por DAYUSOL en cliente Alexin…………….
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…………………………………………………………………………..
Pag
89
90
90
91
92
92
93
93
94
95
96
96
97
97
98
99
100
101
102
103
104
104
105
105
107
108
109
110
110
VII
Índice de tablas.
Í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……….
Tabla 3.2. Parámetros de validación de permisos de los archivos……………..
Tabla 3.3. Política de propiedades de archivo……………………………………
Tabla 3.4. Política integridad de archivo…………………………………………..
Tabla 3.5. Procesos principales del IDS propuesto………………………………
Tabla 3.6. Crear perfil del cliente…………………………………………………...
Tabla 3.7. Instalar perfil del cliente…………………………………………………
Tabla 3.8. Programación de ejecución…………………………………………….
Tabla 3.9. Establecer método de autenticación…………………………………..
Tabla 3.10. Establecer método de conexión………………………………………
Tabla 3.11. Establecer estructura de análisis……………………………………..
Tabla 3.12. Establecer métodos de análisis de integridad………………………
Tabla 3.13. Establecer métodos de impresión de reportes de análisis………...
Tabla 3.14. Mostar estado del cliente……………………………………………...
Tabla 3.15. Descripción de Conexión segura……………………………………..
Tabla 3.17. Descripción análisis del cliente……………………………………….
Tabla 3.18. Descripción de búsqueda de cambios……………………………….
Tabla 3.19. Descripción de base de datos de modificaciones…………………..
Tabla 3.20. Descripción de impresión de informes……………………………….
Tabla 3.21. Descripción de generación de perfil de usuario…………………….
Tabla 3.22. Descripción de administración y actualización de cambios……….
Tabla 3.23. Descripción del sistema de respaldos……………………………….
49
50
50
50
53
53
54
54
54
54
54
54
55
55
56
58
60
62
64
66
68
69
Tabla 4.1. Especificaciones del entorno de red de DAYUSOL………………….
Tabla 4.2. Especificaciones del SSH implementado en DAYUSOL……………
Tabla 4.3. Especificaciones de estructura de archivos en DAYUSOL…………
Tabla 4.4. Especificaciones de compendios en DAYUSOL……………………..
Tabla 4.5. Resumen de sensores de DAYUSOL…………………………………
Tabla 4.6. Directorio de aplicaciones de DAYUSOL……………………………..
Tabla 4.7. Estructura de políticas de DAYUSOL…………………………………
Tabla 4.8. Estructura de políticas de DAYUSOL…………………………………
Tabla 4.9. Políticas y riesgo implementados en DAYUSOL…………………….
Tabla 4.10. Programaciones de análisis utilizadas en DAYUSOL……………...
Tabla 4.11. Base de datos de estadísticas y reportes de DAYUSOL………….
75
76
77
78
78
80
83
83
84
85
86
Tabla 5.1. Resumen de modificaciones en el cliente Router……………………
Tabla 5.2. Resumen de modificaciones en el cliente Moniton…………………..
Tabla 5.3. Resumen de modificaciones en el cliente Alexin…………………….
Tabla 5.4. Resumen de modificaciones con la instalación de paquetes……….
Tabla 5.5. Características de hardware del cliente Router………………………
Tabla 5.6. Características de hardware del cliente Miniton……………………..
Tabla 5.7. Características de hardware del cliente Alexin……………………….
Tabla 5.8. Características de hardware del cliente Alex-lap-hp………………...
98
99
100
101
106
106
108
109
VIII
Introducción.
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
IX
Introducción.
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
reconocimiento y detección de intrusiones.
permita
realizar
pruebas
de
• Analizar el uso de recursos de hardware necesarios para el análisis de
detección de modificaciones implementado.
X
Introducción.
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
XI
Introducción.
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.
XII
Introducción.
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.
XIII
Capitulo 1. Estado del arte.
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.
1
Capitulo 1. Estado del arte.
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.
2
Capitulo 1. Estado del arte.
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.
3
Capitulo 1. Estado del arte.
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].
4
Capitulo 1. Estado del arte.
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.
5
Capitulo 1. Estado del arte.
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.
6
Capitulo 1. Estado del arte.
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.
7
Capitulo 1. Estado del arte.
•
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).
8
Capitulo 1. Estado del arte.
•
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
9
Capitulo 1. Estado del arte.
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].
10
Capitulo 1. Estado del arte.
•
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.
11
Capitulo 1. Estado del arte.
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
12
Capitulo 1. Estado del arte.
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
13
Capitulo 1. Estado del arte.
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
14
Capitulo 1. Estado del arte.
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).
15
Capitulo 1. Estado del arte.
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.
16
Capítulo 2. Marco teórico.
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].
17
Capítulo 2. Marco teórico.
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
18
Capítulo 2. Marco teórico.
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.
19
Capítulo 2. Marco teórico.
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 alguna 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.
20
Capítulo 2. Marco teórico.
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].
21
Capítulo 2. Marco teórico.
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:
22
Capítulo 2. Marco teórico.
•
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
23
Capítulo 2. Marco teórico.
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.
24
Capítulo 2. Marco teórico.
•
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.
25
Capítulo 2. Marco teórico.
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).
26
Capítulo 2. Marco teórico.
•
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.
27
Capítulo 2. Marco teórico.
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]:
28
Capítulo 2. Marco teórico.
•
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
29
Capítulo 2. Marco teórico.
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.
30
Capítulo 2. Marco teórico.
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.
31
Capítulo 2. Marco teórico.
/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.
32
Capítulo 2. Marco teórico.
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.
33
Capítulo 2. Marco teórico.
•
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
0
1
2
3
4
5
6
7
Binario
000
001
010
011
100
101
110
111
Permisos
----x
-w-wx
r-r-x
rwrwx
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'.
34
Capítulo 2. Marco teórico.
•
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
35
Capítulo 2. Marco teórico.
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.
36
Capítulo 2. Marco teórico.
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.
37
Capítulo 2. Marco teórico.
•
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
38
Capítulo 2. Marco teórico.
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.
39
Capítulo 2. Marco teórico.
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.
40
Capítulo 2. Marco teórico.
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.
41
Capítulo 2. Marco teórico.
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.
42
Capítulo 2. Marco teórico.
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.
43
Capítulo 2. Marco teórico.
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.
44
Capitulo 3. Análisis y diseño del sistema.
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.
45
Capitulo 3. Análisis y diseño del sistema.
•
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.
46
Capitulo 3. Análisis y diseño del sistema.
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.
47
Capitulo 3. Análisis y diseño del sistema.
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
Comandos
Consola
SERVIDOR
Almacenamiento
Respuesta
BD
ANALISIS
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
48
Capitulo 3. Análisis y diseño del sistema.
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
Alto (High)
Características de los elementos
• 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.
49
Capitulo 3. Análisis y diseño del sistema.
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.
SUID,
GUID
1 bit
Permisos
Permisos Permisos
usuario
grupo
3 bits
3 bits
Permisos
otros
3 bits
Propietario y grupos
Propietario Grupo del
archivo
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.
Enlaces
Política propiedades de archivo
Nombre Permisos Propietario
y grupos
Tamaño
Tabla 3.3. Política de propiedades de archivo.
Nombre
Política integridad de archivo
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
50
Capitulo 3. Análisis y diseño del sistema.
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
51
Capitulo 3. Análisis y diseño del sistema.
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.
52
Capitulo 3. Análisis y diseño del sistema.
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
R1.1
R1.2
R1.3
R1.4
R1.5
R1.6
R1.7
R1.8
R1.9
R1.10
FUNCIÓN
El sistema realiza un análisis de la integridad de
archivos para un equipo
El sistema realiza una prueba de disponibilidad
del equipo en la red LAN
El sistema permite diseñar un archivo de políticas
para el análisis del equipo
El sistema utiliza un módulo para realizar la
conexión segura entre el cliente y el servidor de
monitoreo
El sistema implementa un módulo para garantizar
la autenticación del cliente frente al servidor de
monitoreo
El sistema implementa un módulo para realizar el
análisis de integridad de los archivos del sistema
del cliente
El sistema implementa un módulo de búsqueda
de modificaciones del análisis del cliente
El sistema contiene un módulo para actualizar el
estado del sistema y los cambios generados en la
base de datos.
El sistema contiene una interfaz de despliegue de
resultados para el administrador
El sistema contiene un módulo de edición y
actualización del estado del equipo
CATEGORIA
Evidente
Oculto
Evidente
Oculta
Oculta
Oculta
Oculta
Oculto
Evidente
Evidente
Tabla 3.5. Procesos principales del IDS propuesto.
CASO DE USO
Tipo
Descripción
Crear perfil del cliente
Primario
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.
53
Capitulo 3. Análisis y diseño del sistema.
CASO DE USO
Tipo
Descripción
Instalar perfil de cliente
Primario
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
Tipo
Descripción
Programación de ejecución
Primario
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
Tipo
Descripción
Establecer método de autenticación
Primario
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
Tipo
Descripción
Establecer método de conexión
Primario
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
Tipo
Descripción
Establecer estructura de análisis
Primario
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
Tipo
Descripción
Establecer métodos de análisis de integridad
Primario
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.
54
Capitulo 3. Análisis y diseño del sistema.
CASO DE USO
Tipo
Descripción
Establecer métodos de impresión de los reportes de
análisis
Primario
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
Tipo
Descripción
Mostrar estado del cliente
Primario
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.
B.
C.
D.
E.
F.
G.
H.
Conexión segura
Análisis de sistema
Búsqueda de cambios
Base de datos modificaciones
Impresión de informes
Generación de perfil de usuario
Actualización de cambios
Sistema de respaldos
55
Capitulo 3. Análisis y diseño del sistema.
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
1. Este caso comienza cuando el servidor
de monitoreo desea realizar una
ejecución de análisis
3. El servidor de monitoreo solicita una
conexión de datos segura
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
Respuesta del sistema
2.El sistema realiza una prueba de
disponibilidad del equipo en la red LAN
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.
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.
56
Capitulo 3. Análisis y diseño del sistema.
LLAVE VALIDA
USUARIO AUTORIZADO
ENVIAR
PETICIÓN DE
CONEXION
ESTABLECER
CONEXIÓN
AUTENTICAR
CLIENTE
[CORRECTA]
CONECTAR
CANAL SEGURO
CAMBIAR
CONFIGURACIÓN
ENVIAR
ARCHIVOS
EJECUTAR
COMANDO
REMOTO
RECIBIR
ARCHIVOS
DESCONECTAR
CANAL SEGURO
CERRAR
CONEXIÓN
Figura 3.4. Gráfico de Estados de Conexión Segura.
SERVIDOR
AUDITORIA
CLIENTE
ENVIAR
PETICIÓN
ACEPTAR
PETICIÓN
ENVIAR
AUTENTICACIÓN
VALIDAR
AUTENTICACIÓN
SISTEMA DE
RESPALDOS
[CORRECTO]
SOLICITAR
CANAL SEGURO
BUSCAR
ARCHIVO
POLITICA
ANALISIS DE
SISTEMA
ABRIR
CANAL SEGURO
DESCRITO EN
"ANALISIS DEL
SISTEMA"
EJECUTAR
ANALISIS
SOLICITAR
CERRAR
CANAL
CERRAR
CANAL
EJECUTAR
RESPALDO
DESCRITO EN
"ANALISIS DEL
SISTEMA"
RECIBIR
NOTIFICACIÓN
CANAL
CERRADO
Figura 3.5. Diagrama de actividades del sistema Conexión Segura.
57
Capitulo 3. Análisis y diseño del sistema.
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
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.
6. El servidor almacena los datos
recibidos en la estructura del cliente.
Respuesta del sistema
3. El cliente analiza con una herramienta
de búsqueda los directorios requeridos
por el 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.
4. El cliente aplica técnicas compendio a
la estructura de sus archivos.
5.-El cliente envía la información
recolectada al servidor.
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.
CONSULTAR
PERFIL DE
USUARIO
REALIZAR
ANÁLISIS
TRANSFERIR
INFORMACIÓN
DEL CLIENTE
A SERVIDOR
i
ALMACENAR
INFORMACIÓN
EN SERVIDOR
CERRAR
PERFIL DE
USUARIO
Figura 3.6. Gráfico de Estados de Análisis de sistema.
58
Capitulo 3. Análisis y diseño del sistema.
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).
SERVIDOR MONITOREO
CLIENTE
BUSCAR
DIRECTORIO
DEL CLIENTE
OBTENIDO DE
"GENERACION DE
PERFIL DE
USUARIO"
BUSCAR
ARCHIVO DE
POLITICAS
SOLICITAR
ARCHIVOS
DE INTEGRIDAD
ENVIAR
ARCHIVOS DE
INTEGRIDAD
COPIAR
ARCHIVOS
VALIDAR
INTEGRIDAD
BUSCAR
ARCHIVO
POLITICA
[CORRECTOS]
ESCRIBIR
RIESGO
EN REPORTE
GUARDAR EN
EL DIRECTORIO
DEL CLIENTE
ANALIZAR
ESTRUCTURA
DE DIRECTORIO
GENERAR
FUNCIÓN
COMPENDIO DE
LOS ARCHIVOS
ENVIAR
ESTRUCTURA
Y COMPENDIOS
DE ARCHIVOS
CERRAR
ARCHIVO DE
POLITICAS
Figura 3.7. Diagrama de actividades del sistema Análisis.
59
Capitulo 3. Análisis y diseño del sistema.
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
1. Este caso se inicia de manera
inmediata cuando se termino el análisis
de directorio del cliente.
3. El servidor de monitoreo abre el
directorio que obtuvo del análisis
6.El servidor de almacena el archivo de
reporte obtenido en el directorio del
cliente
Respuesta del sistema
2.El sistema realiza una búsqueda de la
estructura del directorio del cliente en el
servidor
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).
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.
BUSCAR
DIRECTORIO
CLIENTE
BUSCAR
DIRECTORIO
ANÁLISIS
ANALIZAR
DIRECTORIO
CLIENTE-ANÁLISIS
ACTUALIZAR
REPORTES
CLIENTE
Figura 3.8. Gráfico de estados de Búsqueda de cambios.
60
Capitulo 3. Análisis y diseño del sistema.
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.
61
Capitulo 3. Análisis y diseño del sistema.
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
1. Se inicia cuando se ha terminado la
búsqueda de cambios. El sistema de
monitoreo abre el archivo de reporte de
diferencias.
3. El servidor de monitoreo establece la
conexión con el servidor web
4. El servidor web establece la conexión
con la base de datos
6. El servidor de auditoría actualiza el
archivo de reporte.
Respuesta del sistema
2.El sistema obtiene todos los elementos
modificados y el riego que representan
4. El sistema
compara directamente
archivo del servidor de monitoreo y del
cliente en busca de modificaciones
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.
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).
BUSCAR
DIRECTORIO
DEL CLIENTE
ANALIZAR
REPORTE
MODIFICAR
ARCHIVOS
GUARDAR
CAMBIOS
ACTUALIZAR
ESTADO
DEL CLIENTE
ADMINISTRADOR
Figura 3.10. Gráfico de estados de Base de datos modificaciones.
62
Capitulo 3. Análisis y diseño del sistema.
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.
63
Capitulo 3. Análisis y diseño del sistema.
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
1. Este caso comienza cuando el
administrador solicita un reporte de
estado del cliente
5. El administrador solicita un informe
impreso
4. El servidor de monitoreo cierra el
archivo de políticas del cliente
Respuesta del sistema
2. El sistema busca la información del
directorio del clientes
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.
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.
64
Capitulo 3. Análisis y diseño del sistema.
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.
ADMINISTRADOR
SERVIDOR WEB
BASE DE DATOS
SERVIDOR
MONITOREO
INICIA
NAVEGADOR
INICIA
APLICACIÓN
REPORTES
[DISPONIBLE]
ENVÍA
FORMULARIO
SELECCIONA
CLIENTE
SOLICITA
INFORMACIÓN
DEL CLIENTE
BUSCA
REGISTRO
CLIENTE
DESPLIEGA
INFORMACIÓN
NO DISPONIBLE
[EXISTE]
DESPLIEGA
INFORMACIÓN
DEL CLIENTE
SELECCIONA
FORMATO
IMPRESO
ENVÍA
INFORMACIÓN
DEL CLIENTE
CREA
ARCHIVO
IMPRESO
ALMACENA
REPORTE
IMPRESO
ACTUALIZA
DIRECTORIO
DEL CLIENTE
Figura 3.13. Diagrama de actividades del sistema Impresión de Informes.
65
Capitulo 3. Análisis y diseño del sistema.
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
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
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 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.
Respuesta del sistema
2. El sistema presenta una interfaz de
tipo comando y abre un archivo
predefinido de políticas
4 .El sistema almacena los perfiles de
usuario y deja listo para el 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
66
Capitulo 3. Análisis y diseño del sistema.
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.
67
Capitulo 3. Análisis y diseño del sistema.
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
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.
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
5. El sistema termina cerrando la interfaz
de actualización.
Respuesta del sistema
2. El servidor presenta una interfaz de
tipo WEB, consistente en un formulario.
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.
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.
ABRIR
ARCHIVO
BUSCAR
ARCHIVO DE
REPORTE
ACTUALIZAR
REPORTES EN
BASE DE DATOS
EDITAR
ESTADO
CLIENTE
[SIN MODIFICACIONES]
ALMACENAR
CAMBIOS DEL
CLIENTE
Figura 3.16. Gráfico de Estados de Administración y actualización de cambios.
68
Capitulo 3. Análisis y diseño del sistema.
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).
ADMINISTRADOR
SERVIDOR WEB
SOLICITA
ACTUALIZAR
CLIENTE
ACEPTA
PETICIÓN
SELECCIONA
CLIENTE
ENVÍA
FORMULARIO
[OTRO CLIENTE]
SOLICITA
INFORMACIÓN
DEL CLIENTE
BASE DE DATOS
SERVIDOR
MONITOREO
BUSCA
INFORME
DE CAMBIOS
DESPLIEGA
INFORMACIÓN
NO DISPONIBLE
[EXISTE]
DESPLIEGA
INFORMACIÓN
DEL CLIENTE
ENVÍA
INFORMACIÓN
DEL CLIENTE
ENVÍA
ACTUALIZACIÓN
DE CAMBIOS
ACTUALIZA
REGISTRO
DEL CLIENTE
SELECCIONA
CAMBIOS
PERMITIDOS
ACTUALIZA
DIRECTORIO
DEL CLIENTE
Figura 3.17. Diagrama de actividades del sistema administración y actualización de cambios.
69
Capitulo 3. Análisis y diseño del sistema.
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
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.
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.
Respuesta del sistema
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
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.
70
Capitulo 3. Análisis y diseño del sistema.
SERVIDOR
AUDITORIA
CLIENTE
BUSCAR AUDITORIA
DE RESPALDO
BASE DE
DATOS
EC
TO
R
IO
]
BUSCAR ESTRUCTURA
DE DIRECTORIO
[O
TR
O
D
IR
COMPRIMIR DIRECTORIO
ALMACENAR ARCHIVO
DIRECTORIO CLIENTE
ENVIAR ARCHIVO
DE RESPALDO
ACTUALIZAR FECHA
RESPALDO
ACTUALIZAR REGISTRO
DEL CLIENTE
CERRAR ARCHIVO
DE POLITICAS
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.
71
Capitulo 3. Análisis y diseño del sistema.
CLIENTE
SENSOR
SERVIDOR
CONTROL CENTRALIZADO
CANAL DE
COMUNICACIÓN
SEGURO
DATOS
1
2
DETECCION DE
MODIFICACIONES
3
4
BITACORA
ALERTA
6
5
7
REPORTE
8
10
REPORTE
WEB
RESPONSABLE
DE SEGURIDAD
9
DATOS DE
FORENCIA
BASE DE
DATOS
Figura 3.21. Arquitectura de la metodología propuesta.
72
Capitulo 4. Implementación del sistema.
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.
73
Capitulo 4. Implementación del sistema.
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
SENSOR
SERVIDOR
CONTROL CENTRALIZADO
CANAL DE
COMUNICACIÓN
SEGURO
DATOS
1
2
DETECCION DE
MODIFICACIONES
3
4
BITACORA
ALERTA
6
5
7
REPORTE
8
10
REPORTE
WEB
RESPONSABLE
DE SEGURIDAD
9
DATOS DE
FORENCIA
BASE DE
DATOS
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.
74
Capitulo 4. Implementación del sistema.
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
Tipo de red
Tecnología
Especificación
Red de área local LAN
LAN Ethernet
LAN inalámbrica
1000Base-T
Medio de comunicación
UTP categoría 5
Topología
Estrella
Clase de red
Protocolos
Puertos
Clase C
TCP/IP
Servidor (IDS)
Clientes
Características
Especificación IEE 802
IEEE 802.3
IEEE 802.11
Norma de cableado
EIA/TIA-568-B
EIA/TIA 569
Máximo 254 host
23 SSH, 80 HTTP,
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.
75
Capitulo 4. Implementación del sistema.
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
Cliente de OpenSsh
Servidor de IDS
Servidores de OpenSsh
Clientes de análisis
Características
Llave privada
/root/.ssh/id_rsa
Llave pública
id_rsa.pub [DAYUSOL]
Llave privada
/root/.ssh/id_rsa
Host permitidos
known_hosts/id_rsa.pub
[DAYUSOL]
Tabla 4.2. Especificaciones del SSH implementado en DAYUSOL.
76
Capitulo 4. Implementación del sistema.
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
Aplicación
Ruta del directorio de búsqueda
Criterio de búsqueda
Tipo de elemento
Información del elemento
Descripción
Find ( /usr/bin/find)
Ruta absoluta (/)
Permisos , usuarios, fechas de acceso
Archivos (f)
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.
77
Capitulo 4. Implementación del sistema.
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
Aplicación
Ruta del directorio de búsqueda
Criterio de búsqueda
Tipo de elemento
Acción si se encuentra el elemento
Descripción
Find ( /usr/bin/find)
Ruta absoluta (/)
Permisos , usuarios, fechas de acceso
Archivos (f)
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
Estructura de Directorio
Integridad de Archivos
Implementación
Características
Find
Se ejecuta en el cliente
/usr/bin/find
md5sum
Función Hash (compendio)
Se ejecuta en el cliente
/usr/bin/md5sum
SHA-1
Función Hash (compendio)
Se ejecuta en el cliente
/usr/bin/sha-1
Búsqueda de archivos y
sus propiedades dentro de
directorios
Huella digital de 128 bits
Uso de algoritmo MD5
Huella digital de 160 bits
Uso de algoritmo SHA-1
Tabla 4.5. Resumen de sensores de DAYUSOL.
78
Capitulo 4. Implementación del sistema.
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
POLITICAS
Cliente.pol
PAQUETES
REMOTO
compendios
REPORTES
estructuras
LOCAL
Md5sum
Libc.so.6
Ld-linux.so
Figura 4.4. Estructura del directorio de usuarios DAYUSOL.
79
Capitulo 4. Implementación del sistema.
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.
A
CLIENTE
B
REMOTO
C
ESTRUCTURA
COMPENDIO
D
RIESGO
ALTO
RIESGO
MEDIO
RIESGO
BAJO
RIESGO
ALTO
RIESGO
MEDIO
RIESGO
BAJO
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.
80
Capitulo 4. Implementación del sistema.
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, MODIFICADOACTUALIZADO 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.
81
Capitulo 4. Implementación del sistema.
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.
82
Capitulo 4. Implementación del sistema.
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
Directorio de datos
Riesgos de seguridad
Define los directorios a
examinar
Define las propiedades
del archivo analizado.
Revisión de paquetes
Implementación
Características
/home/dayusol/usuarios
ALTO
5
MEDIO
3
BAJO
1
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
Permisos
%m %n %u %g %s %p
Dpkg
Directorio del cliente
Niveles
de
riesgo,
dependientes del uso del
equipo cliente.
Estructura de directorios
de primer nivel de Linux,
capacidad
de
establecimiento de hasta
10
niveles
en
cada
directorio.
Características del archivo
descritas en la Tabla 4.2.
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
Archivos
ejecutables
Archivos del
directorio /bin
Archivos del
directorio /boot
Implementación
Características
Huella digital
(Md5)
Características
Huella digital
(Md5)
Características
Huella digital
(Md5)
/usr/bin/find / -xdev -perm +6111
-type f -printf "%m %n %u %g %s %p\n"
/usr/bin/find / -xdev -perm +6111
-type f -exec /usr/bin/md5sum {} \;
/usr/bin/find /bin -type f -perm +666
-printf "%m %n %u %g %s %p\n"
/usr/bin/find /bin -type f -perm +666
-exec /usr/bin/md5sum {} \;
/usr/bin/find /boot -type f -perm +666
-printf "%m %n %u %g %s %p\n"
/usr/bin/find /boot -type f -perm +666
-exec /usr/bin/md5sum {} \;
Tabla 4.8. Estructura de políticas de DAYUSOL.
83
Capitulo 4. Implementación del sistema.
Nivel
de
riesgo
ALTO
Descripción
Aplicaciones
(ejecutables)
/bin
/root
/boot
/etc
/usr
/lib
/sbin
MEDIO
/media
BAJO
/opt
/mnt
/lost+found
/var
/proc
(no
implementado)
/home
Propiedad de root
Bit suid
Bit guid
Programas ejecución root
Propiedad de root
Archivos del administrador
Archivos de arranque
Configuración
• Usuarios
• Contraseñas
• Servicios
• Dispositivos
• Red
• Puertos
• Programación de tareas
Solo lectura. Ejecución y modificación restringida a root,
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
Librerías. Recursos que son utilizados por las
aplicaciones.
Programas de ejecución de los usuarios para el trabajo
con Shell. Propiedad del administrador
Montaje de dispositivos
• Ópticos de lectura-escritura
• Almacenamiento removible
Permitir lectura y escritura
Aplicaciones opcionales de los usuarios.
Igual que el directorio /media (menor uso)
Recuperación de archivos. Uso exclusivo de root
Contenido variable
• Logs del sistema
• Servidor web
Procesos del sistema, variable de acuerdo al
comportamiento y lo servicios utilizados.
Importante fuente de análisis de comportamiento dinámico
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.
84
Capitulo 4. Implementación del sistema.
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
Cada 20 minutos de lunes a viernes
Una vez cada día a las 2 de mañana
Descripción de la tarea en cron
[Minuto Hora Día Mes Año]
*/20 * 2-5 * *
02***
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.
85
Capitulo 4. Implementación del sistema.
Figura 4.7. Dase de datos Entidad-Relación de DAYUSOL
Recurso
Estructura de la base de
datos de cada equipo
Reporte de análisis de
integridad individual
Reporte de Incidentes
Nivel de riesgos y estado
del sistema
Reporte de Actualización
/reparación de cada
equipo
Estadísticas del total de
sistemas
Implementación
Características
Base
de
DAYUSOL2008
datos Integridad
referencial,
Implementación en Mysql
Determinación de nivel de
fiabilidad del equipo cliente
Formulario
“Reporte Selección de estado del
Cliente” y “Fiabilidad Host” cliente.
Fiabilidad
del
cliente
dependiente del número
de elementos detectados y
su riesgo.
Módulo reportes
Número de elementos de
la red y fiabilidad.
Archivo “Reporte Cliente”
en formato electrónico de
lectura (PDF).
Política de seguridad
RIESGOS: ALTO, MEDIO,
BAJO.
Estado del sistema: Fiable,
No fiable, indeterminado.
Formulario “Actualización
Actualiza
elementos
de elementos”
detectados.
Determinación del estado
del cliente.
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.
86
Capitulo 4. Implementación del sistema.
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.
87
Capitulo 4. Implementación del sistema.
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.
88
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
89
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
90
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
91
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
92
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
93
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
2.
3.
4.
Numero de equipos clientes
Resumen de fiabilidad de los clientes
Gráfica del estado de la red
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.
94
Capitulo 5. Pruebas del sistema DAYUSOL.
1
3
2
5
4
4a
4b
4c
4d
4e
Figura 5.10. Interfaz REPORTE DE HOST.
•
REPORTE DE HOST (ver Figura 5.10):
1.
2.
3.
4.
Datos generales del cliente
Resumen de elementos detectados clasificados por el nivel de riesgo
Gráfica del estado del cliente
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
95
Capitulo 5. Pruebas del sistema DAYUSOL.
1
2
3
2a
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.
96
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
97
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
Consola
Comando
Agregados
35
Eliminados
35
Modificados
35
Total
105
DAYUSOL
105
Script
20
40
20
80
80
Aplicaciones
43
86
82
211
208
Tabla 5.1. Resumen de modificaciones en el cliente Router.
Figura 5.15. Elementos detectados por DAYUSOL en el cliente Router.
98
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
Consola
Agregados
Eliminados
Modificados
Total
DAYUSOL
Comando
10
50
10
70
70
Script
20
40
20
80
80
Aplicaciones
22
18
43
83
83
Tabla 5.2. Resumen de modificaciones en el cliente Moniton.
Figura 5.16 Elementos detectados por DAYUSOL en el cliente Moniton
99
Capitulo 5. Pruebas del sistema DAYUSOL.
•
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.
Consola
Agregados
Eliminados
Modificados
Total
DAYUSOL
Comando
40
36
15
91
91
Aplicaciones
Script
30
40
18
88
88
36
3
45
84
84
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.
100
Capitulo 5. Pruebas del sistema DAYUSOL.
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, libbonoboui20, 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
Agregados
9
Eliminados
0
Modificados
0
Total
9
DAYUSOL
9
etc
0
0
1
1
1
usr
103
0
5
108
108
home
0
0
3
3
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.
101
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
102
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
103
Capitulo 5. Pruebas del sistema DAYUSOL.
Figura 5.20. Reporte de RED de DAYUSOL posterior a la intrusión Zeus y Remote-Shell.
104
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
105
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
106
Capitulo 5. Pruebas del sistema DAYUSOL.
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
Procesador
Pentium IV
700 Mhz
Ejecutables
bin
boot
etc
usr
dev
lib
mnt
opt
sbin
media
home
Total
192.168.1.1 Router
Memoria
Memoria
RAM
swap
255.76
433.77
Mbytes
Mbytes.
Directorios (Mbytes)
Tiempo de
análisis
18.52 seg.
2100
3.6
6.5
23
1400
216
58
4
4
3600
12
74
7501.1
Tabla 5.5. Características de hardware del cliente Router.
107
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
Procesador
Pentium IV
2.4 Ghz
Ejecutables
bin
boot
etc
usr
dev
lib
mnt
opt
sbin
media
home
Total
192.168.1.10 Miniton
Memoria
Memoria
RAM
swap
255.736
971.924
Mbytes
Mbytes.
Directorios (Mbytes)
Tiempo de
análisis
12.30 seg.
2300
4.8
18
9.7
1800
0.064
154
4
4
6.8
12
128
4441.364
Tabla 5.6. Características de hardware del cliente Miniton.
108
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
Procesador
Pentium IV
1.7 Ghz
Ejecutables
bin
boot
etc
usr
dev
lib
mnt
opt
sbin
media
home
Total
192.168.1.11 Alexin
Memoria
Memoria
RAM
swap
516.688
1180.696
Mbytes
Mbytes
Directorios (Mbytes)
Tiempo de
análisis
13 seg.
2600
3.6
12
24
1800
224
58
4
4
3.6
12
8.8
4754
Tabla 5.7. Características de hardware del cliente Alexin.
109
Capitulo 5. Pruebas del sistema DAYUSOL.
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
Memoria
Memoria
Tiempo de
RAM
swap
análisis
Centrino 2
1025.752
967.672
Duo 1.83 Ghz Mbytes
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
Procesador
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”.
110
Capitulo 5. Pruebas del sistema DAYUSOL.
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.
111
Capitulo 6. Conclusiones y trabajos a futuro.
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.
111
Capitulo 6. Conclusiones y trabajos a futuro.
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.
112
Bibliografía
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
113
Bibliografía
[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.
114
Bibliografía
[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.
GNU/Linux 3.1 Bible.
Wiley Publishing, Estados Unidos 2005.
[39]
CERT. Computer Emergency Response Team.
http://www.cert.org/cert/
and Vyas Jaldhar, Debian
115
Bibliografía
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.
116
Bibliografía
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
117
Bibliografía
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.
118
Anexo 1. Manual de usuario.
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.
119
Anexo 1. Manual de usuario.
• 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
120
Anexo 1. Manual de usuario.
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
121
Anexo 1. Manual de usuario.
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.
122
Anexo 2. Políticas y código fuente.
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
Nivel de riesgo
Directorio
Tipo de elemento
Descripción del elemento
LABEL \n5
000
E. Estructura de archivo / H.Compendio
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
Directorio de búsqueda
Criterio de búsqueda
Acción para elementos
Encontrados
/usr/bin/find
/
-xdev -perm +6111 -type f
-printf "%m %n %u %g %s %p\n"
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
DEFINE MEDIO
DEFINE BAJO
ALTO
MEDIO
BAJO
123
Anexo 2. Políticas y código fuente.
#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 {} \;
124
Anexo 2. Políticas y código fuente.
########################################################
# 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 \
125
Anexo 2. Políticas y código fuente.
#
-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 {} \;
126
Anexo 2. Políticas y código fuente.
#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
127
Anexo 2. Políticas y código fuente.
#9
#5
#3
#1
PAQUETES
ALTO
MEDIO
BAJO
DEFINE ALTO
DEFINE MEDIO
DEFINE BAJO
ALTO
MEDIO
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 \) \
128
Anexo 2. Políticas y código fuente.
-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
129
Anexo 2. Políticas y código fuente.
#
#
#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
130
Anexo 2. Políticas y código fuente.
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
131
Anexo 2. Políticas y código fuente.
# 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
DEFINE MEDIO
DEFINE BAJO
ALTO
MEDIO
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
########################################################
132
Anexo 2. Políticas y código fuente.
# 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 {} \;
133
Anexo 2. Políticas y código fuente.
## 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 \
134
Anexo 2. Políticas y código fuente.
/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'
135
Anexo 2. Políticas y código fuente.
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
DEFINE MEDIO
DEFINE BAJO
ALTO
MEDIO
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
136
Anexo 2. Políticas y código fuente.
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\)" \
137
Anexo 2. Políticas y código fuente.
#
#
#
#
#
#
#
-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
#
########################################################
138
Anexo 2. Políticas y código fuente.
#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 \
139
Anexo 2. Políticas y código fuente.
/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
140
Anexo 2. Políticas y código fuente.
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
141
Anexo 2. Políticas y código fuente.
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;
142
Anexo 2. Políticas y código fuente.
}
}
/* 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";
143
Anexo 2. Políticas y código fuente.
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')";
144
Anexo 2. Políticas y código fuente.
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')";
145
Anexo 2. Políticas y código fuente.
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`
146
Anexo 2. Políticas y código fuente.
(`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];
147
Anexo 2. Políticas y código fuente.
$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;
148
Anexo 2. Políticas y código fuente.
$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;
149
Anexo 2. Políticas y código fuente.
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')";
150
Anexo 2. Políticas y código fuente.
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;
?>
151
Anexo 2. Políticas y código fuente.
___________________________________________________________________________________
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;
152
Anexo 2. Políticas y código fuente.
$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");
?>
153
Anexo 2. Políticas y código fuente.
___________________________________________________________________________________
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) )
{
154
Anexo 2. Políticas y código fuente.
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 ) )
155
Anexo 2. Políticas y código fuente.
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";
}
156
Anexo 2. Políticas y código fuente.
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>' ;
157
Anexo 2. Políticas y código fuente.
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
//
158
Anexo 2. Políticas y código fuente.
// 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 ;
}
159
Anexo 2. Políticas y código fuente.
////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");
160
Anexo 2. Políticas y código fuente.
$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);
161
Anexo 2. Políticas y código fuente.
$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%"> </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>
162
Anexo 2. Políticas y código fuente.
<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ÑO, ENLACES, USUARIOS Y GRUPO</font></strong></div></td>
</tr>
<tr>
<td width="12%"> </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>
163
Anexo 2. Políticas y código fuente.
<?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`,`H
ORA`)
) 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,
164
Anexo 2. Políticas y código fuente.
`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,
165
Anexo 2. Políticas y código fuente.
`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;
166