INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

“PROPUESTA DE UN SISTEMA DE DETECCIÓN DE INTRUSOS PARA MONITOREAR LA RED INSTITUCIONAL DE ESIME ZACATENCO”

PRESENTA:

ABRIL FERNANDA GARCÍA RAMÍREZ

RAFAEL MARTÍNEZ GARCÍA

Para obtener el título de

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

ASESOR TÉCNICO

M. en C. FERNANDO NOYA CHÁVEZ

ASESOR TEÓRICO

M. en C. KARLA SANDRA ARELLANO GARCÍA

M. en C. GREGORIO PÉREZ GARCÍA

MÉXICO, D.F. MAYO DE 2008

ÍNDICE GENERAL N°

PAG

GLOSARIO DE TÉRMINOS TÉCNICOS 1

INTRODUCCIÓN 4

JUSTIFICACIÓN 6

OBJETIVO GENERAL 10

OBJETIVOS ESPECÍFICOS 11

MARCO DE TRABAJO 12

ANTECEDENTES 13

CAPITULO I. SISTEMAS DE DETECCIÓN DE INTRUSOS

1.1 Seguridad en Redes en Comunicaciones 16

1.1.1 Tipos de ataques 16

1.1.1.1 Exploración de puertos 17

1.1.1.2 Suplantación (Spoofing) 18

1.1.1.3 Interceptación 19

1.1.1.4 Negaciones de servicios 20

1.1.1.5 Ataques vía Web 20

1.1.2 Virus 21

1.1.3 Antivirus 21

1.1.4 Seguridad en Linux 22

1.1.5 Mecanismos de Seguridad Informática 22

1.1.5.1 Mecanismos de Prevención 23

1.1.5.2 Mecanismos de Detección 24

1.1.5.3 Mecanismos de Recuperación 24

1.2 Sistemas de Detección de Intrusos 24

1.2.1 Arquitectura de los IDS 25

1.2.1.1 Common Intrusion Detection Framework (CIDF) 25

1.2.1.2 Common Intrusion Specification Language (CISL) 26

1.2.1.3 Autopost de AusCERT 26

1.2.1.4 Arquitectura de IDWG (Intrusion Detection Working Group) 27

1.2.2 Clasificación de los IDS 27

1.2.2.1 Enfoque o Tipo de Análisis 28

1.2.2.2 Origen de los Datos 29

1.2.2.3 Estructura 31

1.2.2.4 Comportamiento o Respuesta 32

1.2.3 Ubicación de los IDS 33

1.3 Productos Comerciales (IDS) 34

1.3.1 Dragon-Enterasys Networks 34

1.3.2 NetRanger-Cisco Systems 36

1.3.3 StoneGate 38

CAPITULO II. IDS SNORT 2.1 Breve Reseña Histórica 40

2.1.1 ¿Qué es Snort? 40

2.1.2 Arquitectura del IDS Snort 40

2.1.2.1 Decodificador de paquetes (Visor de Paquetes) 42

2.1.2.2 Preprocesador 42

2.1.2.3 Motor de detección 43

2.1.2.4 Subsistema de alerta/ registros (Log) 44

2.2 Instalación del IDS Snort 44

2.2.1 Linux como plataforma del SO Utilizado 45

2.2.1.1 Orígenes de Linux 45

2.2.2 Bases de Datos 48

2.2.2.1 MySQL 46

2.2.3 Interfaces gráficas de bases de datos para Snort 50

2.2.3.1 BASE (Basic Analysis And Security Engine ) 50

2.2.3.2 ACID (Analysis Console for Intrusion Databases) 52

2.2.4 Servidores WEB 53

2.2.4.1 Apache 54

2.3 Modos de Alerta 57

2.3.1 Modo Sniffer (Sniffer Mode) 57

2.3.2 Modo de Registro de Paquetes (Packet Logger Mode) 57

2.3.3 Modo NIDS (Network Detection Intrusión System) 58

2.3.4 Modo en Línea (Inline Mode) 56

2.4 Técnicas de Detección de los IDS 59

2.4.1 Detección de Paquetes 59

2.4.2 Técnicas de Inteligencia Artificial 59

2.4.3 Métodos Estadísticos 59

CAPITULO III PRUEBAS Y PROPUESTA DE IMPLEMENTACIÓN

3.1 Introducción 61

3.2 Implantación de IDS Snort en un punto de la red de ESIME Zacatenco 61

3.2.1 Utilización de un puerto espejo 61

3.2.2 Limitantes para la implantación del Sistema 62

3.2.2.1 Equipo (Hardware) 62

3.2.2.2 Disponibilidad de tiempo 62

3.2.2.3 Problemas Encontrados en la instalación de Snort 63

3.2.2.4 Políticas Escolares 63

3.3 Topología de equipo para Pruebas 63

3.3.1 Características mínimas requeridas en del Equipo IDS 64

3.4 Arranque y Pruebas del IDS Snort 64

3.4.1 Como interpretar los logs de Snort 71

3.5 Descripción de los registros de Snort 74

3.5.1 Registros en ambiente de Simulación 74

3.5.1.1 Simulación de ataque tipo ping 74

3.5.1.2 Simulación de ataque tipo escaneo de puertos 75

3.5.2 Registros obtenidos de ataques reales 77

3.5.2.1 Características del protocolo SMNP 161 78

3.5.2.2 Características del protocolo HIP 139 79

3.6 Propuesta de Implementación de un IDS en la ESIME Zacatenco 80

CONCLUSIONES 83

BIBLIOGRAFÍA 84

ANEXOS

APÉNDICE A Manual de Instalación I

APÉNDICE B Manual de reglas en Snort V

APÉNDICE C Reporte semanal obtenido de IDS Dragon Enterasys XIII

APÉNDICE D Revista electrónica en Normas ISO 9000-2000 XIV

APÉNDICE E Propuesta Económica XVIII

APÉNDICE F. Simplificación del sistema operativo Linux. Configuración del kernel, utilización de servicios mínimos para snort.

XXI

F.1 Secuencia de arranque del sistema Ubuntu XXI

F.1.1 Descripción general de la secuencia de arranque (boot-scripts)

XXI

F.1.2 Arranque del hardware XXII

F.1.3 Cargar el S0 XXII

F.1.4 Puesta en marcha del núcleo XXII

F.2 Quitando aplicaciones XXIII

F.3 Deshabilitar los servicios del sistema en el Inicio XXIV

F.4 Método Simple XXIV

F.5 Configuración de Servicios XXV

F.6 Método Completo XXVI

F.7 Restringir Servicios en el sistema operativo XXVIII

F.8 Runlevels XXVIII

F.9 Init e inittab XXXI

F.9.1 Scripts de arranque XXXI

F.9.2 Directorios de ejecución en orden XXXI

APÉNDICE G. Licencia GNU XXXIV

ÍNDICE DE FIGURAS N°

PAG

Figura I Topología general de la red de ESIME. 7

Figura 1.1. Diagrama de bloques de la arquitectura CIDF 24

Figura 1.2. Clasificación de los IDS 26

Figura 1.3. Localización dentro de un IDS entre una organización 31

Figura 1.4. Dragon-Consola de mando de seguridad 32

Figura 1.5. Dragon de detección de intrusos y sistemas de prevención 33

Figura 1.6. Dragon Network Access Control 34

Figura 1.7 Sensor Cisco 4250 34

Figura 1.8. Switches Cisco catalyst serie 6500 35

Figura 1.9. IPS-6100 StoneGate 36

Figura 1.10. IPS-2000 StoneGtae 36

Figura 1.11. IPS-2400 StoneGate 36

Figura 1.12. SGI-2000S StoneGate 37

Figura 1.13. SGI-200S StoneGate 37

Figura 1.14. SGI-20A StoneGate 37

Figura 2.1. Diagrama de operación Snort, versión oficial 39

Figura 2.2. Diagrama de operación Snort, versión modificada 39

Figura 2.3. Diagrama a bloques de visor o decodificador de paquetes 40

Figura 2.4. Diagrama a bloques del procesador 40

Figura 2.5. Diagrama a bloques del motor de detección 41

Figura 2.6. Diagrama a bloques del subsistema de alerta y log 42

Figura 2.7. Pantalla de inicialización de MySQL 47

Figura 2.8. Pantalla grafica de visualización de BASE instalado 48

Figura 2.9. Ejemplo de gráficos obtenidos de BASE 49

Figura 2.10. Pantalla grafica de ACID 50

Figura 2.11. Pantalla para crear ACID 51

Figura 2.12. Gráficos de Alertas registrados por Snort con el interfaz ACID 51

Figura 2.13. Pantalla para crear ACID 52

Figura 3.1. Ejemplo propuesto de un puerto espejo 60

Figura 3.2. Topología montada para realizar las pruebas con Snort. 62

Figura 3.3. Paquetes de datos mostrados en pantalla del IDS en modo Snnifer 63

Figura 3.4. Inicialización del IDS Snort en modo NIDS completo. 64

Figura 3.5. Finalizando IDS Snort en modo NIDS completo 65

Figura 3.6. Estadísticas de protocolos de los paquetes analizados en modo completo

66

Figura 3.7. Inicialización el IDS Snort en modo NIDS rápido 67

Figura 3.8. Activación de alertas en el IDS Snort en modo NIDS rápido 68

Figura 3.9. Interpretación de los registros o archivos tipo log 69

Figura 3.10. Interpretación de los registros de Snort mediante el comando –f

(Lectura) 70

Figura 3.11 Ambiente para simulación de ataque tipo ping 72

Figura 3.12. Trama indicadora de ataque tipo ping 72

Figura 3.13 Formato de petición y respuesta de eco. Ping echo/echo request 73

Figura 3.14. Ambiente para simulación de ataque tipo escaneo de puertos 73

Figura 3.15. Escaneo de puertos 74

Figura 3.16. Escaneo de puertos utilizando Nmap 74

Figura 3.17. Inicializando las reglas de Snort 75

Figura 3.18. Lectura de registro donde se muestran ataques reales 75

Figura 3.19. Registro de ataques realizados usando protocolo SNMP 76

Figura 3.20. Ataque realizado a puertos utilizando SNMP 77

Figura 3.21. Registro de ataque realizado usando protocolo HIP 77

Figura 3.22. Topología general de la red de ESIME Zacatenco 79

Figura 3.23. Diagrama de la propuesta de implantación del IDS en la red 79

Figura B.1. Ejemplo de la Regla VIII

Figura B.2. Ejemplo de formato de incluye VIII

Figura B.3. Ejemplo de una variable definida y usada IX

Figura B.4. Figura variable avanzada usada de ejemplo IX

Figura B.5. Configuración IX

Figura B.6. Ejemplo de un tipo de regla log para un archivo syslog XI

Figura B.7. Ejemplo de dirección IP negación de regla. XII

Figura B.8. IP Dirección lista XII

Figura B.9. Ejemplos de rangos de puertos XII

Figura F.1. Pantalla que muestra como quitar algunas aplicaciones en Ubuntu 7.10

XXIII

Figura F.2. Contenido del directorio /etc/rc2.d visto en la terminal de Linux. XXIV

Figura F.3. Deshabilitar servicios desde el escritorio en Ubuntu 7.10 XXIV

Figura F.4. Deshabilitación de Controladores Restringidos

Figura F.5. Configuración de algunos de los servicios del sistema de Ubuntu 7.10

XXV

Figura F.6. Configuración de servicios. Método Completo XXVI

Figura F.7. Administrador de Inicio para servicios. XXVII

Figura F.8. Pantalla de la Terminal que muestra los scripts del runlevel 2 XXXII

Figura F.9. Archivos en /etc/init.d XXXII

Figura F.10. Contenido en init.d XXXIII

FIGURAS GRÁFICAS N°

PAG Figura A. Amenazas comunes 8 Figura B. Tipos de intrusiones o amenazas 9 ÍNDICE DE TABLAS N°

PAG Tabla 2.4. Generalidades del servidor Apache 53 Tabla 3.1. Características del equipo de monitoreo 62 Tabla 3.2. Características de propuesta para equipo de monitoreo 80 Tabla E.1. Equipo de monitoreo 1 XVIII

Tabla E.2. Equipo de monitoreo 2 XVIII

Tabla E.3. Equipo de monitoreo 3 XVIII

Tabla E.4. Costo total del proyecto XIX

PROPUESTA DE UN SISTEMA DE DETECCIÓN DE INTRUSOS PARA

MONITOREAR LA RED INSTITUCIONAL DE ESIME ZACATENCO.

1

GLOSARIO DE TERMINOS TÉCNICOS

ACD Automatic Call Distribution. (Distribución automática de llamadas). ACID Analysis Console for Intrusion Databases (Consola de análisis para intrusiones

en las bases de datos) ACL (Listas de Control de Acceso) ANSI American National Standards Institute (Instituto Nacional Americano de

Estándares). APACHE Patchy Server (Servidor emparchado) API Application Programming Interface (Programando interface de aplicación). ARP Address Resolution Protocol (Protocolo de resolución de direcciones) ATM Asynchronous Transfer Mode (Modo de transferencia asincrónico) Autopost Autocontexto de los foros o blogs en la internet. AusCERT National Computer Emergency Response Team for Australia and a Leading

CERT in the Asia/Pacific region. (Ordenador Nacional de Equipo de respuesta a emergencias de Australia.)

BASE Basic Analysis and Security Engine (Motor de seguridad y análisis basic) C Lenguaje de programación C++ Lenguaje de programación C# Lenguaje de programación Cherokee Servidor libre para Internet CIDF Common Intrusion Detection Framework (Marco de Detección de Intrusos

Común) CISL Common Intrusion Specification Language (Lenguaje de Especificación de

Intrusiones Común) CGI Common Gateway Interface (Interfaz de entrada común) CVE Common Vulnerabilities and Exposures (Conocimiento de Vulnerabilidades de

Seguridad). Delphi Lenguaje de programación DTE o ETD Data Terminal Equipment (Equipo terminal de datos) DIDS Distribution Intrusion Detection System (Detección de intrusos en el sistema

distribuidos) DNS Domain Name Server (Servicio del nombre de dominio) Negación de servicio dsniff Colección de herramientas para la red de auditoría y pruebas de penetración. Eiffel Lenguaje de programación E-MAIL Correo Electrónico. ENRUTAR Proceso FreeBASIC Lenguaje de programación ftp Protocolo de Comunicación. Gambas Lenguaje de programación GNU Proyecto iniciado para volver al espíritu de cooperación que prevaleció en los

tiempos iniciales de la comunidad de usuarios de computadoras Hacker Experto en varias o alguna rama técnica relacionada con la informática:

programación, redes de computadoras, sistemas operativos, hardware de red/voz y otros.

HTTP Hypertext Transfer Protocol (Protocolo de transferencia de hipertextos) HTML Lenguaje de Programación para Internet. Hubs Son concentradores o centrales de cableado Kernel El núcleo, parte fundamental de un sistema operativo. Software responsable de

facilitar a los distintos programas acceso seguro. HIDS Sistema de detección de intrusos en un Host. ICMP Internet Control Message Protocol (Protocolo de mensajes de Internet) IDS Intrusion Detection System (Detección de intrusos en el sistema) IDSM-2 Intrusion Detection System (Módulo del Sistema de Detección de Intrusiones-2)

2

IDWG Intrusion Detección Working Group (Grupo de Trabajo de Detección de Intrusos) IETF Engineering Task Force IIS Internet Information Services (Servicios de información para Internet) IP Internet Protocol (Protocolo de Internet) lpd Seminario de Redes de Computadores. ISAM Indexed Sequential Access Method (Método de Acceso Secuencial Indexado). Java Lenguaje de programación Lisp Lenguaje de programación MAC Control de Acceso al Medio. MySQL Es un sistema de gestión de base de datos relacional, multihilo y multiusuario se

tomo del nombre de una ciudad de Arusha, Tanzania ODBC Interfaz para el SGBD del MySQL ORACLE Lenguaje de programación. Pascal Lenguaje de programación Perl Lenguaje de programación Ping Protocolo de Comunicación. PHP Lenguaje de programación POSTGRES Es un motor de base de datos relacional para uso de tablas PPP Point to Point Protocol (Protocolo Punto a Punto) Python Lenguaje de programación Root Nombre convencional de la cuenta de usuario que posee todos los derechos en

todos los modos. Ruby Lenguaje de programación Rwx Permiso de Seguridad. Script Guión o conjunto de instrucciones. Permiten la automatización de tareas

creando pequeñas utilidades. Es muy utilizado para la administración de sistemas UNIX.

SERVER Sistema de SGBDR basado en el lenguaje Transac-SQL, específicamente en Sybase IQ para disposición de muchos usuarios y grandes cantidades de datos simultáneamente.

SGBD System Gestion Base Data(Sistema de gestión de bases de datos) SGBDR System Gestion Base Data Relational (Sistema de gestión de bases de datos

relacional) SLIP Serial Line Internet Protocol (Protocolo de líneas seriales de Internet) Smalltalk Lenguaje de programación Sniffing Un sniffer es un programa de para monitorear y analizar el trafico en una red de

computadoras, detectando los cuellos de botellas y problemas que existan en ella.

Snort Snort es un sniffer de paquetes y un detector de intrusos basado en red (se monitoriza todo un dominio de colisión).

SO Sistema operativo SPAN Switched Port Analyzer (Contacto de analizador de puerto) SQL Lenguaje de Programación de Base de Datos SSH Secure Shell. Ofrece una consola en un ordenador remoto con los privilegios

que tenga la cuenta con la que conectes. Switches Son verdaderas Centrales de Comunicaciones de una Red estándar Tcl Lenguaje de programación TCP Transfer Control Protocol (Protocolo de transferencia de control) TCP-RT Transfer Control Protocol Reset (Protocolo de transferencia de control reset)

3

TearDrop Un "ataque por fragmentación" al saturar el tráfico de la red (negación de

servicio) aprovechando el principio de fragmentación del protocolo IP (fragmentar paquetes grandes en varios paquetes IP más pequeños)

TFTP Trivial file transfer Protocol (Protocolo de transferencia de archivos trivial). Telnet TELecommunication NETwork. Es el nombre de un protocolo de red (y del

programa informático que implementa el cliente) UDP User Data Protocol (Protocolo para uso de datos) VLAN Acrónimo de Virtual LAN‘(red de área local virtual). Es un método de crear redes

lógicamente independientes dentro de una misma red física.

4

INTRODUCCIÓN En el presente trabajo de investigación, se hace importante, el tema de la seguridad en redes de comunicaciones, ya que la sociedad actual está demasiado involucrada con el uso de las mismas; además debido a que el tema en seguridad en redes se ha extendido muchísimo se hace más necesario centrarse y especializarse en un área específica, ya que tratar de querer abarcar todo el tema, sería prácticamente imposible. La importancia que cobra la seguridad en una organización ya sea privada, de una dependencia gubernamental, o de otra índole, es imprescindible debido a que un fallo en las redes de la organización podría llevarla a la pérdida de horas de trabajo, de información muy valiosa, o que la lleven a la quiebra. Este trabajo se refiere a un estudio que se hace en la ESIME Zacatenco sobre la problemática de monitoreo de tráfico malévolo y propuesta de detección de este a través de un software de detección de intrusos basado en Linux. Debido al tema que se aborda en la presente investigación, y a los tecnicismos utilizados, la primera parte de este trabajo contiene el glosario de términos técnicos. Después sigue la justificación que lo respalda, en este apartado se habla acerca de la problemática en general existente en el área de seguridad en redes informáticas y la realidad que vive, el IPN, mostrando datos estadísticos proporcionados por parte del área de seguridad del Edificio Inteligente del IPN, para el presente caso de estudio, la ESIME Zacatenco, en la que se pone particular atención debido a que como usuarios de la Red en la escuela se tienen problemas como la asignación de direcciones IP y con los virus, por mencionar algunos aspectos; de eso habla en general la justificación y el porque la elección del software con el que trabajamos, en código abierto. Enseguida se encuentran los objetivos, el general y después los particulares, con los que se plantean las metas del proyecto de investigación; al término de estos se expondrá el marco de trabajo, el cuál da idea a grosso modo de la forma de trabajo para la realización del mismo. Luego se exponen los antecedentes generales que le dan una base histórica al trabajo dentro de un contexto que lo ubica, para dar una idea general que vaya adentrando al lector en el interés particular por el desarrollo del tema y que muestra el porque de la importancia de este proyecto. En el capítulo I se habla acerca de los temas de seguridad en redes, así como de los problemas que enfrentan en cuanto a los ataques que pueden sufrir estas redes, además de otros problemas de seguridad, también se abordan temas de los mecanismos para proteger a las redes. En específico se hablan de los Sistemas de Detección de Intrusos, y se hace una descripción de ellos su clasificación así como otras características que los conforman. Posteriormente en el capítulo II se menciona el IDS con el que se decidió trabajar, que es un sistema en código abierto, se hace una breve referencia histórica del mismo, se describe la arquitectura del IDS Snort, así como el funcionamiento de cada una sus partes, después se habla de Linux, Sistema Operativo en el cuál se montó el IDS Snort, también se realiza una descripción del programa de base de datos utilizado para Snort,

5

MySQL, así como de la interfaz gráfica BASE, y se aborda el tema de servidores Web para mencionar el servidor Apache. Se explican brevemente los comandos para los modos de alerta en Snort, y por último se tocan los temas de las técnicas de detección de los IDS. Para poder llevar a cabo este trabajo se realizó una investigación acerca de la topología de la red del ESIME Zacatenco, de los servicios que ofrece y sucesos que han hecho que se deterioren los servicios que ella ofrece. Todo esto se presenta en los apartados del capítulo III, donde además se habla de la implantación del sistema en un punto de la red de ESIME Zacatenco, así como de las pruebas realizadas para el análisis del rendimiento del IDS Snort, de este modo se hace un análisis de los registros obtenidos en los archivos del sistema, primero de la simulación de ataques, y luego los registros de ataques reales; así también se describen las limitantes para el desarrollo de este proyecto, las dificultades que se tuvieron para la implantación del software, para tener acceso a equipo en la escuela, así como de la instalación del IDS Snort. Después del desarrollo de los capítulos, se presentan los apéndices que contienen, los manuales de instalación de Snort, así como el de la escritura de las reglas. A continuación se tienen el estudio económico del proyecto, y por último se dan las conclusiones del trabajo, así como la bibliografía.

6

JUSTIFICACIÓN Generalidades. En la actualidad todos estamos involucrados de alguna forma con medios informáticos, es por ello que el presente proyecto está enfocado al estudio de la seguridad en las redes informáticas. Ya que el auge de las tecnologías computacionales ha incrementado así como su popularidad nace la necesidad imperiosa de mantener los datos que se utilicen, seguros, además de tener una red libre de amenazas ante el tráfico de estos datos, mantener una red estable, segura y confiable. Debido a esto, surge la inquietud y preocupación por desarrollar, mejorar e implantar, formas que hagan a estas redes seguras de agentes externos, que puedan dañar nuestra información. Existen diversos métodos para mantener seguras las redes informáticas. Por ese motivo este trabajo se concreta a los Sistemas de Detección de Intrusos. Área de Estudio. El IPN, es el área de estudio del presente trabajo, debido a la importancia que implica para loe estudiantes, docentes y administrativos de la misma institución, el estar atentos a las distintas amenazas o ataques que puedan dañar la información que manejan todos los que hacen uso de esta Red Institucional. Es importante mencionar que la red de ESIME Zacatenco presenta algunos problemas en varias áreas, tales como congestionamiento de tráfico, aunque la realidad es que se desconocen las causas. También resalta el hecho, que hay usuarios que entran a la red del IPN, con la intención de modificar, dañar o buscar información de la misma. Otro punto vital a tratar son las políticas existentes las cuáles debieran ser cumplidas, pero no hay mecanismos para detectar su incumplimiento, como son:

• No se permite el uso de software de ‘hackeo’

• No se permite entrar a páginas de contenido dudoso que pueda contener virus. Además se hace necesario el uso de herramientas para determinar si los cortafuegos de la ESIME Zacatenco están apropiadamente configurados, cabe mencionar que no existen mecanismos que protejan o manden alertas en caso de que un servidor sea atacado. El presente proyecto es de vital interés debido a que actualmente en ESIME, se han tenido problemas en la red, en esta escuela, ya que se cuenta con un servidor en Control Escolar, en la unidad de informática se tienen dos servidores FTP, y se cuenta con otro servidor en Horarios como se puede observar en la figura I. De este modo se puede ver la

Topología General de la Red en ESIME Zacatenco.

7

Figura I. Topología general de la red de ESIME Se tienen datos que respaldan el objeto de estudio de este proyecto que en particular será centrado al nodo de ESIME Zacatenco, para ello se han obtenido datos estadísticos del IDS que se utiliza en la Dirección de Cómputo (Edificio Inteligente) del IPN. Estos nos muestran los distintos tipos de intrusiones que dañan la Red Institucional. En la Dirección de Cómputo, no se manejan IDS como tal, se tiene dos tipos de IPS, el primero es perimetral y es de marca StoneGate, el segundo se trata de un IPS interno de la empresa Enterasys llamado Dragon y se maneja por parte del departamento de Reingeniería y Conectividad, es un software con permisos y licencias, el cual tiene requerimientos especiales para sus equipos, con alta capacidad para almacenamiento, tratamiento y flujo de datos. A continuación, se muestran, los datos brindados por el IPS interno Dragon, los cuáles son gráficas que arrojan los resultados de las amenazas más comunes.

Fibra óptica

Servidores Unidad Informática, 2 FTP, 1 MODUL

Site Edif1

Site Edif2

Site Edif 3

Site Edif 4

Site Edif 5 PB

Comunicaciones

Electrotécnia

SEPI

Site Edif 5 3er piso

Labs. pesados ICA

8

Fuente: IDS Dragon Enterasys. Edificio Inteligente IPN. 2008.

Figura A. Amenazas Comunes

La gráfica anterior nos muestra que la amenaza más común, es la suplantación de la dirección de IP, en menor grado la negación de servicios, y por último la violación por acceso remoto. También, se puede mencionar que el Director General de la Dirección de Cómputo hizo referencia a que el nodo más problemático del IPN últimamente ha sido el de la ESIME Zacatenco, reafirmando la necesidad que se tiene de manejar un método sistemático que ayude a prevenir los posibles ataques, intrusiones de usuarios que traten de dañar el trafico de datos, la seguridad y estabilidad de la red en ESIME Zacatenco. Las escuelas de nivel superior carecen en general de mecanismos de seguridad que hagan frente al aumento del número de ataques que se producen en Internet. Es inviable la instalación de cortafuegos que limiten el acceso por defecto dejando abiertos solo los servicios necesarios, por lo que su configuración sería la de ’permitir por defecto’ y filtrar solo los servicios problemáticos por razones administrativas (correo y web, por ejemplo). Esta tarea se puede realizar en el propio enrutador de entrada y no necesita de hardware específico como el cortafuegos. Una solución que se le puede dar al problema de la falta de seguridad y que encaja con lo anterior es la instalación de sistemas pasivos que alerten a los administradores en el momento en el que se produzca un ataque. El administrador será conocedor del ataque y

Tráfico de amenaza por categoría

529,419,059,542.00

22,198,691,037.00586,490,309.00

DoS

Violación por acceso remoto

Uso sospechoso de Protocolo IP

9

dependiendo de la gravedad de éste podrá decidir si avisa al responsable de la red el origen del ataque, o no.

Fuente: IDS Dragon Enterasys. Edificio Inteligente IPN. 2008.

Figura B. Tipos de intrusiones o amenazas En el gráfico anterior se tienen, los eventos de todas las redes, de las cuentas de los eventos por código. Aquí se observa que la llamada Nueva Estafa es el código más común, de los eventos que se presentan. Debido a la condición de estudiantes y a las mismas posibilidades económicas, se cuenta con equipos sencillos a los cuales se adapta mejor otro tipo de software para IDS. Se ha elegido el IDS Snort, debido a que es un software en código libre además tiene varias características por las que se optó trabajar con el, ya que los requerimientos de hardware son mas simples, así como el código que se maneja, ya que este es menos pesado, es decir, son líneas de código mas sencillas y como esta basado en Linux se tiene un sistema operativo que es confiable y estable. Aparte de que puede ser instalado fácilmente, gratuito, en los equipos de computo portátiles para monitoreo y aplicación del IDS Snort, sin las dificultades que conllevan a otros tipos de IDS, para el desarrollo de las pruebas y reportes de este trabajo. Herramientas que complementan un Sistema de Seguridad de Código Abierto Componentes y soluciones globales. Estos bien probados y aceptados componentes son incorporados en sus soluciones propietarias completas por los fabricantes de sistemas de seguridad. Es el caso de los analizadores de vulnerabilidades Nmap y Nessus, el sistema de detección de intrusiones (IDS) Snort y un buen número de cortafuegos, algunas veces cuidadosamente escondidos, otras veces abiertamente promocionados tras la marca comercial. Además,

Número total de eventos por categoría Todas las redes

20740267

5000000

482

9795323388

800

400000089237

1150852

892371150852

Nueva Estafa

Proeza

Sospechoso

Mal Intencionado

DoS

Otros

Política

Proeza Potencial

Acceso

Flujo

Serie de Tiempo

10

algunos productos de seguridad de código abierto han sido convertidos en comerciales por los propios equipos de desarrollo. Tal es el caso de los citados Snort, de Sourcefire, y Nessus, de Tenable. En cualquier caso, hay cuatro argumentos básicos a favor de las herramientas de seguridad de código abierto: agilidad ante el constante cambio de los retos y amenazas, soporte de la comunidad del software libre, adaptación a los requerimientos de cada empresa y costes más bajos. Y todas estas ventajas aparecen en todas las áreas de seguridad. Detección/prevención de intrusiones Un sistema de detección de intrusiones (IDS) no sólo detecta ataques; también resulta útil para efectuar análisis forenses, detectar malos usos y errores de configuración, e incluso para crear perfiles del rendimiento de la red. Para satisfacer tal variedad de necesidades, IDS recoge y almacena los eventos detectados por lo sensores desplegados por la red. Además, busca, recoge y analiza los eventos en el momento que se producen, los archiva y permite su recuperación posterior. También genera alertas instantáneas ante algunos eventos determinados, gestiona todos estos componentes y reporta tendencias a largo plazo. En despliegues avanzados, los datos IDS se apoyan en dispositivos de correlación para buscar tendencias entre los eventos. El equipo de desarrollo de Snort (formado mayoritariamente por trabajadores de Sourcefire, que vende sistemas IDS/IPS basados en este dispositivo de código abierto) se ha ocupado de la primera parte de las prestaciones citadas. Como sucede con SpamAssassin, Snort por sí solo resulta casi completamente inútil, pero se puede integrar fácilmente con sistemas operativos como Linux o BSD (Berkeley Software Distribution o Berkeley Unix) para crear un sensor IDS que detecte tráfico y genere eventos. Pero, aún así, sin una infraestructura que gestione tanto el sistema como los eventos identificados, no merece mucho la pena su uso en las empresas si no se complementa con otras herramientas. No obstante, los responsables de centros de datos que quieran construir un IDS de código abierto al 100% totalmente controlado por ellos, pueden empezar por utilizar sensores basados en Snort sobre Linux y complementarlos con varios componentes de software libre capaces de gestionar dichos sensores. Disponer de tal gestión puede exigir crear scripts o aplicaciones internamente, aunque hay herramientas específicas, como Oinkmaster e IDS Policy Manager, que mantienen las reglas de Snort actualizadas apropiadamente. Para registro de eventos, el enfoque común es usar Barnyard, un añadido a Snort, junto con la base de datos MySQL. Posteriormente, herramientas como Analysis Console for Intrusion Databases o el más nuevo Basic Analysis and Security Engine –en combinación con un servidor Web y varias herramientas gráficas y de scripting–, permiten identificar tendencias y realizar análisis forenses. Pero como la parte más difícil de crear un IDS corporativo es convertir los datos de los sensores en información útil, una mejor solución puede ser utilizar sensores IDS de código abierto y una “superconsola” IDS comercial para tratar eventos y alertas, archivarlos y analizarlos. Este enfoque tiene la virtud de seguir reduciendo el riesgo de estar atado a una red de sensores IDS de una firma comercial determinada. Un problema significativo considerando que el 40% de los fabricantes de IDS/IPS probados por IDG en

11

Estados Unidos en 2003 ya no existen (el 50% de los correspondientes a las pruebas de 2002). La mayor parte de los productos de gestión de información de seguridad de compañías como ArcSight, NetIQ (ahora unidad de negocio de Attachmate), EMC (con la tecnología de la Network Intelligence, adquirida en 2006) y Tenable Networks Security, por ejemplo, trabajan perfectamente con sensores Snort. Y por una licencia adicional, 3D Defense Center, de Sourcefire, acepta eventos de Snort tan fácilmente como de otras ofertas empaquetadas de la firma. Análisis de vulnerabilidades Saber qué está en la red y qué servicios están en uso es una parte fundamental de la seguridad. Y una herramienta de análisis de vulnerabilidades es un arma valiosa para mantenerse al corriente automáticamente de los servicios y servidores presentes. Nessus, de Tenable, una popular herramienta para descubrir servicios y gestionar vulnerabilidades, está abriendo los límites de lo que significa el código abierto en el centro de datos. Originalmente, fue una herramienta totalmente libre, pero el año pasado, con el lanzamiento de su versión 3, sus desarrolladores lo convirtieron parcialmente en solución comercial. Este cambio de licencia fue impopular en la siempre imprevisible comunidad de código abierto, pero el número de usuarios entusiastas no parece haber disminuido. Nessus Versión 2 se sigue manteniendo como proyecto de código abierto. Con una arquitectura cliente/servidor y diversas interfaces gráficas disponibles, Nessus necesita menos software adicional que SpamAssassin o Snort para convertirse en un paquete totalmente funcional. Otras firmas de descubrimiento de red y análisis ofrecen más herramientas para gestionar los resultados del escaneado, proporcionando enlaces con sistemas de gestión de parches y tratando el ciclo de vida de las vulnerabilidades, pero el equipo de Nessus se ha focalizado más en hacer un dispositivo altamente configurable. Para conseguir una mayor paridad con los productos comerciales, los usuarios de Nessus pueden comprar Security Center, también de Tenable. Se trata de una herramienta de gestión centralizada para Nessus que escanea datos de utilidad para la generación de informes y el análisis y gestión de vulnerabilidades. Asimismo, correlaciona eventos de dispositivos IDS con las vulnerabilidades detectadas a fin de dar a los administradores de seguridad una información más útil sobre los aspectos más significativos. Además, la mayor parte de los productos comerciales de gestión de información de seguridad también son capaces de compendiar y correlacionar datos escaneados por Nessus. Con todo, como Nessus sigue un enfoque activo –es decir, opera probando los sistemas para descubrir servicios, sistemas operativos y vulnerabilidades–, no resultará indicado para muchas organizaciones. La mala reputación que se ha ganado este tipo de escáneres, al desactivar o ralentizar los sistemas, además de otras cuestiones políticas, ha ampliado el horizonte del enfoque pasivo. Y aunque existen sistemas de escaneado pasivo de la comunidad de código libre, los administradores de redes con mayores pretensiones deberían analizar las soluciones comerciales de firmas como Sourcefire (RealTime Network Awareness) y Tenable (Passive Vulnerability Scanner).

12

OBJETIVO GENERAL

• PROPONER LA IMPLANTACIÓN DEL IDS SNORT EN PLATAFORMA LINUX PARA MONITOREO DE LA RED DE DATOS DE LA ESCUELA ESIME ZACATENCO DEL INSTITUTO POLITECNICO NACIONAL.

13

OBJETIVOS ESPECÍFICOS

• Proponer un Sistema de Detección de Intrusos como medio para descubrir anomalías de tráfico en la red de ESIME Zacatenco.

• Conocer el funcionamiento y requerimientos de un IDS en plataforma Linux.

• Registrar la actividad presente en un punto de la red de ESIME Zacatenco

mediante el IDS Snort. • Analizar los registros detectados por el sistema IDS Sort para establecer y corregir

problemas de seguridad en la red de ESIME Zacatenco.

14

MARCO DE TRABAJO OBJETIVOS ACTIVIDADES METODOLOGÌAS Y/O

TÉCNICAS HERRAMIENTAS

EMPLEADAS METAS

Proponer un Sistema de Detección de Intrusos como medio para descubrir anomalías de tráfico en la Red de ESIME Zacatenco.

Investigar en fuentes primarias: Entrevistas a Profesores de ESIME Zacatenco, Ingenieros del área de seguridad informática de la Central Inteligente del IPN y a Investigadores y maestros de la Unidad de Informática de ESIME Zacatenco. Investigar en fuentes secundarias: Consulta de Foros, Manuales, Tesinas y Proyectos en Internet. Consulta de Libros, Manuales, Revistas, CD’s sobre seguridad informática.

Libros, revistas, manuales (sobre redes informáticas y acerca de seguridad informática). Tutoriales, foros, congresos, manuales, descarga de software libre (online). Navegadores de Internet (Firefox, Explorer7). Procesador de textos (Word, OpenOffice).

Obtener una propuesta del sistema de detección de intrusiones para la red de ESIME Zacatenco.

Conocer el funcionamiento y requerimientos de un IDS (Sistema de Detección de Intrusiones) en plataforma Linux.

Inducción y prácticas en SO Linux Estudio de manuales de Snort Conocimiento de reglas en Snort Instalación de SO Linux Instalación de IDS Snort Conexión a servidor Apache Instalación de MySQL

Distribución de S.O. Linux Ubuntu Gusty Gibbon7.10 Snort 2.8.0.2 Servidor Apache MySQL BASE (Interfaz WEB)

Establecer bases teóricas fundamentadas para la implantación del IDS Snort

Registrar la actividad presente en un punto de la red de ESIME Zacatenco

Simulación de ataques: Envío de pings (utilidad) Escaneo de Puertos. Mantener el sistema activo para análisis de tráfico

Distribución de S.O. Linux Ubuntu Gusty Gibbon7.10 Snort 2.8.0.2 Símbolo del Sistema NMap (escaneador de puertos) Wireshark (analizador de puertos)

Obtener resultados del rendimiento de la operación de Snort.

Analizar los registros detectados por el sistema IDS Snort para establecer y corregir problemas de seguridad en la Red de ESIME Zacatenco

Lectura y evaluación de reportes obtenidos de los registros en los archivos de Snort.

Distribución de S.O. Linux Ubuntu Gusty Gibbon7.10 OpenOffice (Toda su plataforma de trabajo) Word Servidor Apache FireFox

Realizar la propuesta de implantación del IDS Snort, para diversos puntos dentro de la Red de ESIME Zacatenco, en base a los registros analizados.

12

15

ANTECEDENTES A medida que la tecnología de la información se desarrolla rápidamente también aumentan crímenes contra la seguridad de los datos. Existen ataques, virus, amenazas, y fraude informático por mencionar solo algunas anomalías con las que profesionales y expertos encargados de la seguridad de la información en diversas organizaciones, tales como empresas e instituciones privadas y públicas se han enfrentado con mayor auge en últimas décadas. Los criminales de la información han mostrado su interés por las actividades de organizaciones administrativas o comerciales con intentos de robar o revelar información confidencial, que dañan la imagen profesional, interrumpen la actividad comercial y pueden alterar los contenidos de datos de una organización. Estos actos pueden causar daños considerables al capital, tangible o intangible. Violaciones e incidentes en seguridad se han convertido en un gran problema principalmente en redes, Internet, sistemas de cómputo, servidores, con lo que la información en muchas organizaciones ha quedado expuesta a una infinidad de personas internas o ajenas, que en la mayoría de los casos hacen uso inadecuado de esa información. Pruebas realizadas en 2002 sobre el delito informático en los Estados Unidos por parte de 503 especialistas y expertos acerca de seguridad en datos indicaron que las amenazas y otras vulnerabilidades de la seguridad de la información continúan sin disminuir y el cargo financiero es considerable. De acuerdo a los resultados de las pruebas un 90% de los equipos de seguridad analizados detectaron en un plazo de 12 meses esas vulnerabilidades que son las causa del 80% de las perdidas financieras, y el 46% (223 equipos de respuesta) reportaron estos resultados de pérdidas financieras un total de USD 455 848 000. Un ejemplo claro pueden ser las Instituciones Públicas, un caso particular, hablando de Instituciones Educativas, lo es el IPN; la más importante de sus facultades, que es la ESIME, campus Zacatenco; se ve afectada por una buena cantidad de ataques, y es blanco perfecto para aquellos usuarios maliciosos que tratan de usar la información circulante dentro de la red misma, con fines de infiltrarse y hacer cambios en ella, así como dañar funciones, borrar información valiosa, modificar direcciones IP, etc. Tomando en cuenta que por ser una Institución que cuenta con una red gratuita abierta, puede ser afectada por cualquier persona, siendo inclusive los atacantes los mismos alumnos. Es por ello que cada vez se hace más importante el conocimiento de los precedentes sentados y la información recopilada con anterioridad acerca de estos ataques que pueden afectar o dañar más seriamente a la red, pudiendo ser un potencial riesgo para la estabilidad de la Red de ESIME Zacatenco.

CAPÍTULO I

SISTEMAS DE DETECCIÓN DE INTRUSOS

16

1.1 Seguridad de Redes en Comunicaciones Como tal la seguridad en sistemas informáticos se ha convertido en una necesidad vital que ya no puede ser pasada por alto, el uso de redes de comunicaciones utilizadas por empresas así como por usuarios comunes o redes públicas, ya sea institucional o de gobierno, hace imprescindible el desarrollo y aplicación de diversas técnicas para el control de la seguridad. Un sistema informático es aquel que se dedica al tratamiento automático de la información. Así la seguridad en un sistema informático tiene como objetivo primordial el asegurar el tráfico de datos a través de la red, haciendo que estén libres de cualquier modificación, daño o cualquier tipo de peligro, por parte de usuarios no autorizados que puedan hacer esto, haciendo con este tipo de protecciones que estos sistemas sean fiables.

Para definir a un sistema de seguridad como fiable, con respecto a la información que almacena, este tiene que ver con tres aspectos muy importantes: confidencialidad, integridad y disponibilidad. La confidencialidad hace referencia al acceso a datos o a la información del sistema por usuarios autorizados a él, asegurando que no harán mal uso de los mismos, así como mantenerlo alejado de usuarios no autorizados; la integridad habla de la modificación de la información, para que no sea borrada o dañada por usuarios no autorizados; así podrá ser modificada solo por usuarios autorizados, de manera controlada; y la disponibilidad señala que los datos permanecerán accesibles a los usuarios autorizados cuando estos lo requieran.

Debido a que las redes de comunicaciones utilizan diversos protocolos para establecer la comunicación de un equipo a otro; es decir, se establece la comunicación entre equipo y entre usuarios para el intercambio de información, esto propicia que se generen huecos de seguridad haciéndolas propensas a agentes que puedan dañar estas redes. Las formas para dañar una red son por ejemplo, a través de sus puertos, haciendo exploraciones a estos, con el propósito de encontrar vulnerabilidades. También por medio de ataques remotos dentro de los cuales podemos incluir, los llamados de negación de servicios para los cuáles el principal objetivo es inhabilitar una red, enviándole tantas peticiones hasta que el sistema sea incapaz de responder a ellas. Otros son los programas maliciosos, tales como virus, gusanos o caballos de Troya, estos tienen la finalidad de introducirse y propagarse en la red con la finalidad de robar, espiar y dañar la información. 1.1.1 Tipos de Ataques Como se mencionó en el apartado anterior, debido a que en los sistemas de información de redes de datos son utilizados los protocolos de comunicación, establecidos para la comunicación entre un cliente y el servidor así como el intercambio de información; tenemos que cuando se establece esta acción intervienen en ocasiones otros actores conocidos como intrusos; ellos tratan de dañar al sistema, espiando, robando o modificando la información aprovechando alguna vulnerabilidad o hueco de seguridad del sistema. Una vulnerabilidad es un error generalmente de programación o de configuración del servicio que pueden comprometer la seguridad del sistema; así es por ello que se debe poner especial atención en las vulnerabilidades que pueda tener un sistema, por parte de los administradores del mismo y sus desarrolladores, para evitar en un futuro un desafortunado episodio de ataques potenciales.

17

De esta forma podemos hacer una clasificación de acuerdo al daño causado al sistema atacado:

Intrusos curiosos. Son personas probablemente sin mucho conocimiento del ٭

sistema, así como de informática, que no están autorizados al acceso de el sistema al que desean acceder sin hacer mayor daño al mismo, ya que solo lo espían.

Crackers. Son usuarios por lo general con cierto conocimiento que utilizan un ٭sistema de forma ilegítima, para ejecutar un programa malicioso para beneficio personal o robar cierta información. Las acciones maliciosas que ellos realizan son con la finalidad de ganar popularidad, anunciando sus habilidades como reto personal, así como una especie de estatus con respecto a otros como ellos.

Intrusos Remunerados. Son usuarios maliciosos con gran experiencia en ٭problemas de seguridad de redes de datos y conocimiento basto del sistema los cuales son requeridos por terceras personas con fines delictivos para dañar al sistema, por un pago como el salario por un trabajo.

Así un intruso conocedor primero deberá buscar las vulnerabilidades del sistema, esto para poder realizar el ataque y prepararlo, aprovechando de este modo esas vulnerabilidades para los fines que le sean útiles, esto lo realiza por medio de la exploración de puertos, que les proporciona a los atacantes la información de los puertos abiertos, así como las aplicaciones ejecutadas en ellos y que pueden definir los puntos a atacar. Acto seguido, lanzará el ataque y éste intentará entrar al sistema y si lo logra intentará dañar la información, modificarla o borrarla del mismo, mediante programas maliciosos. Por último el atacante borrará el rastro de su ingreso y esto lo hará ingresando a las bitácoras del sistema, para eliminar los registros que delaten su ingreso.

Debido a esto observemos que cada vez son más suspicaces a ataques que en años anteriores, debido al acceso a Internet por medio de equipos móviles y a través de banda ancha. Así que por este aumento de nivel de acceso se introducen ataques maliciosos los cuáles son conocidos como ataques remotos.

1.1.1.1 Exploración de Puertos Para los puertos en una computadora existen tres estados; abierto, cerrado o bloqueado. De este modo el estado más vulnerable a un ataque es cuando este se encuentre abierto, ya que significa que una aplicación servidor está escuchando por ese puerto las peticiones de los clientes que se conecten y de este modo el puerto puede brindar información acerca de las vulnerabilidades de seguridad del sistema. Al fin y al cabo los puertos abiertos son puntos de acceso a aplicaciones que corren en una computadora y estas aplicaciones pueden tener vulnerabilidades que pueden ser aprovechadas por otros usuarios. Existen varios puertos famosos y conocidos por las vulnerabilidades que presentan las aplicaciones que en ellos se ejecutan, dentro de éstos se encuentran puertos de inicio de sesión como el puerto 22 (ssh1), el puerto 23 (telnet2) y el puerto 21 (ftp3). También se

1 Protocolo usado para el puerto 22 para administración remota, a través de el viajan los datos encriptados.

2 Protocolo al que corresponde el puerto 23, con el cuál se intercambian datos no codificados.

3 Protocolo al que corresponden los puertos 20 y 21, para transferencia de archivos.

18

encuentran puertos de servidores de nombres como el puerto 53 (DNS4) y otros puertos como el puerto 69 (TFTP5) y el puerto 515 (lpd6) entre otros. Por ejemplo, la aplicación TFTP (Trivial File Transfer Protocol —Protocolo de transferencia de archivos trivial—) es un protocolo de transferencia muy simple y a menudo se utiliza para transferir pequeños archivos entre ordenadores en una red. Esta aplicación es vulnerable ya que no utiliza mecanismos de encriptación o autenticación por lo que representa un hueco de seguridad que los usuarios maliciosos estarán ansiosos por explotar. La aplicación lpd es la utilidad UNIX de impresión y permite entregar trabajos de impresión, ejecutarlos a través de filtros, gestionar las colas de impresión, y puede aceptar trabajos locales de impresión, o sobre la red, y acceder a varias partes del sistema, lo cual lo convierte en un potencial agujero de seguridad. De este modo un usuario debe ser consciente de bloquear los puertos que no sean usados ya que incluso, aunque los puertos estén bloqueados, un usuario malicioso puede acceder a la red por otros medios y atacar estos puertos si no están debidamente asegurados. 1.1.1.2 Suplantación (Spoofing) Se conoce así a las técnicas de suplantación de identidad generalmente con fines maliciosos o de investigación. Se conocen distintos tipos de suplantación dependiendo la técnica a la que nos refiramos; como la suplantación IP, suplantación ARP, suplantación DNS, suplantación Web o suplantación de correo electrónico; se puede englobar dentro de suplantación cualquier tecnología de red susceptible de sufrir suplantaciones de identidad.

Suplantación IP. Esta técnica consiste en la suplantación de las direcciones IP ٭origen de un paquete TCP/IP por otra dirección IP a la cual se desea suplantar. Los enrutadores actuales no admiten el envío de paquetes con IP origen no perteneciente a una de las redes que administra (los paquetes suplantados no sobrepasarán el enrutador. En la suplantación entran en juego tres máquinas: un atacante, un atacado, y un sistema suplantado que tiene cierta relación con el atacado; para que el pirata pueda conseguir su objetivo necesita por un lado establecer una comunicación falseada con su objetivo, y por otro evitar que el equipo suplantado interfiera en el ataque.

Suplantación ARP. Consiste en la suplantación por medio de tablas ARP, es la ٭construcción de tramas de solicitud y respuesta ARP, con el objetivo de falsear la tabla ARP (relación IP-MAC) de una víctima y forzarla a que envíe los paquetes a un servidor o huésped atacante en lugar de hacerlo a su destino legítimo; ya que ARP es el protocolo encargado de traducir direcciones IP a direcciones MAC para que la comunicación pueda establecerse.

Suplantación DNS. Esta es una suplantación o falseamiento de identidad por ٭nombre de dominio. Esto se consigue falseando las entradas de la relación Nombre de dominio-IP de un servidor DNS, mediante alguna vulnerabilidad del servidor en concreto o por su confianza hacia servidores poco fiables.

Suplantación WEB o Suplantación de Correo Electrónico. Este tipo de ٭suplantación de una página web o de correo electrónico que trata de enrrutar la conexión de una víctima a través de una página falsa hacia otras páginas WEB, la

4 El protocolo DNS; por sus siglas en inglés (Domain Name System), usa el puerto 53 de UDP y TCP.

5 El protocolo de transferencia de archivos trivial.

6 Protocolo utilizado para el puerto 515 actúa como servidor de impresión.

19

página WEB falsa actúa a modo de proxy7 solicitando la información requerida por la víctima a cada servidor original, o suplantando la dirección de un correo. El atacante puede modificar cualquier información desde y hacia cualquier servidor que la víctima visite.

1.1.1.3 Interceptación

La interceptación es un proceso mediante el cual un agente capta información que no le iba dirigida, es en principio un ataque pasivo, lo más peligroso de la interceptación es que es muy difícil de detectar mientras se produce, de forma que un atacante puede capturar información privilegiada y claves para acceder a más información sin que nadie se de cuenta hasta que dicho atacante utiliza la información capturada, convirtiendo el ataque en activo. La interceptación lógica de datos más conocida y extendida es el sniffing, el cuál consiste en capturar tramas que circulan por la red mediante un programa que está ejecutándose en una máquina conectada a ella o bien mediante un dispositivo que se engancha directamente al cableado. También existen otros tipos más de sniffing como son desde dsniff y su familia, capaces hasta de capturar los correos electrónicos directamente en formato SMTP o cargar de forma automática en un navegador las mismas páginas que visita la víctima del ataque, hasta el arcaico snoop8 de Solaris, que vuelca paquetes en un formato por defecto casi ilegible, pasando por los clásicos tcpdump9 o sniffit (que en algunas de sus versiones incluía el Touch of Dead, capaz de cortar conexiones establecidas entre dos máquinas sin más que pulsar F5). El sniffing es indetectable en la mayor parte de casos; a pesar de que existen métodos para tratar de detectar sistemas con un interfaz en modo promiscuo, no suelen ser todo lo efectivos que uno podría esperar, ya que detectar una máquina en este estado no es ni de lejos inmediato. En algunas versiones de Linux existe un programa denominado ttysnoop (por snooping - fisgoneo - se conoce a los ataques genéricos de interceptación de datos) capaz de registrar en tiempo real todo lo que un usuario teclea en una terminal, tanto física como virtual. Aunque el resultado es en muchos aspectos similar al sniffing, técnicamente poco tiene que ver con este: en ningún momento se capturan datos que circulan por la red, la tarjeta no trabaja en modo promiscuo (es mas, ni siquiera es necesario un interfaz de red), etc.; simplemente, la información que un usuario introduce en una terminal es clonada en otra, permitiendo tanto la entrada como la salida de datos a través de ambas. Aunque Linux sea el sistema Unix nativo de ttysnoop existen versiones también para otros entornos, y por supuesto esta no es la única herramienta para ‘fisgonear' en las terminales de usuarios. Otro ataque de interceptación, menos utilizado que los anteriores pero igual de peligroso, es el keylogging, el registro de las teclas pulsadas por un usuario en una sesión. Aunque es más habitual el uso de keyloggers en entornos Windows, en Unix también disponemos de ellos: podríamos incluso considerar a ttysnoop como un keylogger avanzado.

7 Equipo o dispositivo que sirve como intermediario.

8 Utilidad de Solaris que captura y muestra contenido de paquetes en red, se encuentra en el directorio

/ usr / sbin directorio 9 Utilidad en línea de comandos de la consola o terminal para analizar el tráfico de red.

20

1.1.1.4 Negaciones de Servicios Un ataque de Negación de Servicios (DoS), es uno de los ataques que intenta comprometer la disponibilidad de los recursos de una computadora. Constituyen en muchos casos uno de los ataques más sencillos y contundentes contra todo tipo de servicios, y en entornos donde la disponibilidad es valorada por encima de otros parámetros de la seguridad global, puede convertirse en un serio problema, ya que un pirata puede interrumpir constantemente un servicio sin necesidad de grandes conocimientos o recursos, utilizando programas sencillos, un módem y una computadora caseros. Los ataques DoS más comunes son los desbordamientos de pings10 y los bombardeos de correos electrónicos (ambos intentan consumir en cantidades desproporcionadas los recursos, inhabilitando los procesos legítimos). Otros ataques son creados para hacer caer el sistema, tales como el famoso “ping de la muerte”, y el “teardrop”11 son ejemplos de éstos. Existen dos tipos principales de ataques de negación de servicio:

Exploración de grietas o desperfectos. Una exploración de grietas utiliza un ٭desperfecto en el software del sistema para causar una falla en los procesos o para agotar los recursos del sistema. Con respecto a los ataques que intentan agotar los recursos del sistema, éstos pueden ser: tiempo de procesador, memoria, espacio en disco, espacio en un buffer específico, o ancho de banda de una red.

Ataques de inundación. Este tipo de ataques simplemente envían a un sistema o a ٭un componente del sistema más información de la que puede manejar. En los casos en los que el atacante no puede mandar al sistema suficientes datos para inundar su capacidad de procesamiento, el atacante puede sin embargo ser capaz de monopolizar la conexión al sistema, negando a alguien más el uso del recurso. Con este tipo de ataques no existe ninguna grieta o desperfecto en el sistema que se deba reparar.

Los ataques de Negación de Servicios pueden ser inicializados para hacer caer un sistema o inhabilitarlo. Un sistema “fail-open”12 deja de brindar protección cuando es inhabilitado por un ataque DoS. Un sistema “fail-closed”13, por otra parte, deja a la red protegida cuando es inhabilitada por la fuerza. 1.1.1.5 Ataques vía Web Estos ataques se han vuelto más populares en los últimos años, debido a que para los atacantes es más divertido, hacerse más populares al desprestigiar a grandes empresas haciendo caer sus páginas Web principales. Este tipo de ataques tienen más éxito debido a una configuración incorrecta en los servidores o a errores en el diseño del sistema, si la empresa es grande, los servidores Web suelen ser más complejos y su administración se vuelve más difícil, si la empresa es pequeña es muy posible que haya elegido un servidor Web simple en su instalación y administración y donde es casi imposible garantizar una mínima seguridad. Cada día es más sencillo para un pirata ejecutar órdenes de forma

10

Utilidad que usa el Símbolo del Sistema en Windows para pedir respuesta a otro equipo en Red 11

Ataque por fragmentación, mejor conocido como teardrop. 12

Se le llama así a los sistemas de falla abierta. 13

Se le llama así a los sistemas de falla cerrada.

21

remota en una máquina, o al menos modificar contenidos de forma no autorizada, gracias a los servidores Web que un sistema pueda albergar. Puede haber un usuario con más experiencia que intente dañar el sistema; esto es factible ya que el servidor Web proporciona excesiva información sobre su configuración, y además esta herramienta tiene algunos archivos y directorios que pueden resultar interesantes para un atacante: en el caso de los CGI que es un programa ejecutable, es equivalente a permitir a cualquiera ejecutar un programa en un sistema específico, y estos programas pueden ser vulnerables. Los CGI se utilizan para modificar páginas Web, robar información de tarjetas de crédito e instalar puertas traseras que les servirán posteriormente para tener acceso a los sistemas comprometidos. 1.1.2 Virus Un virus es un programa cuya finalidad es reproducirse de manera automática y dañar o desestabilizar al sistema donde se encuentre alojado. Estos programas se ejecutan dentro de otros programas o en los huecos de seguridad sin permiso ni conocimiento de los usuarios, pretendiendo expandirse y alterar todos los sectores posibles de los equipos.

Los virus reemplazan archivos ejecutables por otros archivos que contienen los códigos de los virus. Los virus mediante un sistema conectado a la red buscan propagarse y realizar una compilación para después copiar el virus. La mayoría de los virus se concentran en un fichero ejecutable, con lo que los virus pueden estar en un equipo pero no pueden infectarlo, a menos de que el usuario ejecute dichos programas.

La consecuencia más dañina de los virus es su autoreproducción que satura todos los recursos de la computadora. 1.1.3 Antivirus Las computadoras no son capaces de diferenciar a un programa normal, de un virus puesto que se limita a ejecutar las tareas dictaminadas por el usuario, sin embargo si el sistema operativo cuenta con herramientas de protección adecuadas, es posible detectar y detener la propagación de estos programas por todo el disco. Para controlar la amenaza de los virus se cuentan con mecanismos que ayudan a los usuarios a identificar cuando se esta ejecutando un virus para después proceder a eliminarlos del disco a estas aplicaciones se les da el nombre de Antivirus. Los antivirus pueden hacer que una computadora pierda hasta el 30% de su velocidad. Cada año cientos de millones de dólares se pierden en horas/hombre por los virus en todo el mundo. Los antivirus son instalados en el sistema y permanecen en memoria y se ejecutan en segundo plano para alertar de alguna actividad de virus al usuario y eliminarlo. Aproximadamente aparecen más de 30 mil virus cada mes y es un hecho que las actualizaciones mensuales de los antivirus no los incluyen a todos. Por lo que es de suma importancia tener actualizados dichos mecanismos, actualmente existen diversas aplicaciones antivirus que se actualizan cada mes, y la adquisición de estos paquetes permite tener un sistema limpio de programas dañinos.

22

1.1.4 Seguridad en Linux Los virus son la pesadilla de los administradores, cada mes aparecen más de 30 mil y es un hecho que las actualizaciones mensuales de los antivirus no los incluyen a todos. Para los usuarios no expertos también son una molestia, los antivirus pueden hacer que una computadora pierda hasta el 30% de su velocidad. Cada año cientos de millones de dólares se pierden en horas/hombre por los virus en todo el mundo. Los gusanos son programas que aprovechan un exploit (error en el código de un programa) para infiltrarse en un sistema. Los troyanos son gusanos que abren un puerto trasero para permitir que una persona ajena entre al sistema. La diferencia principal entre los virus y los gusanos radica en que los virus se propagan solos por la red, mientras que alguien (un hacker14) debe realizar acciones específicas para implantar un gusano. Por cada máquina atacada por un gusano existen miles (quizás millones) de equipos infectados por virus. En GNU/Linux hay gusanos y troyanos, pero no virus. Con frecuencia "expertos" argumentan que en Linux no hay virus porque hay pocos equipos con este sistema operativo, pero que en cuanto se vuelva más popular los virus aparecerán. Obviando el hecho de que Unix/Linux poseen el 40% del mercado de servidores, esta opinión revela las pobres expectativas que Microsoft le ha impuesto al usuario común, pues según éste, es normal que todos los sistemas operativos sean afectados por los virus. Pero en realidad, solo Windows padece de los virus. No todo es culpa de Microsoft, no ha sido fácil llevar a un sistema operativo tan deficiente como Windows95 al exigente mundo de los servidores: en busca de un buen desempeño, se ha debido de pagar un precio en la seguridad de Windows XP y Windows 2003. El hecho, sin embargo, es que en Linux no hay ni habrá virus, (la verdad es que en ningún sistema operativo deberían de existir los virus), la razón radica en la gestión de memoria y la asignación de permisos por omisión, los cuales hacen imposible que un programa no autorizado se ejecute y propague. Varias consultoras reportan que los servidores más atacados en Internet son los basados en Linux, y la gran mayoría sale victorioso de la prueba. Sin embargo, esto no significa que este sistema operativo sea invulnerable: los programas y el mismo kernel15 poseen fallas que al ser explotadas permiten que, en casos extremos, un extraño tome control del equipo. La mejor manera de prepararse para un ataque es siendo uno mismo un hacker, escaneando los puerto de nuestro servidor, inyectando SQL en nuestras paginas Web y tratando de ejecutar código malicioso. En Linux los usuarios no disponen de la mayoría de los permisos para modificar a los programas y archivos instalados por lo que si un virus lograra ejecutarse no podría extenderse ni dañar los archivos de sistema, a menos que sea un usuario root16, el cual cuenta con todos los permisos necesarios para controlar el sistema. 1.1.5 Mecanismos de Seguridad Informática Son utilizados para implementar políticas de seguridad y son una herramienta básica para garantizar la seguridad de la propia red. Estos mecanismos de seguridad se clasifican en

14

Se refiere a un experto en alguna rama de la informática. 15

Núcleo de un sistema operativo, del anglicismo kernel. 16

También conocido como superusuario en sistemas Unix.

23

tres grupos principales que son: mecanismos de prevención, mecanismos de detección y mecanismos de recuperación. 1.1.5.1 Mecanismos de prevención Son los que están dedicados a aumentar la seguridad de un sistema cuando se encuentra funcionando normalmente para prevenir la ocurrencia de violaciones a la seguridad. Los mecanismos de seguridad son los siguientes:

Mecanismos de autenticación e identificación. Estos hacen posible identificar ٭entidades del sistema de una forma única y una vez identificadas, 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. Un grupo especialmente importante de estos mecanismos son los denominados Sistemas de Autenticación de Usuarios. Hay varias técnicas para identificar a un usuario legítimo: se puede usar alguna contraseña que sólo el usuario legítimo tiene y debe mantenerlo seguro; otra técnica puede ser por algún objeto que el usuario legítimo posea (tarjeta inteligente con funciones de almacenamiento seguro de información y para su procesamiento) y una técnica muy segura es la autenticación biométrica la que se basa en el reconocimiento de una característica física única de un individuo como sus huellas dactilares o la pupila de uno de sus ojos. Como estas características no cambian con el tiempo el usuario podrá ser reconocido en cualquier situación.

Mecanismos de control de acceso. Cualquier objeto del sistema debe 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 Unix, el control de acceso más habitual es el discrecional, implantado por los bits rwx y las listas de control de acceso para cada archivo (objeto) del sistema; sin embargo, también se permiten especificar controles de acceso obligatorio (MAC).

Cortafuegos. Es un sistema o grupo de sistemas que hace cumplir una política de ٭control de acceso entre dos redes. Se puede definir un cortafuegos como cualquier sistema empleado para separar una máquina o subred del resto, protegiéndola así de servicios y protocolos que desde el exterior puedan suponer una amenaza a la seguridad. El espacio protegido o perímetro de seguridad, suele ser propiedad del mismo sistema que se está protegiendo, y la protección se realiza contra una red externa, no confiable, llamada zona de riesgo.

Mecanismos de seguridad en las comunicaciones. Este es especialmente ٭importante para la seguridad del sistema, el proteger la integridad y la privacidad de los datos cuando se transmiten a través de la red. Para garantizar la seguridad en las comunicaciones, se utilizan ciertos mecanismos, muchos de los cuales se basan en la Criptografía: cifrado de clave pública, de clave privada, firmas digitales, etc. Aunque cada vez se utilizan más los protocolos seguros, como SSH o Kerberos, en el caso de sistemas Unix en red, aún es frecuente encontrar conexiones en texto claro, no sólo entre máquinas de una misma subred, sino entre redes diferentes. De las mayores amenazas a la integridad de las redes se tiene este tráfico sin cifrar, que facilita ataques encaminados a robar contraseñas o suplantar la identidad de máquinas de la red.

24

1.1.5.2 Mecanismos de detección Como mecanismos de detección se les distingue a aquellos que se emplean para detectar violaciones de la seguridad o intentos de violación; ejemplos de estos mecanismos son los programas de auditoria. Casi todas las actividades realizadas en un sistema Linux son susceptibles de ser, en mayor o menor medida, supervisadas debido a la facilidad que tienen estos sistemas de registrar gran parte de las actividades ocurridas en este. Sin embargo, debido a la cantidad inmensa de información que se recoge en las bitácoras del sistema es conveniente implantar herramientas que revisen y analicen automáticamente esta información. En estos mecanismos de detección se cuenta con una herramienta muy popular en los últimos años, los Sistemas de Detección de Intrusos; que supervisan y registran toda actividad en el sistema analizando si hay en alguna actividad maliciosa para dar una respuesta a dicha actividad. Los Sistemas de Detección de Intrusos no son la única medida de control para garantizar la seguridad de un sistema informático pero se le considera una herramienta que en la práctica muestra un grado de efectividad altamente confiable. 1.1.5.3 Mecanismos de recuperación Estos mecanismos son los que se emplean cuando una violación del sistema ha sido detectada y así llevarlo nuevamente a su correcto funcionamiento; tenemos como ejemplo de estos mecanismos el uso de copias de seguridad o el hardware adicional. También los antivirus son ejemplo de este tipo de mecanismos (pero pueden ser mecanismos de detección también). Los antivirus detectan y eliminan virus informáticos y otros programas maliciosos. Un antivirus compara el código de cada archivo con la base de datos de los códigos (llamados vacunas) de los virus conocidos, haciéndose necesario e importante la actualización periódica para evitar que un virus nuevo no sea detectado. Aún cuando estos tres tipos de mecanismos son importantes en la seguridad de un sistema, es muy importante la aplicación de mecanismos de prevención y de detección. En todo sistema el detectar un intento de violación, evitar un ataque, o detectar una violación exitosa inmediatamente después de que ocurra es más productivo y menos comprometedor para el sistema a tener que rehabilitar el estado tras una penetración de la máquina. Con lo cual se hace necesario combinar más de una herramienta con el fin de fortalecer el nivel de seguridad de un sistema. 1.2 Sistemas de Detección de Intrusos Un Sistema de Detección de Intrusos o IDS (Intrusion Detection System) es una herramienta de seguridad encargada de monitorizar los eventos que ocurren en un sistema informático en busca de intentos de comprometer la seguridad de un sistema determinado, vigilan el tráfico de nuestra red, examinan los paquetes analizándolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque como pueden ser el análisis de nuestra red, barrido de puertos, etc., buscan patrones previamente definidos que impliquen cualquier tipo de actividad sospechosa o maliciosa sobre nuestra red o servidor. Definimos intento de intrusión como cualquier intento de comprometer la confidencialidad, integridad, disponibilidad o evitar los mecanismos de seguridad de una computadora o

25

red. Las intrusiones se pueden producir de varias formas: atacantes que acceden a los sistemas desde Internet, usuarios autorizados del sistema que intentan ganar privilegios adicionales para los cuales no están autorizados y usuarios autorizados que hacen un mal uso de los privilegios que se les han asignado.

1.2.1 Arquitectura de los IDS

Existen varias propuestas sobra la arquitectura de los IDS pero ninguna de ellas se usa mayoritariamente. Lo cual provoca que los productos de los fabricantes que trabajan con distinta arquitectura puedan difícilmente interactuar entre sí. "Si no existe un solo producto mágico que haga todo por nosotros, es mejor que los distintos productos utilizados para establecer nuestra capacidad de detección de intrusos interactúen. Para que estos productos funcionen juntos debe aplicarse un estándar. Los estándares originales fueron el formato ’autopost de AusCERT’ y CIDF. En estos momentos, los esfuerzos de estandarización actuales parecen ser IDWG y CVE y posiblemente algunos productos comerciales."17

1.2.1.1 Common Intrusion Detection Framework (CIDF)

El Marco de Detección de Intrusos Común es un primer intento de estandarización de la arquitectura de un IDS. Más no logró su aceptación como estándar, pero estableció un modelo y un vocabulario para discutir sobre las intrusiones. Muchas personas que trabajaron en el proyecto original están muy involucradas en los esfuerzos del Grupo de Trabajo de Detección de Intrusos (Intrusion Detección Working Group, IDWG) del Internet Engineering Task Force (IETF). Los cuatro tipos básicos de equipos que contempla el CIDF son los siguientes (ver figura 1.1):

Equipos E, o generadores de eventos, son los sensores. Su trabajo es detectar ٭eventos y lanzar informes.

Equipos A, reciben informes y realizan análisis. Pueden ofrecer una prescripción y ٭un curso de acción recomendado.

Equipos D, son componentes de bases de datos. Pueden determinar si se ha ٭visto antes una dirección IP o un ataque por medio de correlación y pueden realizar análisis de pistas.

,Equipos R, o equipos de respuesta, pueden tomar el resultado de los equipos E ٭A y D y responder a los eventos.

17

NORTHCUTT, S. Novak, J. 2001. p. 180.

26

Figura 1.1. Diagrama de bloques de la arquitectura CIDF 1.2.1.2 Common Intrusion Specification Language (CISL)

El Lenguaje de Especificación de Intrusiones Común surge de la necesidad de unir los cuatro tipos de equipos de CIDF. Los diseñadores de CISL pensaron en la necesidad de que este lenguaje debería ser capaz de transmitir los siguientes tipos de información:

Información de eventos en bruto. Auditoria de registros y tráfico de red. Sería el ٭encargado de unir equipos E con equipos A.

Resultados de los análisis. Descripciones de las anomalías del sistema y de los ٭ataques detectados. Uniría equipos A con D.

Prescripciones de respuestas. Detener determinadas actividades o modificar ٭parámetros de seguridad de componentes. Encargado de la unión entre equipos A y R.

CISL es un lenguaje bastante complicado de sintaxis parecida a LISP que no llegó a cuajar en la comunidad de seguridad.

1.2.1.3 Autopost de AusCERT

A diferencia de CIDF/CISL, el CERT australiano (AusCERT) desarrolló un sistema de trabajo sencillo el cual permitía que se analizara y se agregara un informe en una base de

AANNÁÁLLIISSIISS DDEE FFIIRRMMAASS

((AA))

AANNAALLIIZZAADDOORR DDEE

PPRROOTTOOCCOOLLOO PPAASSIIVVOO

((EE))

CCAAJJAA DDEE AALLMMAACCEENNAAMMIIEENNTTOO

((DD))

CCAAJJAA DDEE CCOONNTTRRAAMMEEDDIIDDAASS

((CC))

((RReeccoonnssttrruucccciióónn ddeell fflluujjoo TTCCPP))

((AAllmmaacceennaarr eell ccoonntteenniiddoo ddee llaa ccoonneexxiióónn eenn ddiissccoo))

((DDeetteecccciióónn ddee llaa ccaaddeennaa ““eenndd..eexxee““eenn uunnaa ccoonneexxiióónn WWeebb))

((CCeerrrraarr llaa ccoonneexxiióónn eenn aammbbooss llaaddooss))

EEtthheerrnneett

27

datos con tan solo un par de líneas de Perl. El formato que tiene el informe de un incidente puede ser el siguiente:

Source: 216.36.45.84 Ports: tcp 111 Incident type: Network_scan re-distribute: yes timezone: GMT + 1300 reply: no Time: Web 15 Mar 2000 at 14:01 (UTC)

Este sistema tiene una alta interoperabilidad y es muy sencillo de construir y analizar. El problema que presenta es que los analistas frecuentemente necesitan un gran nivel de detalle (una fidelidad alta) acerca del evento, por ejemplo, para análisis forense, y en este modelo toda esa información se perdería. La solución de interoperabilidad que parece ser la elegida es IDWG; según progresa el trabajo, la fidelidad de los datos es el indicador a vigilar más importante.

1.2.1.4 Arquitectura de IDWG (Intrusion Detection Working Group) El IETF rechazó el enfoque de CIDF con la seguridad de una cierta aversión a CISL, todo esto motivado por su complejidad, gracias a esto se creó un grupo de trabajo llamado IDWG (Intrusion Detection Working Group) cuyo objetivo fue el de definir formatos y procedimientos de intercambio de información entre los diversos subsistemas del IDS. Los resultados de este grupo de trabajo fueron:

a. Documentos que pudieran describir los requerimientos funcionales de alto nivel para la comunicación entre sistemas de detección de intrusos, así como entre los sistemas de detección de intrusos y sus sistemas de gestión.

b. Un lenguaje común de especificación que describiera el formato de los datos. c. Un marco de trabajo que identificase los mejores protocolos que puedan ser

usados para la comunicación entre los IDS además que definiera como se mapean en éstos los formatos de datos.

Actualmente existen tres borradores esperando ser aceptados como estándares.

1.2.2 Clasificación de los IDS

Con base en el tipo de sistemas que vigilan, existen dos clases de IDS: los que analizan actividades de una única máquina en busca de posibles ataques, y los que lo hacen de una subred, aunque el sistema se instale en sólo uno de sus huéspedes según figura 1.2:

28

Figura 1.2. Clasificación de los IDS

1.2.2.1 Enfoque o Tipo de Análisis Después del proceso de recopilación de información, se lleva a cabo el proceso de análisis. El objetivo principal del sensor del IDS es descartar información que le parezca irrelevante y dependiendo de la política de detección se harán las detecciones correspondientes.

La detección de intrusos también se puede clasificar según los objetivos del motor de análisis. Los dos tipos principales son: detección de anomalías y detección de usos indebidos. Detección de Anomalías La detección de anomalías conoce lo normal (en ocasiones se dice que tienen un conocimiento positivo) y detecta lo que no lo es, este esquema se limita a conocer lo anormal para poderlo detectar (conocimiento negativo), identifican comportamientos inusuales debido a lo anterior dentro de una red o en un servidor. Operan mediante datos históricos con los cuáles van construyendo perfiles acerca del comportamiento normal de los usuarios. Se recogen los datos de los eventos monitorizados y en base a una variedad de medidas de cuando la actividad registrada es distinta a la normal. Detección de Usos Indebido o Firmas Este modelo de detección contiene colecciones de firmas o patrones de ataques conocidos, supervisa los eventos registrados en el sistema en busca de ocurrencias de alguna firma de la colección.

29

Su funcionamiento se basa en la detección de usos no permitidos, es decir; se anticipa con el establecimiento de patrones definidos, con conocimiento de los ataques existentes y sus variaciones. Snort es un ejemplo de sistema basado en firmas, una de sus características más notables es, además de su funcionalidad, un subsistema flexible de firmas de ataques ya que tiene una base de datos de ataques que ya son conocidos y se está actualizando constantemente. Esta base de datos contiene las características de los ataques de red y cuando uno de ellos ocurre, y si coincide con alguno de estos patrones se lanza una alerta. 1.2.2.2 Origen de los Datos

NIDS (IDSs basados en red) La mayor parte de los sistemas de detección de intrusos están basados en red. Estos IDSs detectan ataques capturando y analizando paquetes de la red. Escuchando en un segmento, un NIDS puede monitorizar el tráfico que afecta a múltiples servidores que están conectados a ese segmento de red, protegiendo así a estos servidores. Los IDSs basados en red a menudo están formados por un conjunto de sensores localizados en varios puntos de la red. Estos sensores monitorizan el tráfico realizando análisis local e informando de los ataques que se producen a la consola de gestión. Como los sensores están limitados a ejecutar el software de detección, pueden ser más fácilmente asegurados ante ataques. Muchos de estos sensores son diseñados para correr en modo oculto, de tal forma que sea más difícil para un atacante determinar su presencia y localización. Ventajas:

• Un IDS bien localizado puede monitorizar una red grande, siempre y cuando tenga la capacidad suficiente para analizar todo el tráfico.

• Los NIDSs tienen un impacto pequeño en la red, siendo normalmente dispositivos pasivos que no interfieren en las operaciones habituales de ésta.

• Se pueden configurar para que sean muy seguros ante ataques haciéndolos invisibles al resto de la red.

Desventajas:

• Pueden tener dificultades procesando todos los paquetes en una red grande o con mucho tráfico y pueden fallar en reconocer ataques lanzados durante periodos de tráfico alto. Algunos vendedores están intentando resolver este problema implementando IDSs completamente en hardware, lo cual los hace mucho más rápidos.

• Los IDSs basados en red no analizan la información cifrada. Este problema se incrementa cuando la organización utiliza cifrado en el propio nivel de red (IPSec) entre servidores, pero se puede resolver con una política de seguridad más relajada (por ejemplo, IPSec en modo túnel).

• Los IDSs basados en red no saben si el ataque tuvo o no éxito, lo único que pueden saber es que el ataque fue lanzado. Esto significa que después de que

30

un NIDS detecte un ataque, los administradores deben manualmente investigar cada host atacado para determinar si el intento de penetración tuvo éxito o no.

• Algunos NIDS tienen problemas al tratar con ataques basados en red que viajan en paquetes fragmentados. Estos paquetes hacen que el IDS no detecte dicho ataque o que sea inestable e incluso pueda llegar a caer.

• Quizá el mayor inconveniente de los NIDS es que su implementación de la pila de protocolos de red puede diferir a la pila de los sistemas a los que protege. Muchos sistemas servidores y de escritorio actuales no cumplen en ciertos aspectos los estándares TCP/IP, pudiendo descartar paquetes que el NIDS ha aceptado. Esta inconsistencia de información entre el NIDS y el sistema protegido es la base de la ocultación de ataques que veremos más adelante.

HIDS (IDSs basados en host) Los HIDS fueron el primer tipo de IDSs desarrollados e implementados. Operan sobre la información recogida desde dentro de una computadora, como pueda ser los ficheros de auditoria del sistema operativo. Esto permite que el IDS analice las actividades que se producen con una gran precisión, determinando exactamente qué procesos y usuarios están involucrados en un ataque particular dentro del sistema operativo. A diferencia de los NIDSs, los HIDSs pueden ver el resultado de un intento de ataque, al igual que pueden acceder directamente y monitorizar los ficheros de datos y procesos del sistema atacado. Ventajas:

• Los IDSs basados en servidor, al tener la capacidad de monitorizar eventos locales a un servidor, pueden detectar ataques que no pueden ser vistos por un IDS basado en red.

• Pueden a menudo operar en un entorno en el cual el tráfico de red viaja cifrado, ya que la fuente de información es analizada antes de que los datos sean cifrados en el servidor origen y/o después de que los datos sea descifrados en el servidor o huésped destino.

Desventajas:

• Los IDSs basados en servidores son más costosos de administrar, ya que deben ser gestionados y configurados en cada servidor monitorizado. Mientras que con los NIDS teníamos un IDS por múltiples sistemas monitorizados, con los HIDS tenemos un IDS por sistema monitorizado.

• Si la estación de análisis se encuentra dentro del servidor monitorizado, el IDS puede ser deshabilitado si un ataque logra tener éxito sobre la máquina.

• No son adecuados para detectar ataques a toda una red (por ejemplo, escaneos de puertos) puesto que el IDS solo ve aquellos paquetes de red enviados a él. Pueden ser deshabilitados por ciertos ataques de DoS. Usan recursos del servidor que están monitorizando, influyendo en el rendimiento del sistema monitorizado.

31

IDSs Híbridos En estos sistemas se tienen ambos tipos de IDS anteriormente mencionados, tanto NIDS como HIDS, con la idea de tener una arquitectura híbrida, la cuál se pueda complementar e implementar simultáneamente para obtener un alto nivel de seguridad. El IDS Híbrido es aquel sistema de detección constituido por sensores en cada huésped que permiten la detección local de los sistemas y un sensor en cada segmento de red a vigilar. El agente híbrido se localiza dentro del equipo que supervisa y además es capaz de revisar en varios puntos de la red, analizando el tráfico de la misma pero solo el que va dirigido al equipo que protegen. Es capaz de agregar eventos generados por diferentes fuentes de información, proporcionando así una imagen más amplia y detallada de las actividades maliciosas en un determinado entorno. Sus componentes principales son18:

• Agentes de huésped (supervisan actividad del huésped).

• Agentes de red (supervisan la actividad en el segmento de red).

• Transceptores (comunicación).

• Consola de eventos (interfaz con el operador). Los agentes de huésped supervisan actividad interesante en el huésped en el que se encuentran instalados y son entidades independientes. Se ejecuta continuamente o bajo demanda, y se comunica con otros agentes. Puede haber varios agentes de huésped instalados en un huésped. Los agentes de red analizan la actividad de un segmento de red y se comportan como un NIDS. Normalmente los agentes de huésped y los agentes de red tienen diferentes lenguajes y propósitos. Los transceptores transmiten y reciben información de los agentes de huésped y de red, y debe haber un transceptor en cada máquina donde haya algún agente. La consola de eventos es un elemento que funciona como interfaz entre el IDS Híbrido y el administrador; es aquí donde se presentan todos los resultados de los análisis del SDI. Aunque la consola de eventos, también conocida como interfaz de usuario no forma parte de la arquitectura de implementación de un IDS, es un elemento muy importante del sistema, puesto que es quien permite y facilita la toma de decisiones al administrador o encargado ante cualquier incidente, además le permite verificar los informes o estadísticas de los análisis del sistema.

1.2.2.3 Estructura Distribuidos (DIDS) Los IDS distribuidos son aquellos sistemas en donde se implantan varios IDS que se comunican entre si o con un servidor central que permite centralizar y correlacionar todos los datos generados por ellos. El tener varios agentes distintos por toda la red permite

18

CHABLÉ Mtnez. Hilda Ma., Tesis, p. 25

32

ampliar la información de la que se dispone para la detección de un incidente en el sistema.

Centralizados Son aquellos IDS que emplean sensores que transmiten información a un sistema central desde donde se controla todo. De esta forma se permite ahorrar en costoso equipamientos pero manteniendo un amplio abanico de sensores desde donde recoger información. 1.2.2.4 Comportamiento o Respuesta Una vez se ha producido un análisis de los eventos y hemos detectado un ataque, el IDS reacciona. Las repuestas las podemos agrupar en dos tipos: pasivas y activas. Las pasivas envían informes a personas, que se encargarán de tomar acciones al respecto, si procede. Las activas lanzan automáticamente respuestas a dichos ataques. Respuestas pasivas En este tipo de respuestas se notifica al responsable de seguridad de la organización, al usuario del sistema atacado o a algún CERT19 de lo sucedido. También es posible avisar al administrador del sitio desde el cual se produjo el ataque avisándole de lo ocurrido, pero es posible que el atacante monitorice el correo electrónico de esa organización o que haya usado una IP falsa para su ataque. Respuestas activas Las respuestas activas son acciones automáticas que se toman cuando ciertos tipos de intrusiones son detectados. Podemos estableces tres categorías distintas:

• Recogida de información adicional: consiste en incrementar el nivel de sensibilidad de los sensores para obtener más pistas del posible ataque (por ejemplo, capturando todos los paquetes que vienen de la fuente que originó el ataque durante un cierto tiempo o para un máximo número de paquetes).

• Cambio del entorno: otra respuesta activa puede ser la de parar el ataque; por ejemplo, en el caso de una conexión TCP20 se puede cerrar la sesión establecida inyectando segmentos TCP RST21 al atacante y a la víctima o filtrar en el ruteador de acceso o en el cortafuegos la dirección IP del intruso o el puerto atacado para evitar futuros ataques.

• Tomar acciones contra el atacante. Esto involucra lanzar ataques en contra del intruso o intentar activamente obtener información acerca de la computadora del atacante o el sitio donde se encuentra. Sin embargo, este tipo de respuesta no es recomendable, debido a que muchos atacantes utilizan direcciones de red falsas cuando atacan sistemas, lo cual podría acarrear un gran riesgo el causar daños a sitios o usuarios inocentes de Internet.

19

Computer Emergency Response Team 20

Transfer Control Protocol 21

Opción en las banderas de la cabecera TCP llamado Reset (RST)

33

Muchos de ellos tienen unidades de respuesta que modifican las ACLs22 del cortafuegos corporativo para por ejemplo, bloquear ataques en curso, evitar el acceso a una IP de un intruso, etc. Estos sistemas reciben por tanto el nombre de Sistemas Preventores de Intrusos o IPS (Intrusion Prevention Systems). Aunque la idea parece muy sofisticada y útil hay que tener presente que dichos motores de respuesta tienen un funcionamiento muy simplista y en absoluto inteligente. Es por ello peligroso emplear dichos sistemas, puesto que pueden bloquear o restringir el acceso a recursos del sistema informático debido a falsos positivos o a análisis erróneos de los datos de entrada. 1.2.3 Ubicación de los IDS Existen principalmente tres zonas en las que podríamos poner un sensor, tal y como muestra la Figura 1.3:

Figura 1.3 Localización de un IDS dentro de una organización. Veamos las características que presenta cada una de estas zonas: Zona roja: Esta es una zona de alto riesgo. En esta zona el IDS debe ser configurado para ser poco sensible, puesto que vera todo el tráfico que entre o salga de nuestra red y habrá más posibilidad de falsas alarmas. Zona verde: El IDS debería ser configurado para tener una sensibilidad un poco mayor que en la zona roja, puesto que ahora, el cortafuegos deberá ser capaz de filtrar algunos accesos definidos mediante la política de nuestra organización. En esta zona aparece un menor número de falsas alarmas que en la zona roja, puesto que en este punto solo deberían estar permitidos accesos hacia nuestros servidores. Zona azul: Esta es la zona de confianza. Cualquier tráfico anómalo que llegue hasta aquí debe ser considerado como hostil. En este punto de la red se producirán el menor número

22

Access Control Lists

34

de falsas alarmas, por lo que cualquier alarma del IDS debe de ser inmediatamente estudiada. Es importante destacar que la zona azul no es parte de la red interna. Todo lo que llegue al IDS de la zona azul ira hacia el cortafuegos (por ejemplo, si utilizamos un proxy-cache para nuestros usuarios de web) o hacia el exterior. El IDS no escuchará ningún tipo de tráfico interno dentro de nuestra red. En el caso de tener un IDS escuchando tráfico interno (por ejemplo, colocado entre una VLAN y su router), las falsas alarmas vendrán provocadas en su mayor parte por máquinas internas al acceder a los servidores de nuestra red, por servidores nuestros (DNS sobre todo) y escaneadores de red, por lo que habrá que configurar el IDS para que no sea muy sensible.

1.3 Productos Comerciales (IDS)

1.3.1 Dragon-Enterasys Networks Análisis del Comportamiento Dragón Consola de mando de Seguridad Dragon Comando de Seguridad es una consola de Información de Seguridad y eventos de Administrador que combina las mejores características con las metodologías de detección de comportamiento. Dragon Consola Comando de Seguridad ofrece información pertinente para gestionar eficazmente la seguridad de la postura de las organizaciones más grandes.

Figura 1.4 Dragon - Consola de Mando de Seguridad La mayoría de los sistemas de detección de amenazas generan tanta información que es difícil determinar las vulnerabilidades que requieren una respuesta inmediata y de alta prioridad. El Dragón de Seguridad de la Consola de comandos (DSCC), empresa de gestión de la seguridad solución se ha desarrollado específicamente para hacer frente a este reto. DSCC proporciona potentes herramientas que permiten el equipo de operaciones de seguridad para gestionar de manera proactiva de complejas infraestructuras de seguridad.

35

Los componentes de hardware incluyen:

• Dragon mando de consola • Procesador de flujo de anomalías • Procesador de eventos • Comportamiento sensores de flujo

Dragón de Detección de Intrusos y Sistemas de Prevención Análisis de las amenazas post-Conecte el, prevención y contención.

El Dragon ® IDS / IPS es único en la industria, ya que se basa en la capacidad para entregar ambos en red y en huésped con funcionalidad simultánea y apoyo a las siguientes capacidades de prevención y detección de intrusos:

• Basada en firmas • Protocolos de base • Anomalíasde base • Comportamientos de base

Figura 1.5 Dragon de Detección de Intrusos y Sistemas de Prevención

Su alto rendimiento multi-hilos y la arquitectura virtual sensor de apoyo asegura que el Dragon pueda escalar para garantizar las redes más grandes del mundo.

Cuando Dragon IDS se combina con Enterasys NetSight Automatizado ® Security Manager (ASM) ambos se benefician ya que la fuente de los ataques ha sido identificado, localizado y automáticamente aislado o en cuarentena, si ese usuario / dispositivo está conectado a redes de Enterasys para hardware o de terceros la infraestructura. Esto es parte integrante de Enterasys la capacidad para garantizar cualquier red de cualquier proveedor.

El IPS Dragon alerta sobre el ataque, la caída de ofender a los paquetes, dar por terminado el período de sesiones para TCP y UDP a base de ataques, dinámica y establecer las reglas del cortafuegos que puede mantener la fuente de la amenaza fuera de la red de forma indefinida o configurable para un período de tiempo. El Dragon IPS de Red puede aprovechar la vulnerabilidad de miles y explotar a base de firmas de los Dragones de la amenaza bibliotecas como base para la red de control y defensa contra amenazas.

36

Red de Control de Acceso

Enterasys ® Network Access Control es una base de estándares completo, de múltiples proveedores interoperables antes y después de conectar la red de control de acceso a la solución. Enterasys NAC soporta al puerto de la RFC 3580 y VLAN basadas en cuarentena para Enterasys y de terceros, interruptores, además de las más potentes políticas de aislamiento Secure Networks ™ (que impiden comprometida criterios de valoración de lanzar ataques, mientras que en el estado de cuarentena) en los conmutadores Enterasys.

Figura 1.6 Dragon Network Access Control

1.3.2 NetRanger-Cisco Systems

Los IDS de Cisco proporcionan protección contra intrusiones tales como gusanos de Internet, usuarios no autorizados, junto con el ancho de banda y ataques de aplicación e-Business. Utilizan distintas técnicas de detección de estado incluyendo reconocimiento de patrones, análisis de protocolos, detección heurística, y la detección de anomalías.

PRODUCTOS Y PLATAFORMAS Sensores de Red: En el mercado los IDS de Cisco 4200 para la protección contra intrusiones dentro de un enfoque integral. Cisco IDS-4250: Soporta hasta 500 Mb/s sin paralelizar y puede ser utilizado para monitorizar tráfico en una red Gigabit y para tráfico atravesando conmutadores usados para agregar tráfico entre numerosas subredes.

Figura 1.7 Sensor Cisco 4250. Cisco IDS-4235: Este sensor está optimizado para monitorizar 200 Mb/s de tráfico y es especialmente adecuado para monitorizar tráfico en puertos SPAN (Switched Port

37

Analyzer) y segmentos Fast Ethernet23. También es adecuado para monitorizar múltiples entornos T3. Sensores Switch El Módulo del Sistema de Detección de Intrusiones (IDSM-2) de la serie 6500 de Cisco® Catalyst® es una importante solución de sistema de prevención de intrusiones (IPS) para salvaguardar a las organizaciones de los costosos ataques y debilidades de una red, ayudando así a asegurar la continuidad de los negocios. La segunda generación Cisco IDSM-2 protege ambientes con switches con funciones integrales en modo completo del IPS directamente dentro de la infraestructura de la red a través del chasis Cisco Catalyst completamente desplegado. Esta adaptación permite al usuario monitorear el tráfico directamente de la placa madre del switch- una plataforma lógica para servicios adicionales como el cortafuegos, VPN, e IPS. Los Cisco IDSM-2 con el Software del Sensor Cisco IPS v6.0 ayuda a los usuarios a detener más amenazas con mayor confidencialidad, mediante el uso de los siguientes elementos:

• Identificación de amenazas multivector – Inspección detallada del tráfico de las capas 2 a 7 protegiendo la red de violaciones de políticas, explotación de vulnerabilidades y actividad anómala.

• Tecnologías de prevención exactas – La innovadora característica de Grado de Riesgo (Risk Rating) de los sistemas Cisco y el Generador de Eventos Meta proveen de la confidencialidad para tomar acciones preventivas dentro de un margen más amplio de amenazas fuera del riesgo del caer en el tráfico legítimo.

Figura 1.8 Switches Cisco Catalyst Serie 6500

23

Ethernet de alta velocidad, nombre de una serie de estándares de IEEE de redes Ethernet de 100 Mbps

38

1.3.3 StoneGate Aplicaciones del IPS Las aplicaciones del sistema de prevención de intrusiones (IPS) de StoneGate se utilizan para detectar, para identificar y para responder a las amenazas de la seguridad de la red.

StoneGate IPS-6100. Las características del StoneGate IPS-6100 trabajan a una velocidad de procesamiento de 4 Gbps y se puede utilizar como el sensor en línea del IPS o Sensor-Analizador combinado.

Figura 1.9 IPS-6100 StoneGate

StoneGate IPS-6000. Las características del StoneGate IPS-6000 operan a 2 Gbps de velocidad de procesamiento y puede ser utilizado como el sensor en línea del IPS o Sensor-Analizador combinado. Protege hasta cuatro segmentos en línea. StoneGate IPS-2000. Con la capacidad de 600 Mbit/s StoneGate Ips-2000 se diseña para las sucursales, DMZ, el extranet o los segmentos internos de la red. Todas las aplicaciones del sensor de StoneGate Ips-2000 pueden proteger hasta dos segmentos en línea.

Figura 1.10 IPS-2000StoneGate

StoneGate IPS-400. Con la capacidad de 100 Mbit/s el IPS-400 StoneGate se diseña para las sucursales pequeñas. La aplicación ofrece las funcionalidades del sensor y del analizador, dando la protección flexible para los ambientes que requieren la última facilidad del uso.

Figura 1.11 IPS-400StoneGate

39

StoneGate SGI-2000S. Sensor con tres pares de “fail-open” y dos puertos de gestión, con velocidades de 1200 Mbps.

Figura 1.12 SGI-2000S StoneGate

StoneGate SGI-200S. El sensor con dos pares “fail-open” y dos puertos de administración, alcanza velocidades de hasta 400 Mbps.

Figura 1.13 SGI-200S StoneGate StoneGate SGI-200C. El analizador y el sensor combinados con dos pares de “fail-open” y dos puertos de la gestión, con velocidades de hasta 400 Mbps. StoneGate SGI-200N. Sensor que se utilizará con la solución externa de puente del hardware, velocidades de hasta 400 Mbps. StoneGate SGI-200ANZ. Analizador independiente para los sitios que tienen sensores múltiples, velocidades de hasta 400 Mbps. StoneGate SGI-20A. Analizador y sensor combinados con cuatro interfaces de la captura, velocidades de hasta 80 Mbps.

Figura 1.14 SGI-20A StoneGate

CAPÍTULO II

IDS SNORT

40

2.1 Breve Reseña Histórica En 1998, Martin Roesch desarrolló una nueva tecnología llamada Snort .al la cual le llamó una tecnología de detección de intrusión "de peso ligero" en comparación de los sistemas comerciales existentes en esa época. Durante los años el Snort ha adquirido madurez, destaca la rica tecnología que brinda la configuración estándar del sistema de prevención de intrusos. Avances recientes como lo es la actualización de las reglas así como las capacidades que ofrecen la detección de amenazas más flexible y exacta disponibles, haciendo a Snort una herramienta de peso pesado de la prevención de intrusos.

2.1.1 ¿Qué es Snort? Snort es un sistema de detección y/o prevención de intrusiones de red en código abierto, capaz de analizar la ejecución del tráfico en tiempo real, y registros de paquetes en direcciones IP de red. Puede realizarse el análisis de protocolo, contenido búsqueda/acoplamiento, y puede ser usado para detectar una variedad de ataques pruebas, por ejemplo desbordamientos del almacenador intermediario, exploraciones del puerto stealth, ataques CGI, pruebas SMB, tentativas de huella dactilar del SO y muchas más. Snort utiliza reglas flexibles de lenguaje, para describir el tráfico que debe pasar o recoger, así como un motor de la detección que utiliza una arquitectura plugin modular. Snort tiene una capacidad de alertar en tiempo real también, incorporando mecanismos de alerta para syslog, un archivo especificado de usuario, un socket UNIX, o mensajes WinPopup para clientes Windows usando los clientes SMB de Samba. Snort tiene tres usos primarios. Puede ser usado como succionador de paquete recto como tcpdump, una herramienta del paquete (útil para eliminar errores del tráfico de la red, etc), o como un sistema completamente abastecido para la prevención de las intrusiones de la red. 2.1.2 Arquitectura del IDS Snort Es realmente importante y necesario conocer los componentes con los que Snort cuenta, debido a que este utiliza distintos conectores de software, para personalizar su implementación, y aunque Snort puede desarrollar muchas tareas sencillas se hace indispensable el entender su arquitectura, ya que tendremos una visión más clara de lo que este software realiza. Básicamente se encuentra conformada por cuatro componentes básicos:

� Decodificador de paquetes � Preprocesador � Motor de detección � Subsistema de alerta y log

41

Figura 2.1 Diagrama de operación de Snort, versión oficial.

La figura 2.2 ofrece un modelo a gran escala de la arquitectura de Snort. En su forma mas simple, la arquitectura de este software es similar a un clasificador de monedas mecánico.

� Toma todas las monedas (paquetes de la red que se están escuchando). � Entonces la envía atreves de un canal inclinado para determinar si son monedas y

como deben ser clasificadas (preprocesador). � A continuación ordena las monedas de acuerdo a su tipo. Esto es para el

almacenamiento de centavos, monedas de 1, 2, 5, etc. Pesos (en el IDS es la maquina de detección de paquetes que va separando los paquetes dependiendo de su contenido y riesgo).

� Finalmente es la decisión del administrador que hacer con las monedas, usualmente almacenarlas (es el registro y almacenamiento en alguna base de datos).

Figura 2.2 Diagrama de operación de Snort, versión modificada.

42

2.1.2.1 Decodificador de paquetes (Visor de Paquetes) El decodificador de paquetes permite a una aplicación o dispositivo escuchar de forma disimulada el tráfico de la red, tienen como objetivo la obtención de datos del exterior del sistema de detección de intrusos.; son los “ojos” del IDS. Soporta gran variedad de protocolos de capa de enlace bajo TCP/IP, tales como Ethernet, ICMP (Internet Control Message Protocol), UDP (User Data Protocol), TCP (Transfer Control Protocol).Es el encargado de organizar los paquetes conforme van pasando por la pila de protocolos. Cada subrutina del decodificador ordena de una forma distinta los paquetes, formando una estructura de datos basada en punteros por encima del tráfico real capturado. Esta estructura de datos será la que guíe al motor de análisis para el posterior análisis. La figura 2.3 nos muestra la capacidad del visor de paquetes.

Figura 2.3 Diagrama a bloques de Visor o decodificador de paquetes

2.1.2.2 Preprocesador Las entradas que el preprocesador toma serán los datos en bruto del entorno exterior al IDS los verifica y compara contra ciertos plugins para pasarlos a un formato común al resto de los componentes y proporcionan los eventos al resto de componentes; es decir, cuando algún paquete ya ha sido clasificado como algún tipo de conducta pasa al motor de detección, prácticamente en tiempo real. En la figura 2.4 se observa la forma en como opera el preprocesador.

Figura 2.4 Diagrama a bloques del Preprocesador

Interface Visible

eth1

Interface Visible

eth0

SSH

HTTPS SQL SMB

SNMB

VISOR DE

PAQUETES

RED

PAQUETES

Preprocesador Motor de Detección PAQUETES

Plug-in de Cifrado HTTP

43

Una característica de suma importancia para los IDS es esta debido a que se pueden habilitar o deshabilitar los plugins a nuestro criterio o según convenga a nuestras necesidades, conforme lo vaya requiriendo el nivel del preprocesador.

2.1.2.3 Motor de Detección El motor de detección es el núcleo de los IDS. Es el motor de inferencia que, gracias a unos conocimientos, será capaz de discernir la relevancia de los eventos recibidos. Además toma los datos que vienen del preprocesador y debido a que Snort se basa en reglas este mantiene sus reglas de detección en una lista enlazada bidimensional. La lista base se denomina Cabecera de Cadena (Chain Header) y la que deriva de ésta se llama Opción de Cadena (Chain Option). Cuando llega un paquete al motor de detección, éste busca en la lista Cabecera de Cadena de izquierda a derecha la primera coincidencia. Después, buscará por la lista Opción de Cadena si el paquete cumple las opciones especificadas. Si aparece alguna coincidencia no seguirá buscando y se tomarán las acciones correspondientes. En caso contrario, buscará en el siguiente nodo de Cabecera de Cadena.

Figura 2.5 Diagrama a bloques del Motor de Detección

El motor de búsqueda tiene capacidad para la inserción de módulos plug-in (extiende las capacidades de un navegador), que pueden utilizarse para dos cosas:

a) Permiten hacer búsquedas más complicadas en los paquetes o flujos TCP cuando la sintaxis de las reglas no lo permite. A estos módulos se les llama preprocesadores, y los más utilizados son el detector de escaneos de puertos, el desfragmentador, el reconstructor de flujo TCP y el Spade, un motor de detección de anomalías aun en fase muy primitiva.

b) Permite definir modos de alerta y log no pertenecientes a Snort, como bases de

datos (MySQL, Oracle,), SNMP traps, CSV o salida en formato XML

Motor de Detección

Regla

¿Coincide con los

paquetes?

NO Descartar

SI

Registro de Alerta

Si coincide enviar alerta/registrar

44

2.1.2.4 Subsistema de Alerta/ Registros (Log)

Después de pasar los paquetes de datos por el motor de detección, debe salir de alguna forma, y esto lo hace con ayuda de este subsistema de Alertas y Registros. En este existen tres sistemas de registro o log y cuatro de alerta. Las opciones de los registros pueden ser activadas para almacenar paquetes en forma decodificada y entendible para humanos. El formato decodificado se usa para un análisis rápido y el tcpdump es mucho más rápido de almacenar y proporciona un mayor rendimiento. Las alertas se pueden realizar por syslog, en ficheros texto mediante dos formatos distintos (rápido y completo). Avisan del tipo de ataque detectado y ofrece información adicional como IP origen y destino, fecha y hora de la detección y campo de datos. El componente de alertas en forma similar al motor de detección y al preprocesador utiliza plugins para enviar alertas a las bases de datos y a través de protocolos de red como SNMP. Ver la figura 2.6 para observar como funciona.

Figura 2.6 Diagrama a bloques del Subsistema de Alerta y Log Snort dispone de un mecanismo que optimiza considerablemente su rendimiento. Puesto que normalmente se quiere un sistema de back-end potente como una base de datos SQL para hacer correlaciones de los ataques, las escrituras de los logs o registros suelen ser muy robusto. Al ser Snort un proceso monolítico, mientras que se encuentra escribiendo en la base de datos es incapaz de hacer otras cosas, como procesar el tráfico de entrada. 2.2 Instalación del IDS Snort Para la instalación de Snort en este proyecto, se hizo uso de la plataforma Linux como Sistema Operativo, además este Sistema de Detección de Intrusos (IDS) en código abierto Snort, tiene una serie de requerimientos para su funcionamiento y para la obtención de sus registros, alertas, y demás información que nos es útil.

Registro WEB/Interacción con el Usuario

Archivo de Registro del Sistema

Alertas/Registros

Traps de SNMP Archivos de Registro/ Base de Datos

Archivos de Registro/ Base de Datos

45

Lo que a continuación se muestra es la base teórica del software y herramientas que en dado momento le será necesario a Snort para mostrar lo que ha obtenido en su proceso de detección, tales elementos de ayuda son bases de datos, servidores Web e interfases gráficas para la visualización gráfica y ordenada de sus resultados. 2.2.1 Linux como plataforma del S.O. utilizado 2.2.1.1Orígenes de Linux Entre los sistemas operativos que había hace una década estaba Minix, un sistema operativo tipo Unix, de fuentes publicas, que se había escrito a modo didáctico para los estudiantes de ingeniería informática. Funcionaba en un procesador 8086, por lo que era un poco limitado. Linus Tolvards un estudiante finlandés de informática que investigando y profundizando en los microprocesadores 386 decidió hacer, partiendo de cero, un sistema operativo, basado en Minix, pero que aprovechase toda la potencia del 386, memoria virtual, multitarea y otras cosas. Así que empezó a crearlo, las primeras versiones eran poco atractivas, apenas ejecutabas el GCC (un compilador de C creado según el estilo GNU) el bash (el equivalente al command.com). Pero Linus, lo publico en Internet, con sus fuentes, y un montón de gente se intereso en él, modificándolo, mejorándolo y añadiéndole cosas, a la vez que Linus lo mejoraba y coordinaba todo el trabajo que hacían el resto de la gente. Y así sigue siendo hoy, cientos de versiones después hasta convertirse en lo que tenemos delante. La gente de GNU creó un montón de programas para su sistema operativo que gracias a que son software libre son también usados en Linux y por eso a Linux se le llama muchas veces GNU/Linux. El núcleo de Linux, el kernel, se distribuye bajo la licencia GPL, es un tipo de licencia, dentro de lo que podríamos llamar el Software de Código Abierto (Open Source), básicamente dice que cojas el programa, lo uses, aprendas, lo mejores y compartas esas mejoras con el resto del mundo. Además la licencia GNU fija una serie de derechos a programador que le protegen, pero en resumidas cuentas: Un Programa con Licencia GPL puede ser vendido, alquilado, prestado modificado, pero:

• No se puede limitar el número de usuarios, copias o tiempo de uso.

• No se puede cobrar por usar el programa (pero sí por distribuirlo).

• No se puede impedir que otros lo vendan o distribuyan.

• Tienes que dar las fuentes del programa de una manera pública.

• Puedes modificar el programa, o aprovechar parte del código, pero el resultado tiene que seguir la misma filosofía.

Es básicamente lo que llamaríamos un programa Freeware, o Gratis. Linux sigue esta licencia. Por eso encontramos revistas que lo regalan a gente que cobra por él y a gente que lo descarga de Internet.

46

Características de Linux Multitarea El ordenador puede estar haciendo varias cosas a la vez, y que no tendrás que esperar a que acabe una para hacer otra, la multitarea esta controlada por el S.O., no por las aplicaciones, por lo que a diferencia de otros S.O. nunca se te quedara parado por culpa de una mala aplicación que consuma todos los recursos del ordenador. Aquí si podrás bajar correo de Internet, formatear un disco, imprimir 100 hojas, tener aplicaciones de juegos sin problemas. Multiusuario Si has manejado otros S.O., seguramente usas MAC OS o Windows, en estos S.O. tú eres el único que lo usas, en Linux, puede haber varias personas usando el ordenador, compartiendo el microprocesador, así puedes ponerle un par de pantallas y teclados y estar otra persona navegando por Internet, escribiendo una carta, jugando en su pantalla, mientras tu estas en otra haciendo otra cosa completamente diferente, pero ambos en el mismo cpu. Además proporciona los elementos necesarios para garantizar la seguridad y la privacidad de los datos entre usuarios. POSIX Aunque para los usuarios normales esto importa poco, POSIX es un estándar de la industria, que asegura una calidad mínima en ciertas partes del S.O. y asegura su compatibilidad, a nivel de código, es decir, programas POSIX que funcionan en otros Unix, no tendrán problema para compilarse y ejecutarse en Linux. Para muchas empresas esto es muy importante, a la hora de decidirse por un S.O. u otro (por eso Windows NT es compatible POSIX). Compatibilidad Cuando se toca el tema de compatibilidad, la gente tiene opiniones sobre dificultades comunes, por ejemplo, Ejecutar sus aplicaciones favoritas en distintos ambientes como Windows, MAC y Unix. Ficheros Linux no tiene ningún problema para compilar cualquier tipo de disco de cualquier cosa que exista, leerlo y usar su contenido, además existen Suites como OpenOffice o Corel WordPerfect que permiten leer y usar ficheros de aplicaciones comunes como puedan ser Word o Excel. Además cuando se trabaja en red, Linux es capaz de entenderse y de mediar entre todo tipo de redes, permitiendo entornos heterogéneos sin ningún problema. Programas Se pueden ejecutar programas de otros S.O. para MAC tienes basilisk2, capaz de crear un Macintosh virtual y ejecutar MacOs para M68K sin problemas.

47

Para Windows existen varios programas que permiten hacer funcionar programas de Windows, crossoffice (para entornos de oficina), WineX para juegos, y la versión libre de estos Wine, que permite ejecutar la mayoría de los programas. Si el programa es para MS-Dos existe DosEmu, un emulador de MS-Dos (bueno no exactamente, más bien habría que decir de 386) donde podrás ejecutar a pantalla completa, como en la realidad, o en ventana de X Windows, cualquier programa para este S.O. Además de estos existen vmware (comercial) y bosh que crean PC virtuales donde ejecutar cualquier sistema operativo. Estabilidad Linux es un S.O. robusto si existe alguna aplicación mal construida por supuesto que no funcionará, pero no afectará al resto del sistema, nunca tendrás que reiniciar el CPU por que un programa lo ha sobrecargado, hay que notar que es posible que se bloquee el teclado o la pantalla, pero eso no significa que se sobrecargue el ordenador, puedes entrar al ordenador por otro sitio (una terminal, por red) y desbloquearlo, y seguir usándolo, o si se te bloquea un programa mientras estabas conectado a Internet y descargando el correo, quizás no puedas usar el ordenador, pero seguirá bajando el correo sin problemas. Es libre Es decir no te costara nada, no tendrás que pagar licencias, podrás copiarlo, venderlo, instalarlo donde quieras sin problemas, pero lo más importante es que dispones del código fuente, esto significa que si un día te encontrases con un problema del S.O. no tendrías que esperar inútilmente a que su creador decidiese que era un problema importante y crease un service pack para el S.O., tu mismo puedes solucionar el problema o puedes indicarle a una tercera persona el problema, y esta no tendrá que ser de la empresa que creo el S.O. para poder solucionártelo. Soporte Parece mentira, siendo gratis, pero aparte del que te da Mandrake, SUSE, RedHat, Ubuntu, si le compras los CD a estas empresas, existen cientos de personas, de todos los idiomas conocidos, que gustosos te ayudaran a solucionar cualquier problema que tengas con Linux, y en pocos días. Una opción mas es la de unirte a las listas de distribución que hay en Internet, no solo aprenderás, podrás ayudar a otros en los problemas que tengan. Adaptación Linux es uno de los S.O. que más rápido evoluciona, se adapta al mercado y soluciona los problemas rápidamente, como por ejemplo el bug F00F del Pentium, Linux fue el primero en tener solución, Soporta el sistema FAT32 de Microsoft antes que sus propios Sistemas Operativos (Windows NT 4), a sido de los primeros en estar disponible para las arquitectura Athlon64.

48

2.2.2 Bases de datos A las bases de datos se les conoce como el conjunto, colección o depósito de datos almacenados en un soporte informático no volátil, donde los datos están interrelacionados y estructurados. Un SGBD es conocido como el “conjunto coordinado de programas, procedimientos, lenguajes, etc. que sumistra a los distintos tipos de usuarios los medios necesarios para describir y manipular los datos almacenados en la base, garantizando su seguridad”24 Las funciones esenciales de un SGBD son: La descripción, que permite especificar los datos y sus relaciones. La manipulación que a su vez se refiere a consultas ya sean totales o selectivas y a la actualización de los datos (insertar, borrar y modificar). Y el control el cual proporciona elementos para la administración. Para cumplir con la función de manipulación los SGBD, requieren de lenguajes que permitan tanto a usuarios finales como a programadores tener acceso a los datos de una base de datos determinada. El lenguaje más popular actualmente para la gestión de bases de datos relacionales es SQL Nace con el nombre de “SEQUEL” (SQL) implantado por IBM. En 1979 aparece el primer SGBDR comercial basado en SQL: ORACLE. Para el año 1992 se hace una revisión del ANSI para SQL, quedando como el único lenguaje relacional que es ANSI estándar. También los siguientes SGBDR incorporan SQL: MySQL, SQL, SERVER, PostgreSQL, entre otros. Aunque el nombre SQL sugiere un lenguaje de consulta, también se pueden realizar entre otras como la definición de tablas, actualización a la base de datos, definición de vistas y definición de privilegios. Debido a que se ha convertido en un estándar actualmente existen entre otras las siguientes bases de datos basadas en SQL, las cuales se describen a continuación. 2.2.2.1 MySQL Historia La empresa opensource MySQL AB establecida inicialmente en Suecia en 1995 y cuyos fundadores son David Axmark, Allan Larsson, y Michael "Monty" Widenius, es la creadora de MySQL. Esta empresa tiene como objetivo que MySQL cumpla el estándar SQL, sin tener que sacrificar velocidad, fiabilidad o usabilidad. Michael Widenius. En los 90’s intentó usar mSQL para conectar las tablas usando rutinas de bajo nivel ISAM, mas mSQL no era tan rápido y flexible para sus necesidades. Lo que hizo que creara una API SQL denominada MySQL para bases de datos muy similar a la de mSQL pero más portable. El origen del nombre de MySQL no es claro. Desde hace más de 10 años, las herramientas han mantenido el prefijo My. Se piensa que tiene relación con el nombre de la hija del cofundador Monty Widenius llamada My. Por otro lado, el nombre del delfín de MySQL es Sakila y fue seleccionado por los fundadores de MySQL AB en el concurso “Name the Dolphin”. Este nombre fue enviado por Ambrose Twebaze, un desarrollador de Open source Africano, derivado del idioma SiSwate, el idioma local de Swazilandia y corresponde al nombre de una ciudad en Arusha, Tanzania, cerca de Uganda la ciudad origen de Ambrose.

24

Torres Villasánchez Juan C 2007. p4.

49

MySQL, es un sistema de gestión de base de datos relacional, multihilo y multiusuario cuenta con más de seis millones de instancias. MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. MySQL AB pertenece a Sun Microsystems desde el mes de Enero de 2008. MySQL se ofrece por un lado bajo la GNU GPL, para cualquier uso compatible con la licencia pero las empresas que deseen incorporarlo en productos privativos pueden comprar a la empresa una licencia específica que les pueda permitir este uso. En su mayor parte se encuentra desarrollado en ANSI C.

Figura 2.7 Pantalla de Inicialización de MySQL A diferencia que proyectos como Apache, en donde el Software es desarrollado por una comunidad pública y el copyright del código esta en poder del autor individual, MySQL es propiedad y esta patrocinado por una empresa privada, que posee el copyright de la mayor parte del código. Todo esto hace posible el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios. En el caso de sus operaciones contratan trabajadores alrededor del mundo que colaboran vía Internet MySQL AB fue fundado por David Axmark, Allan Larsson y Michael Widenius. Lenguajes de programación Se cuenta con varias APIs las cuales permiten, a aplicaciones escritas en diversos lenguajes de programación, y poder acceder a las bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via dbExpress), Eiffel, Smalltalk, Java (con una implantación nativa del driver de Java), Lisp, Perl, PHP, Python, Ruby,Gambas, REALbasic (Mac), FreeBASIC, y Tcl; cada uno de estos utiliza una API específica. También existe un interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de programación que soporte ODBC comunicarse con las bases de datos MySQL. Aplicaciones MySQL es muy usado en aplicaciones web como MediaWiki, Drupal o phpBB, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de

50

seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede llegar a provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. 2.2.3 Interfases Gráficas de Bases de Datos para Snort Siempre se tratará de que el detector de intrusos en este caso Snort, arroje sus alertas en una SGBD de las citadas anteriormente según se requiera, de la cual se leen los datos en una interfaz Web construida en PHP (BASE) a través de ADODB, de manera que sea más fácil hacer gráficos de las alertas, para poder verlas por destino, por puerto, eliminarlas, archivarlas, etc. Esto se logra teniendo cuidado de configurar y mantener nuestro IDS correctamente con lo cual nos alertará de los intentos de intrusión y ataques varios que nuestra red pueda sufrir, porque de lo contrario nuestro disco duro se llenará un basura y nos puede colapsar el tráfico de la red. El ingeniero Daniel medianero25 recomienda hacer uso de la base de datos MySQL de la cual se leen los datos en una interfaz web construida en PHP (BASE) a través de ADODB

2.2.3.1 BASE (Basic Analysis and Security Engine)

BASE es la interfaz en PHP, con la cual nos podemos relacionar para ver las alertas, eliminarlas, clasificarlas, etc. Su descarga e instalación es muy sencilla e independiente de la distribución de Linux que usemos, son apenas unos comandos que colocarán BASE en un lugar en el cual Apache2 pueda proporcionárnoslo posteriormente.

Figura 2.8. Pantalla gráfica de finalización de BASE instalado

25

Medianero García Daniel. 2008 ftp://meleagro.homeunix.org

51

Figura 2.9 Ejemplo de gráficas obtenidas en BASE

2.2.3.2 ACID (Analysis Console for Intrusion Databases) ACID, es la interface Web para la visualización de los logs recogidos por Snort, no necesita instalación alguna, solo se debe descargar y guardarlo en el lugar que se le designe, donde se tengan los hostings, ya que es una página web y al momento de descomprimirlo tenemos una interface ACID. Para configurarla simplemente se debe editar el archivo.

52

ACID se encuentra desarrollada en lenguaje PHP, que nos muestra los registros guardados por Snort. Así puede guardarlos en una base de datos o en simples ficheros de texto como puede ser syslog. Si hemos decidido usar ACID para visualizar sus efectos, deberemos usar MySQL como almacén para los logs recogidos por Snort. ACID es una interface web, por lo que partimos de la base de que el sistema operativo sobre el que esta funcionando tiene instalado un servidor Web. Para configurarla ACID solo se debe editar el archivo acid_config.php y especificarle los parámetros referentes a la base de datos contra la que va a trabajar (el nombre de la base de datos, ip del servidor, login y password, entre otros). Una vez apuntado, se crea un VirtualHost en el servidor apache al cual se puede puede acceder (http://httpd.apache.org/docs/vhosts/examples.html) anotando el directorio donde se descomprimió ACID, y se reinicia el servidor Web. Una vez hecho eso, se anota con el browser a la dirección del virtualhost: http://direccion_de_virtualhost/acid_main.php Una vez que se ha entrado se comprobará el estado de las tablas básicas para iniciar el logging, si estas no están creadas correctamente, pedirá permiso para hacerlo, contestando que si, haciéndolo ya sin ningún problema. Ahora ya se puede tener acceso a la interface ACID y seguramente se verán las barritas rojas de las “gráficas” con el porcentaje de trafico TCP, ICMP y UDP. Pero para tener acceso a ver esta página ACID nos pedirá autentificación (login y password) al entrar, se puede hacer de varias formass, pero lo recomendable es usar la autentificación del propio servidor Web.

Figura 2.10 Pantalla gráfica de de ACID

53

Figura 2.11 Pantalla para crear ACID

Figura 2.12 Gráficos de alertas registradas por Snort con el interfaz ACID 2.2.4 Servidores WEB Se sabe que un servidor Web es un programa que implanta el protocolo HTTP (hypertext transfer protocol). Este protocolo está diseñado para transferir lo que se conoce como hipertextos, páginas Web o páginas HTML (hypertext markup language). Textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música. Sin embargo, el hecho de que HTTP y HTML

54

estén íntimamente ligados no debe dar lugar a confundir ambos términos. HTML es un lenguaje de marcas y HTTP es un protocolo. Por lo tanto un servidor Web se encarga de mantenerse a la espera de peticiones HTTP llevada a cabo por un cliente HTTP que se conoce como navegador. El navegador realiza una petición al servidor y éste le responde con el contenido que el cliente solicita. A modo de ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste realiza una petición HTTP al servidor de dicha dirección. El servidor responde al cliente enviando el código HTML de la página; el cliente, una vez recibido el código, lo interpreta y lo muestra en pantalla. Como se puede ver con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo ninguna interpretación de la misma.

Figura 2.13 Servidor Web de la Wikimedia

Acerca del servicio Web clásico se puede disponer de aplicaciones Web. Las cuales son fragmentos de código que se ejecutan cuando se realizan ciertas peticiones o respuestas HTTP. Pero se debe distinguir entre:

• Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo Java o Javascript: el servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Por tanto, es necesario que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts). Normalmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden añadirse más lenguajes mediante el uso de plugins

• Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código recién creado y lo envía al cliente por medio del protocolo HTTP.

Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayoría de las ocasiones para realizar aplicaciones Web. La razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad adicional, como sí ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues,

55

cualquier cliente dotado de un navegador Web básico puede utilizar este tipo de aplicaciones. 2.2.4.1 Apache Tenemos que el servidor HTTP Apache es un software libre, servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1[1] y la noción de sitio virtual. En un principio su desarrollo hacia el año 1995, se basó inicialmente en el código del popular NCSA HTTPd 1.3 y fue reescrito por completo tiempo después. Behelendorf eligió ese nombre decidido a que tuviese la connotación de algo firme y enérgico y no agresivo, como la tribu Apache que fue la última en rendirse al recién formado gobierno de EEUU, haciendo una analogía por la preocupación de su grupo para que llegasen las empresas y "civilizasen" el paisaje creado por los primeros ingenieros de internet. Además Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor "emparchado"). Este servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation. Y presenta entre otras características: mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración.

Apache

Instalador de Apache HTTP Server 2.2.2

Desarrollador: Apache Software Foundation

Última versión: 2.2.8 (19 de Enero de 2008)

S.O.: Multiplataforma

Género: Servidor web

Licencia: Licencia Apache

En español: -

Sitio Web: [ http://httpd.apache.org/]

Tabla 2.4. Generalidades del Servidor Apache

56

El servidor Apache tiene gran aceptación en la red: desde 1996, es el servidor HTTP más usado. Alcanzó su máxima cuota de mercado en 2005 al ser el servidor empleado en el 70% de los sitios Web en el mundo, sin embargo ha sufrido un descenso en su cuota de mercado en los últimos años26. La mayoría de las vulnerabilidades de la seguridad descubiertas y resueltas tan sólo pueden ser aprovechadas por usuarios locales y no remotamente. Sin embargo, algunas se pueden accionar remotamente en ciertas situaciones, o explotar por los usuarios locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP como módulo de Apache. Ventajas

• Modular

• Open source

• Multi-plataforma

• Extensible

• Popular (fácil conseguir ayuda/soporte)

• Gratuito

• Módulos La arquitectura del servidor Apache es muy modular. El servidor consta de una sección core y diversos módulos que aportan mucha de la funcionalidad que podría considerarse básica para un servidor Web. Algunos de estos módulos son:

• mod_ssl - Comunicaciones Seguras vía TLS.

• mod_rewrite-Reescritura de direcciones (generalmente utilizado para transformar páginas dinámicas como php en páginas estáticas html para así engañar a los navegantes o a los motores de búsqueda en cuanto a como fueron desarrolladas estas páginas).

• mod_dav-Soporte del protocolo WebDAV (RFC 2518).

• mod_deflate-Compresión transparente con el algoritmo deflate del contenido enviado al cliente.

• mod_auth_ldap-Permite autentificar usuarios contra un servidor LDAP.

• mod_proxy_ajp-Conector para enlazar con el servidor Jakarta Tomcat de páginas dinámicas en Java (servlets y JSP).

El servidor de base puede ser extendido con la inclusión de módulos externos entre los cuales se encuentran:

• mod_perl - Páginas dinámicas en Perl.

• mod_php - Páginas dinámicas en PHP.

• mod_python - Páginas dinámicas en Python.

• mod_rexx - Páginas dinámicas en REXX y Object REXX.

• mod_ruby - Páginas dinámicas en Ruby.

• mod_aspdotnet - Páginas dinámicas en .NET_de_Microsoft (Módulo retirado).

• mod_mono - Páginas dinámicas en Mono

• mod_security - Filtrado a nivel de aplicación, para seguridad.

26

Estadísticas históricas y de uso diario proporcionadas por Netcraf.

57

2.3 Modos de Alerta El IDS Snort cuenta con una gran cantidad de opciones en sus líneas de comando para manejarlo. Por lo que no siempre funcionan correctamente juntas. Hay algunos conceptos básicos que deben ser entendidos acerca de snort ya que puede ser configurado para que funcione en los siguientes modos27. 2.3.1. Modo Sniffer (Sniffer mode) En este modo simplemente ve los paquetes que se encuentran en la red y los despliega de manera de flujo de datos en una ventana de consola. Para mostrar las cabeceras de los paquetes TCP/IP en pantalla se necesita el siguiente comando: ./snort –v Este comando ejecuta a Snort y solo muestra las cabeceras IP y TCP/UDP/ICMP. Para ver la aplicación de los datos en transito se requiere insertar el siguiente comando: ./snort vd Este comando indica a Snort que despliegue los paquetes de datos como las cabeceras. Si se quiere una descripción aún más descriptiva, se ingresa el siguiente comando: . /snort -vde También se puede ejecutar en una sola línea de comando las instrucciones pasadas obteniendo el mismo resultado:

. /snort –d –v –e 2.3.2 Modo de registro de paquetes (Packet Logger mode). En este modo el Snort guarda los registros en el disco, solo se necesita especificar un directorio de registro y Snort automáticamente sabrá donde almacenarlos. ./snort -dev -l ./log Snort al ser ejecutado en este modo recolecta cada paquete que ve en la red y lo coloca en el directorio especificado (log), basado sobre la dirección IP de uno de los huéspedes de los datagramas, si solo se especifica el accionador –l , se podrá notar que Snort algunas veces usa la dirección de la computadora remota, como el directorio en donde están los paquetes y algunas otras ocasiones usará la dirección de huésped local. 2.3.3 Modo NIDS (Network Intrusion Detection System, NIDS mode) Esta es la configuración mas compleja, este modo le permite a Snort analizar el tráfico de la red mediante marcas, en contra de un conjunto de reglas de usuario definido y hace funcionar algunas acciones basadas en lo que Snort puede ver. Para habilitar el modo de detección de intrusos en red (NIDS), se necesita la siguiente línea:

. /snort –dev –l ./log –h 192.168.1.0/24 -c snort.conf

27

Se trabajo en el modo Sniffer, Packet Logger mode, Nids.

58

En donde snort.conf es el nombre del archivo de reglas. Esta línea aplicará las reglas configuradas en el archivo snort.conf para cada paquete que decida si una acción basada en algún tipo de regla en el archivo debe de ser tomada. Si no se selecciona un archivo de salida para el programa, se tomará por default el directorio /var/log/snort. Un punto a notar acerca de los últimos comandos de línea, es que si Snort está siendo usado por largo tiempo como un IDS. El accionador –v se puede quitar de la línea de comandos por motivo de velocidad. La pantalla es un lugar lento para escribir los datos, y los paquetes pueden pasar rápidamente mientras se escriben en la pantalla. Esto casi no es necesario para grabar las cabeceras de los enlaces de datos para la mayor de la aplicaciones, por eso usualmente se pueden omitir el accionador –e también.

./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf Snort también puede ser configurado para ejecutarse en el modo NIDS básico, registrando los paquetes que accionan las reglas especificadas en el archivo snort.conf en código ASCII que usa una estructura de directorio jerárquico. 2.3.4 Modo en línea (Inline Mode) El snort 2.3.0 integro el sistema de prevención de intrusos la capacidad de snort Inline en el proyecto oficial de snort. Snort Inline obtiene paquetes de tablas ip o paquetes llenos de reglas basadas en snort. Para trabajar apropiadamente el Snort Inline, debes descargar y compilar las iptables con el código incluido “make install-devel” de la web.

(www.iptables.org) Esto instalado en la librería libipq permite la interface de Snort Inline con las iptables. Existen tres tipos de reglas que puedes usar cuando compilas Snort con Snort Inline:

• drop: la regla de tipo drop dirá a las iptables el flujo del paquete para enviar su significado por la vía usual.

• Reject: La regla tipo reject dirá a las iptables el flujo de paquetes para enviar su significado por la vía usual y enviar el reseteo al protocolo TCP si el protocolo es TCP o a un puerto de icmp inalcanzable si el protocolo es UDP.

• Sdrop: La regla tipo Sdrop dirá a las iptables el flujo del paquete, nada es enviado. Nota: También puede sustituir las secciones de la carga útil del paquete usando el Snort Inline. Orden de aplicación de las reglas para Snort Inline El orden de aplicación para las reglas es el siguiente: ->activation->dynamic->drop->sdrop->reject->alert->pass->log

59

Esto asegurara que la regla Drop tiene mayor prioridad que la regla Alert o la regla Log. Se puede usar la bandera -o para cambiar el orden del uso de la regla. ->activation->dynamic->pass->drop->sdrop->reject->alert->log 2.4 TÉCNICAS DE DETECCION DE LOS IDS Existen diversas tecnologías utilizadas para la detección de intrusos, a continuación se muestran algunas de estas técnicas: 2.4.1 Detección de patrones Detectan ciertas actividades del sistema operativo o cadenas de bits en tráfico de red que indican actividad que pertenece o se relaciona con ataques conocidos. En cuanto sea mayor el número de patrones reconocidos como una anomalía o un ataque potencial, mayor será la capacidad del IDS para detectar ataques. La mayor desventaja de estos sistemas es que los patrones de los ataques que ya son conocidos están almacenados en algún lugar en el sistema, y no serán capaces de detectar futuras intrusiones que sean desconocidas, es decir que no correspondan con alguno de los patrones almacenados por el sistema. Por ejemplo, el sistema STAT basa su funcionamiento en la detección de patrones, éste codifica y hace corresponder la secuencia de acciones de un evento en una firma, por ejemplo, cambiar el dueño de un archivo y cuando detecta un evento que no corresponde con alguna de las firmas almacenadas lo considera como un ataque. 2.4.2 Técnicas de inteligencia artificial. Identifican patrones de ataque o actividad anómala por medio de ciertos indicadores para un perfil. Este tipo de tecnologías construyen modelos dinámicos para los perfiles de uso normal de un sistema, los cuales se van retroalimentando con los diferentes tipos de actividad —maliciosa o no— que se presenten en el sistema y así obtener perfiles que se adecúen al comportamiento habitual del sistema. Por ejemplo, a través de redes neuronales entrenadas para aceptar actividad cotidiana y disparar una alarma cuando hay una desviación considerable en los indicadores; estas redes comienzan con un grado de experiencia bajo ganado con algunos ejemplos de ataques seleccionados con anterioridad y van ganando experiencia analizando el comportamiento del sistema a través del tiempo, obteniendo así un nivel cada vez más alto de entrenamiento. La red MLFF (Multilayered Feed Forward Network) es usada como una aproximación universal para clasificar, reconocer y generalizar los datos de entrada tomados de un grupo de datos de ejemplo; estos datos son los que brindan el aprendizaje a la red neuronal. Así se modela una red que es capaz de encapsular el comportamiento de un usuario y que es tan flexible como para añadir constantemente grandes, pequeños y tal vez imperceptibles cambios del comportamiento de los usuarios al modelo actual. 2.4.3 Métodos estadísticos. Identifican desviaciones numéricas en ciertos indicadores, basándose en perfiles previamente definidos de lo que constituye un ataque o actividad legítima.

60

Un modelo estadístico es aquel que se basa en un análisis estadístico del comportamiento previo de un evento para poder determinar de manera aproximada el valor que tendrá en futuras repeticiones. Los modelos estadísticos usan una gran cantidad de datos de comportamiento obtenidos previamente. Los métodos estadísticos son muy usados en el análisis de tráfico de una red local, por ejemplo; con estos métodos se puede modelar de manera estadística el comportamiento normal de la red recolectando, promediando, y suavizando una gran cantidad de datos que son resultado del muestreo de paquetes de varios días de actividad. Estos modelos sirven para determinar el nivel de desempeño cotidiano de la red, y cuando se presente un comportamiento que tenga un error mayor al permitido con respecto al desempeño cotidiano del modelo se considera como una anomalía. Como se puede ver, existen dos enfoques en la aplicación de tecnologías de detección de intrusos:

• Detectar aquello que es plenamente conocido (ataques o actividad legítima).

• Detectar aquello que es desconocido (actividad anómala, generalmente asociada con ataques).

CAPÍTULO III

PRUEBAS Y PROPUESTA DE IMPLANTACIÓN

61

3.1 Introducción En este capítulo se obtienen los resultados del proyecto para poder hacer un análisis de estos resultados. En principio, se muestra la forma como se inicializa correctamente Snort en modo Sniffer, modo de registro de paquetes, y modo de detección de intrusos en red (NIDS), en la modalidad rápida y completa, después se divide en dos secciones este capítulo; primeramente con un ambiente simulado, en el cuál se realizan algunos tipos de ataques, esto lo hacemos desde un equipo atacante o mal intencionado, hacia el equipo en el que esta montado el IDS Snort; después se tiene la parte de los registros almacenados en los registros log, que se encuentran en los directorios de Snort, con ataques reales, hechos desde equipos desconocidos al equipo con el IDS. 3.2 Implantación de IDS Snort en un punto de la Red de ESIME Zacatenco Para llevar a cabo la presente investigación y reflejar los conocimientos acerca de Snort, ver su funcionamiento, se tiene que partir de la idea de montar en algún equipo preferentemente en la escuela, en donde se pudiese llevar a cabo la instalación del IDS, así que para ello se enuncian a continuación los pasos que se siguieron para realizar este proyecto y la investigación correspondiente. 3.2.1 Utilización de un Puerto Espejo Un puerto espejo es aquel puerto que se encarga de retransmitir el trafico en uno o varios puertos de algún dispositivo de comunicación de datos. Para que el IDS Snort pueda ver el tráfico de la red, se puede hacer uso de una técnica conocida como puerto espejo, la cuál consiste en que el servidor que este viendo el tráfico que va de Internet a la red interna en ESIME, está conectado a los equipos conmutadores o switches que hay, así que otro equipo, en el que esté montado Snort se conectará a el conmutador al que esté conectado el servidor que esté viendo el tráfico que aquí interesa, de esta forma debido a que estos dispositivos tienen la cualidad de realizar una especie de reflejo del flujo de datos a través de señales eléctricas en los dispositivos de comunicación, hacen de esta forma, un puerto espejo, debido a que los puertos del switch, reflejan el tráfico real que va del servidor al otro lado de este, donde está la red de datos. Los puertos espejo son ideales para el monitoreo de redes en general ya que no intervienen directamente en el funcionamiento de la red, son una opción indicada para el análisis y trabajan en forma paralela a varios puertos utilizados en la red. En la figura 3.1. se puede observar en forma esquemática a modo general la forma de conexión de un puerto espejo.

62

IDS

Flujo de Datos Reflejado

Tráfico que llega al servidor

Flujo de Datos de la Red

Figura 3.1 Ejemplo propuesto de un Puerto Espejo 3.2.2 Limitantes para la Implantación del Sistema En el siguiente apartado se dan a conocer las limitantes para desarrollar el presente proyecto, debido a los cuáles fue necesario modificar el objetivo general, ya que para hacer esto, se necesitaban bases de conocimientos acerca de un Sistema Operativo el cuál es Linux en la distribución ubuntu 7.10, que fue la base del desarrollo para la instalación del IDS Snort, por mencionar algunos de los problemas y factores que afectaron en los tiempos para el desarrollo del trabajo. 3.2.2.1 Equipo (Hardware) Para las pruebas realizadas se necesito de equipo tanto de comunicación, como de transmisión y recepción de datos, el cual fue difícil de obtener, pero se recurrió a la Academia de Computación de la carrera de Ingeniería en Comunicaciones y Electrónica para que el proyecto pudiera realizarse, obteniendo respuesta por parte del jefe de laboratorios de la especialidad de computación, quien contribuyó directamente en el préstamo del equipo necesario para poder llevar acabo el proyecto, el sistema de identificación de intrusos pudo montarse adecuadamente y se comenzó con el monitoreo de la red recibiendo paquetes de datos para efectuar un informe de las amenazas y actividad en la red. 3.2.2.2 Disponibilidad de tiempo De forma paralela se buscó contactar al jefe de la unidad de informática para realizar pruebas de manera simultánea a las pruebas hechas en el nodo del equipo montado en el edificio 4 de la ESIME, pero se tuvieron dificultades en cuanto a la disponibilidad de tiempo, puesto que los horarios designados por el administrador de red no se ajustaban a las actividades escolares de los desarrolladores del proyecto, pero se pudo instalar el IDS

63

Snort en el site del edificio 1, en un puerto de un servidor que se encuentra trabajando en la entrada de red al nodo ESIME Zacatenco con la red institucional del Instituto Politécnico Nacional. 3.2.2.3 Problemas encontrados en la instalación y arranque de Snort La limitante principal que se presentó al instalar Snort en el equipo con la dirección IP siguiente: 148.204.219.120, fue que al descargar de la red los paquetes con la versión 2.8.0.1, no se podía instalar el sistema debido a que la versión más reciente es la 2.8.0.2 con la cual nuestra base de datos era compatible; además de que la configuración del archivo snort.conf no contaba con los permisos del administrador, los cuales se solucionaron al trabajar como usuario root en el sistema operativo. También se instaló la base de datos en MySQL, conectando con el servidor web Apache la interfaz gráfica BASE, pero no se pudieron conectar las tablas de la base de datos con los registros de los archivos de Snort, esto debido a que faltaron algunos plugins que no se encontraron disponibles en la web, por que pertenecían a una versión pasada de Snort. 3.2.2.4 Políticas Escolares Una de las grandes restricciones que se tuvieron complicaciones fue al implantar el IDS en la red, ya que para poder trabajar con nuestra aplicación en el esquema de seguridad de la red institucional de ESIME fue necesario contar con la aprobación del administrador de red el cual ajustó nuestro proyecto a las condiciones y políticas vigentes en la red. 3.3 Topología de Equipo para Pruebas El escenario real para la instalación del IDS Snort, fue montado en un equipo de un cubículo perteneciente a ESIME, el cuál fue facilitado por el Jefe de los Laboratorios de Computación de la carrera de ICE, el Ing. Ignacio Sandoval, en este equipo, el cuál cuenta con una IP fija, se hicieron las pruebas de análisis necesarias, con las cuáles se fue tomando nota de los registros obtenidos. Es de vital importancia tener en cuenta que se hicieron ataques simulados, en primera instancia, debido a que no se contaba con un escenario el cuál arrojara los datos esperados, debido a que la configuración y arquitectura con la que se trabajó no cubría las necesidades de operación del IDS Snort, para detectar las amenazas del tráfico de la Red en ESIME Zacatenco como tal.

64

Switch

IDS Snort

IP Dinámica IP: 148.204.219.120

Equipo para Emular Ataques

Enrutador IP: 148.204.219.99

En la figura 3.2 se puede observar la topología montada para realizar las pruebas con Snort.

Figura 3.2 Topología montada para realizar las pruebas con Snort. 3.3.1 Características mínimas requeridas en del Equipo IDS Dentro de las características del equipo usado para las pruebas y los ataques simulados se emplearon:

CP empleada en pruebas Procesador Pentium (R) 4 CPU 3GHZ

Disco Duro 60 GB

Sistema Operativo Linux, UBUNTU 7.10

Memoria RAM 512 MB

Tabla 3.1 Características del equipo de monitoreo

3.4 Arranque y pruebas del IDS Snort El IDS Snort fue instalado y configurado en un punto de la red para trabajar en tres de sus modalidades de alerta, modo Sniffer, modo de Registro de Paquetes, y el Modo de Detección de Intrusos en Red (NIDS), para monitorear la actividad presente en la red y después analizar a detalle los archivos obtenidos (logs), se realizaron varias pruebas en estos modos para ver el funcionamiento del IDS Snort (Nota: La instalación de Snort se puede ver en el Apéndice A). La primera prueba ha sido activar al IDS Snort en su forma más sencillas (sniffer), para asegurar que existen paquetes circulando por la red, teniendo respuesta en tiempo real con salida en pantalla, sobre la descripción de los paquetes. En el modo de registro de paquetes se activa al IDS Snort con la siguiente línea de comando, desde la Terminal de Linux. root@servicio~desktop:/etc/snort/ # snort -dev -l /var/log/snort -h 148.204.219.120/24

65

Donde con –dev se analizan los paquetes en re, -l asignamos un directorio para los registros en el equipo con IP 148.204.219.120.

Figura 3.3 Paquetes de datos mostrados en pantalla del IDS en modo sniffer

66

Y con esta inicialización el IDS guardó los paquetes en el disco, en base a las reglas predefinidas. También se inicializó al IDS Snort en su modalidad de detección de intrusos en red (NIDS), en la forma completa (full) y rápida (fast), creando los archivos de los registros los cuales se almacenaron en el directorio, /var/log/snort basado sobre la IP del equipo donde se monto el IDS, 148.204.219.120/24.

Se inicializó Snort en modo NIDS completo

Figura 3.4 Inicialización del IDS Snort en modo NIDS completo

67

Figura 3.5 Finalizando al IDS Snort modo NIDS completo

Al finalizar el modo completo se pueden ver algunas estadísticas de los protocolos empleados.

68

Figura 3.6 Estadísticas de protocolos de lo paquetes analizados en modo completo.

69

También se inicializó al IDS Snort en modo NIDS rápido

Figura 3.7 Inicializando al IDS Snort modo NIDS rápido

70

Figura 3.8 Activación de alertas en el IDS Snort modo rápido

Después de accionar al IDS Snort y dejarlo trabajar por cierto periodo de tiempo, este mostró la información de los registros después de insertar la siguiente línea. root@servicio~desktop:/var/log/snort# snort –r snort.log.XXXXXX (XXXXXX, regularmente es la fecha en que se creo el archivo), donde leemos los registros.

71

Figura 3.9 Interpretación de los registros o archivos tipo log 3.4.1 Como interpretar los logs de Snort Los resultados o logs del IDS Snort se almacenaron en el directorio /var/log/snort del disco, y la instrucción para poderlos leer se muestra en la siguiente figura 3.10, ya que estos archivos se encuentran codificados y necesitan un visor de paquetes.

72

Figura 3.10 Interpretación de los registros de Snort mediante el comando –r (lectura).

Con esta modalidad podemos analizar todos los paquetes capturados en cada uno de los monitoreos del IDS Snort, y nos ayudan a conocer el tipo de tramas que circulan por la red. Una vez que se terminan de leer los datos, el comando de lectura o interpretación de registros, presenta una descripción de los protocolos de los paquetes analizados en la red.

73

A continuación se muestran los datos estadísticos de los protocolos que se presentan al finalizar a Snort en el modo NIDS. ====== Snort processed 8 packets.

=============================================================================== Breakdown by protocol (includes rebuilt packets): ETH: 8 (100.000%) ETHdisc: 0 (0.000%) VLAN: 0 (0.000%) IPV6: 0 (0.000%) IP6 EXT: 0 (0.000%) IP6opts: 0 (0.000%) IP6disc: 0 (0.000%) IP4: 8 (100.000%) IP4disc: 0 (0.000%) TCP 6: 0 (0.000%) UDP 6: 0 (0.000%) ICMP6: 0 (0.000%) ICMP-IP: 0 (0.000%) TCP: 0 (0.000%) UDP: 2 (25.000%) ICMP: 4 (50.000%) TCPdisc: 0 (0.000%) UDPdisc: 0 (0.000%) ICMPdis: 0 (0.000%) FRAG: 0 (0.000%) FRAG 6: 0 (0.000%) ARP: 0 (0.000%) EAPOL: 0 (0.000%) ETHLOOP: 0 (0.000%) IPX: 0 (0.000%) OTHER: 2 (25.000%) DISCARD: 0 (0.000%) InvChkSum: 0 (0.000%) Upconvt: 0 (0.000%) Up fail: 0 (0.000%) S5 G 1: 0 (0.000%) S5 G 2: 0 (0.000%) Total: 8

=========================================================================

Dentro de la descripción de los paquetes se encontró información en la red que nos revela que si existen algunos tipos de amenazas o ataques detectados por el IDS Snort, como puede ser solicitudes de otros equipos que pidan información sobre estos equipos de la red.

74

3.5 Descripción de los registros de Snort 3.5.1 Registros en Ambiente de Simulación A continuación se presenta la parte práctica del proyecto, como se muestra en la figura 3.11, se cuenta con un equipo PC, el cuál tiene una IP fija, con dirección 148.204.219.120, se simuló de este modo algunos ataques sencillos y comunes para observar el funcionamiento del IDS Snort, de modo que se consiguió información en los archivos de registros existentes, ficheros que fueron cargados cuando se instaló Snort. 3.5.1.1 Simulación de Ataque tipo Ping Un ataque común es el que a continuación se muestra y para esto se utilizó la herramienta de Símbolo del Sistema, en Windows empleando la utilidad del ping, el cuál utiliza el protocolo ICMP, así tenemos que se considera un ataque debido a la forma de operación del ping, ya que por el formato de la trama, el usuario malicioso pide con la trama una solicitud de respuesta, y el equipo que recibe esta trama acepta la petición, así que el otro espera, hasta que el equipo vulnerable mande la respuesta a la petición. El ping es considerado un ataque porque así se conocen las PC´s activas en una red y el atacante ya puede dirigir procesos más específicos sobre este.

Figura 3.11 Ambiente para Simulación de Ataque tipo Ping A continuación se muestra la trama obtenida de los registros guardados del archivo, con la información de tiempo, equipo y puertos origen y destino, así como la información perteneciente al protocolo ICMP, que es en este caso el que responde al ataque. Es considerada esta acción como ataque debido a que el equipo sospechoso esta pidiendo respuesta ya que si la petición es respondida, este equipo (en este caso con la IP 148.204.219.120) abre ciertos puertos y el otro equipo observará que el equipo esta activo.

Figura 3.12 Trama indicadora de ataque tipo ping

75

Para detectar un ping realizado desde fuera de nuestra red, lo primero que se debe saber es qué tipo de datos intervienen en la cabecera del datagrama IP, en la ICMP y los datos. Para todo esto contamos con un tipo de herramientas llamadas sniffers (olfateadores). La teoría TCP/IP dice que:

• un echo request es de tipo 8 para obtener un echo reply (tipo 0)

• en el campo Protocolo de la cabecera IP debe ir el dato ICMP y poco más recordaremos.

Figura 3.13 Formato de petición y respuesta de eco. Ping echo / echo request.

3.5.1.2 Simulación de Ataque tipo Escaneo de puertos En la siguiente prueba se utilizó una herramienta para redes informáticas, con el fin de obtener información acerca de la disponibilidad de puertos en equipos en Red, como es el analizador de puertos conocido como Nmap, con el cuál se ha trabajado para tratar de descubrir los puertos abiertos del equipo que tiene montado el IDS Snort, desde otro equipo (laptop), que tenga instalado este programa para ver los puertos así como, la disponibilidad de los mismos.

Figura 3.14 Ambiente para Simulación de Ataque tipo Escaneo de puertos

Aquí se tiene la trama obtenida también en los registros con otro tipo de ataque, conocido como escaneo de puertos, para ello el equipo intruso, ocupa una herramienta para redes, que es utilizada por lo general para observar el tráfico presente en un equipo determinado, así se puede ver el tráfico en una IP fija, por ejemplo, que es el caso en particular, para los fines de este trabajo; por lo cuál se utiliza el software de aplicación llamado Nmap, que se observa en la figura 3.15:

76

Figura 3.15 Escaneo de Puertos

Esta acción es considerada como un ataque potencial, debido a que el equipo atacante, tiene acceso a información de los puertos abiertos de este equipo o cualquier otro, y es vulnerable debido a que sabe que aplicaciones se encuentran ejecutando y por cuáles puertos puede acceder en ese momento debido a la información extraída del mismo.

Figura 3.16 Escaneo de Puertos utilizando Nmap Una vez que se ha accedido a los archivos de los registros se puede observar también información respecto a los puertos, con un contador de las reglas de Snort; es decir es observable la frecuencia de utilización o del tráfico de red, a través de los puertos que estén corriendo en las aplicaciones registradas en estos archivos.

77

Figura 3.17 Inicializando las reglas de Snort

3.5.2 Registros obtenidos de Ataques Reales Cuando se quiere acceder a los registros que se tienen para poder verificar la existencia de ataques en nuestro equipo, se debe hacer como súper-usuario (root) desde la consola, como se observa en la figura 3.18, y para observar un archivo en específico se realiza con el comando – r descrito anteriormente dentro del directorio /var/log/snort que es donde se encuentran los archivo tipo log, de este modo se podrá ver el contenido de los registros.

Figura 3.18 Lectura de registro donde se muestran ataques reales

Cuando se revisaron las tramas registradas se obtuvo información valiosa e interesante acerca de distintos tipos de ataques los cuáles serán expuestos a continuación. El primer ataque real arrojado por estos registros el cuál es importante mencionar es un ataque que tiene la siguiente trama de información

78

Figura 3.19 Registro de ataques realizados usando protocolo SNMP 3.5.2.1 Características del protocolo SNMP 161 En este ataque se muestra la intervención del protocolo SNMP (Simple Network Management Protocol) el cual es un protocolo estándar para la administración de red en Internet. Prácticamente todos los sistemas operativos, enrutadores, conmutadores, modems cable o ADSL MODEM, cortafuegos, etc, se ofrecen con el servicio SNMP, existen varias vulnerabilidades con este protocolo ya que definen múltiples tipos de mensajes SNMP que se emplean para petición de información o cambios de configuración, respuestas de las peticiones, enumeración de objetos SNMP y envío de alertas, Estas vulnerabilidades pueden causar problemas de denegación de servicios, interrupciones de servicio e incluso permitir al atacante conseguir acceso sobre el dispositivo afectado. En las dos tramas anteriores, se arrojan datos con información bastante valiosa acerca de la actividad del usuario malicioso, y que en estas se da información, en primera de tiempo, seguida de la dirección y puerto origen, es decir, la información de la dirección IP del usuario atacante y su puerto de utilización, seguido por la dirección IP del destino así como su puerto, o protocolo utilizado, como se puede ver en este ejemplo, hablando concretamente, el usuario, está con dominio, dentro del rango de las direcciones IP, dentro del IPN, en ESIME Zacatenco, y está haciendo un broadcast utilizando SNMP que en este caso tiene el número de puerto 161,( 255.255.255.255:161) como se ve en la trama, con el protocolo de usuario, UDP, así que según la teoría de protocolos de redes, SNMP es un protocolo de gestión y administración de datos, lo que hace este ataque es que como este protocolo pide información cerca del equipo, como dirección IP, puertos, aplicaciones en uso, etc., el atacante tiene acceso a información valiosa con la que puede hacerse conocedor de las vulnerabilidades del equipo atacado, es por eso que lo hace con un broadcast para ver que equipo escucha y responde a este mensaje, o a esta petición de información.

79

En la figura 3.20, se aprecia de manera gráfica como se puede realizar este tipo de ataque.

Figura 3.20 Ataque Realizado a Puertos Utilizando SNMP A continuación se muestra otra trama del mismo registro, también con información no menos valiosa, la cuál es de importancia para los fines de análisis de este proyecto, ya que arroja datos que deben ser analizados pues presentan rasgos poco comunes, y sugiere la idea de un posible ataque.

Figura 3.21 Registro de ataque realizado usando protocolo HIP Este tipo de ataque hace un broadcast, también se observa que utiliza el protocolo asignado por el número 139, el cuál es el protocolo HIP (Host Identified Protocol), esta trama es considerada, importante y por eso se registra, ya que este protocolo como su nombre lo dice es de identificación, por dado motivo puede hacer pensar y sospechar que el usuario no autorizado puede atentar contra la seguridad de este equipo por las autenticaciones del mismo ya que este pudiese tener acceso a esa información dañando esos accesos privilegiados. 3.5.2.2. Características del protocolo 139 (HIP) El puerto 139 emplea los protocolos tcp/ip y tiene popularidad ya que personas ajenas a los equipos en las redes paralizaban a los equipos a través de este puerto.

Switch

IDS Snort

Firewall

Switch

Switch

INTERNET

Atacante

Servidor

80

Mediante este el puerto 139 junto con los puertos 137 y 138, aunque estos últimos bajo el protocolo UDP se puede indicar un puerto para la conexión, y en este caso el puerto a probar es el 139, con la dirección IP 148.204.219.120. 3.6 Propuesta de Implementación de un IDS en la ESIME Zacatenco. La implantación de un Sistema de Detección de Intrusos(IDS), en la Escuela Superior de Ingeniería Mecánica y Eléctrica, Unidad Zacatenco, se llevaría a acabo con la finalidad de resolver varias problemáticas con las que se cuentan actualmente en este centro de estudios, considerando dentro de las medidas necesarias una política de seguridad. Esta política se basará en monitoreos realizados en diferentes puntos estratégicos de la red escolar, en esta política se deben aprobar las principales iniciativas para incrementar la seguridad de la información, proponer las responsabilidades generales en materia de seguridad y promover la difusión y apoyo a la seguridad de la información dentro del organismo. La propuesta de implementación se divide en tres partes:

1º. Monitoreo individual 2º. Monitoreo en conjunto

3º. Monitoreo en base a resultados

Monitoreo individual: En esta opción se pretende monitorear varios puntos en red de manera individual, y es en primera instancia para conocer la actividad en algunos puntos específicos, que son segmentos conflictivos dentro de la red. Monitoreo en conjunto: Esta sería la opción principal, de un monitoreo en red y consta de la instalación de un sistema de detección de intrusos el cual tendrá varios sensores de análisis distribuidos en diferentes puntos o equipos de la red, cuya misión será entregar a un equipo administrador un informe detallado de la actividad presente en dichos puntos, con lo que se tendrá la información del comportamiento general de toda la red y se podrá llevar un registro global de las ocurrencias. Monitoreo en base a resultados: Se realizan modificaciones si son necesarias en la configuración del IDS, cambios de acuerdo a los registros obtenidos, se pueden proponer reglas especiales si se observan continuamente incidencias no deseadas en la red, con lo cuál se busca mejorar la seguridad y desempeño del IDS. La propuesta de la implantación en su etapa de monitoreo individual, plantea dentro de los lugares estratégicos para colocar los sensores, dos sitios principales para ver el comportamiento de la red, el Site de la unidad informática de la ESIME, donde se encuentra la salida hacia la red institucional del instituto y el Site del Edificio 3, donde se encuentra control escolar para vigilar la actividad presente, ya que este punto ha sufrido ataques como la modificación de datos en su pagina principal. Una vez montado este sistema en los puntos clave, se deja trabajar al IDS por ciertos periodo de tiempo, para obtener los registros de lo monitoreado y posteriormente presentar reportes semanales del análisis de los datos presentes en la red.

81

Fibra óptica

Labs. pesados

Servidores Unidad Informática, 2 FTP, MODUL

Site Edif1

Site Edif2

Site Edif 3

Site Edif 4

Site Edif 5

Comunicaciones

Electrotécnia

SEPI

Site Edif 5 3er

IDS Snort

NOTA: Además se recomienda instalar Snort en segmentos conflictivos que se tengan en la escuela.

IDS Snort IDS Snort

Fibra óptica

Servidor Unidad

Informatica,

2 FTP, MODUL

Site Edif1 Site Edif2

Site Edif 3

Site Edif 4

Site Edif 5

Servidor labs. pesados ICA

Servidor comunicacionesServidor Electrotécnia

Servidor SEPI

Figura 3.22 Topología general de la red de ESIME Zacatenco. En la imagen se muestra como esta constituída la red institucional de ESIME Zacatenco, esto nos ayuda a entender mejor donde colocar los sensores, cabe resaltar que dos lugares dentro de la red considerados de riesgo se encuentran; uno en la unidad de Informática y otro en el Edificio 3, ya que en estos puntos existen centros de computo, en los cuales se brinda servicio a Internet y el público en general tiene acceso a la red, y otro punto es en el Edificio 1.

Figura 3.23 Diagrama de la propuesta de implantación del IDS en la red.

82

A continuación se muestran las características de los equipos sensores adecuadas o recomendadas para realizar el monitoreo en los equipos sensores.

PC propuesta para implantación de IDS

Procesador: Intel XEON Doble Núcleo 3040, 2 MB Caché, 1.86 GHz, 1066 MHz FSB Memoria: DIMM 1GB, DDR2, 667 MHz (2x512 MB) Disco Duro: 250 GB SATA., 7200 RPM Tarjeta de Red Ethernet: Gigabit Intel®PRO 1000PF Dispositivo Óptico: Combo de unidad CDRW/DVD IDE 48X Costo: $ 12,000.00 M/N

Tabla 3.2 Características de propuesta para equipo de monitoreo

Una etapa para mejorar aún más la red escolar, es programar ciertas tareas en nuestro IDS Snort, para que al cumplir con ciertos parámetros obtenidos de los paquetes de red, efectúe algunas actividades de seguridad informática. En el archivo snort.conf ubicado /etc/snort se le indica a la aplicación que acepte conexiones del sistema donde se ejecuta. Con estas medidas podemos asegurar que la estabilidad de la red mejorará considerablemente y se podrán atacar diferentes anomalías que se llegaran a suscitar en torno a la red de la ESIME Zacatenco e identificar el origen de los ataques.

83

CONCLUSIONES Con el presente trabajo de investigación utilizando un software en código abierto; se obtuvieron avances sustanciales en el conocimiento acera del funcionamiento del IDS Snort, como un sistema que detecta acciones de usuarios maliciosos, debido a los reportes obtenidos, donde se observó la manera en como lanza los registros para lo cuál se deja una propuesta para que se pueda implementar en la ESIME Zacatenco El monitorear, encontrar y analizar ataques en una red de datos nos permite poder diseñar una red más segura con herramientas como son Firewall, Listas de Control de Acceso, Políticas para usuarios y empleados además de poder mejorar configuraciones en equipos de comunicación y servidores Las herramientas de software libre, nos permiten la implementación de una gran cantidad de servicios sin necesidad de pagar licencias pero se recomienda siempre dimensionar correctamente el equipo de computo donde se implementaran estas soluciones basándonos en la cantidad de usuarios y servicios que se vayan a implementar. El software libre también nos permite ahorros significativos al no tener que pagar licencias a fabricantes, que en el caso de fabricantes de IDS sus costos son hasta de cientos de miles de pesos.

84

BIBLIOGRAFÍA [1] CHESWICK William R. Bellovin Stephen M. 1995. FIREWALLS AND INTERNET

SECURITY. REPELLING THE WILY HACKER. Addison-Wesley Publishing Company.

[2] MOLINA Robles Francisco José. 2005. INSTALACIÓN Y MANTENIMIENTO DE

SERVICIOS DE REDES LOCALES. Alfaomega grupo editor, S.A. de C.V. México. [3] MOLINA Robles Francisco José. 2004. SEGURIDAD EN REDES INFORMÁTICAS.

Capítulo 11. REDES DE ÁREA LOCAL. Alfaomega grupo editor, S.A. de C.V. México.

[4] PTACEK T. Newman T. INSERTION, EVASIÓN AND DENIAL OF SERVICE:

ELUDING NETWORK INTRUSIÓN DETECTION. http://www.snort.org/docs/. [5] RAYA Cabrera José Luis. Raya López Elena. 2005. REDES LOCALES. 3ª Edición.

Alfaomega grupo editor, S.A. de C.V. México. [6] RICH Amy (Sun). ANALYZING SNORT DATA WITH THE BASIC ANALYSIS AND

SECURITY ENGINE (BASE). http://www.snort.org/docs/. [7] ROESCH Martin. Green Chris. Sourcefire, Inc. 2008. SNORTUSERS MANUAL 2.3.3

THE SNORT PROJECT. http://www.snort.org/docs/snort_manual/snort_manual.html

[8] VACCA John R. 1997. INTERNET SECURITY SECRETS. (Los Secretos de la

Seguridad en Internet). Ediciones Anaya Multimedia. Madrid, España. [9] VOSSEN J.P. SNORT TECHNICAL GUIDE. Disponible en http://www.snort.org/docs/. http://www.enterasys.com/products/ http://www.cisco.com/ http://www.stonesoft.com http://howtoforge.com/intrusion-detection-with-snort-mysql-apache2-on-ubuntu-7.10-updated http://es.wikipedia.org/wiki/ http://www.idg.es/Comunicaciones/articulo.asp?id=184258

APENDICES

I

APÉNDICE A Sistema de Monitoreo y Detección De Intrusos en Servidores Linux Manual de Instalación � Requerimientos En este manual se describirá cómo instalar y configurar Snort (un sistema de detección de intrusos (IDS), BASE (Básica y Análisis de Seguridad del motor) que es la interfaz grafica del software, MySQL (como la base de datos donde se almacenara la información registrada) y APACHE 2 (como servidor web de la aplicación) sobre Ubuntu 7.10 (Gutsy Gibbon).

A. Obtener privilegios de root

Primero hay que accesar como usuario raíz.

sudo su –

B. Instalación de los paquetes necesarios

La siguiente instrucción instalará todos los paquetes requeridos para hacer la configuración del sistema:

apt-get install libpcap0.8-dev libmysqlclient15-dev mysql-client-5.0 mysql-server-5.0 bison flex apache2 libapache2-mod-php5 php5-gd php5-mysql libphp-adodb php-pear libc6-dev g++ gcc pcregrep libpcre3-dev Apt-get install libmysqlclient15-dev libpcap0.8-dev mysql-5,0-cliente-servidor mysql-5,0 bison flex apache2 libapache2-mod-php5 php5-gd php5-mysql libphp-adodb php-pera libc6-dev g + + gcc pcregrep libpcre3 – Dev

C. Obtener y compilar snort

Una vez obtenida la versión mas actual de Snort lo único que vamos a compilar desde cero.

La última versión de Snort en el momento de la escritura es 2.8.0.2.

En primer lugar vamos a ir a un directorio de trabajo:

cd /usr/src/ Cd / usr / src /

C.1 Descargar Snort y las Normas de Snort

1.-wget http://www.snort.org/dl/current/snort-2.8.0.2.tar.gz

Hay un par de opciones para reglas. Las siguientes instrucciones descargaran las normas públicas, sin embargo con un registro rápido en el sitio de Snort se pueden obtener más normas actuales.

2.-wget http://snort.org/pub-bin/downloads.cgi/Download/vrt_pr/snortrules-pr-2.4.tar.gz

II

C.2 Estas instrucciones son para Desempaquetar y conseguir compilar las normas de snort:

1.-tar zxvf snort-2.8.0.1.tar.gz Tar zxvf snort-2.8.0.1.tar.gz 2.-cd snort-2.8.0.1 CD snort-2.8.0.1 3.-tar zxvf ../snortrules-pr-2.4.tar.gz Tar zxvf ../snortrules-pr-2.4.tar.gz

C.3 Ahora vamos a compilar y activar el conector dinámico con mysql:

1.-./configure -enable-dynamicplugin --with-mysql 2.-make 3.-make install C.3.1 Si lo que queremos es desactivar nuestro conector bastara con la siguiente instrucción:

Make uninstall

C.4 Ahora vamos a re direccionar los directorios de las normas a Snort

Tenemos que pasar las normas y de configuración de snort en su posición

1.-mkdir /etc/snort /etc/snort/rules /var/log/snort 2.-cd /usr/src/snort-2.8.0.2/etc 3.-cp * /etc/snort/ 4.-cd ../rules 5.-cp * /etc/snort/rules

D. Configuración del Snort

Tenemos que modificar el archivo snort.conf.

Para eso tenemos que abrir el siguiente archivo / etc / snort / snort.conf con cualquier editor de texto (nano, vi, vim, etc.).

De este modo se tiene el acceso al archivo.

1.- vi /etc/snort/snort.conf

2.- Se Cambio "var HOME_NET xxx.xxx.xxx.xxx" a "var HOME_NET 148.204.219.120/24" (la red en nuestro caso la IP del Instituto 148.204.219.120). 3.-Cambiamos "var EXTERNAL_NET cualquier" a "var EXTERNAL_NET! $ HOME_NET" 4.-Cambiamos "var RULE_PATE .. / normas" a "var RULE_PATH / etc / snort / rules"

Ahora tenemos que recorrer la lista hasta la sección " # output database: log, mysql, user= ".

5.-Nota: eliminar el "#" de que aparece al principio de esta línea.

6.-Cambie el "user = root " a "user = snort", cambiar el "password = password"

III

por "password = snort_password", "dbname = snort".

Es necesario que tome nota del nombre de usuario, contraseña y dbname. Ya que se necesitara esta información cuando se creó la base de datos Mysql. Para guardar y salir se utilizan los comandos del formato Vi (:wq).

Cambiar los permisos sobre el archivo de configuración para mantener las cosas seguras:

7.- chmod 600 /etc/snort/snort.conf

E. Configuración de la base de datos Mysql.

Ingrese al servidor mysql con la siguiente instrucción.

1.-mysql -u root -p

Crear la base de datos de snort. Importante haber cambiado el 'snort_password' a otra cosa.

2.-create database snort;

Ahora tenemos que conceder todos los privilegios sobre el snort con la siguiente instrucción.

3.-grant all privileges on snort.* to 'snort'@'localhost' identified by 'snort_password';

Salimos de la configuración de la base de datos:

4.-exit

Vamos a utilizar el esquema de snort para el diseño de la base de datos.

5. - -D snort -u snort -p < /usr/src/snort-2.8.0.1/schemas/create_mysql

Nota: Solo necesita la contraseña que asigno antes de Continuar.

F. Probar el Snort

En el modo de terminal se tiene que ejecutar el siguiente comando:

1. - snort -c /etc/snort/snort.conf # Snort-c / etc / snort / snort.conf

Si todo ha salido bien al final de la pantalla que aparece se deberá ver un cerdo dibujado en código ASCII.

Para cerrar la ventana de verificación utilice el comando ctrl+c.

G. Obtener e instalar el Archivo BASE

Abra un navegador Web y vaya a la siguiente liga:

IV

http://sourceforge.net/project/showfiles.php?group_id=103348.

Después haga click en el link descarga que aparece a la derecha, haga clic en el paquete mas reciente con extensión tar.gz.

En el tipo de terminal:

1.-cd 2.-wget http://easynews.dl.sourceforge.net/sourceforge/secureideas/base-1.3.9.tar.gz

Ahora tenemos que ir a la raíz de su del documento web BASE que se descargo en el link anterior (por defecto éste es / var / www), desempaquetarlo y establecer los permisos necesarios para configurar BASE:

1.-cd /var/www/ 2.-tar zxvf ~/base-1.3.9.tar.gz 3.-cd .. 4.-chmod 757 base-1.3.9

Queremos asegurarnos de que un par de módulos de Pear se active: 5.-pear install Image_Color 6.-pear install Image_Canvas-alpha 7.-pear install Image_Graph-alpha

• H. Set up BASE Establecer BASE

Open a web browser and navigate to http://YOUR.IP.ADDRESS/base-1.3.9/setup .

Abra un navegador web y navegar a http://YOUR.IP.ADDRESS/base-1.3.9/setup.

Haga clic en continuar en la primera página.

� Paso 1 de 5: Introduzca la ruta de acceso a ADODB. Esto es / usr / share / php / adodb.

� Paso 2 de 5: Database type = MySQL , Database name = snort , Database Host = localhost , Database username = snort , Database Password = snort_password

� Paso 3 de 5: Si desea utilizar la autentificación de introducir un nombre de usuario y contraseña y marcar la casilla.

� Paso 4 de 5: Haga clic en Crear BASE AG. � Paso 5 de 5: Paso 5 de 5: una vez que se realiza el paso 4 en la parte inferior

haga clic en Ahora continúe con el paso 5.

Guardar esta página.

Cambiar los permisos de vuelta en la / var/www/base-1.3.9 carpeta.

# chmod 755 /var/www/base-1.3.9 # Chmod 755 / var/www/base-1.3.9

V

APÉNDICE B Manual de Reglas en Snort Las reglas de Snort se pueden crear a mano o descargarlas de internet. Para casos específicos se pueden forjar a medida, pero en el caso de querer utilizar Snort para la detección general de intrusiones, existe básicamente el sitio en internet donde se descargan ficheros muy completos para detectar tráfico indeseable. - www.snort.org, la página oficial del programa, que incluye un conjunto de reglas bastante completo.

El lenguaje usado por Snort es flexible y potente, basado en una serie de normas que serán las que nos sirvan de guía para la escritura de las reglas.

Dentro de estas normas tenemos:

• Descripción de cada regla. • Cabecera. • Opciones. • Uso de preprocesadores.

Las reglas Snort (Snort Rules) deben ser escritas en una sola línea, de lo contrario habrá que usar el carácter de escape (\):

alert tcp any 110 -> (content: "filename=\"TOMOFONICA.TXT.vbs\"";\ nocase; msg: "Virus tomofonica";)

Las reglas de Snort las podemos dividir en dos secciones lógicas, a saber: cabecera de la regla y opciones:

• La cabecera contiene la acción de la regla en sí, protocolo, IPs, máscaras de red, puertos origen y destino y destino del paquete o dirección de la operación.

• La sección opciones contiene los mensajes y la información necesaria para la decisión a tomar por parte de la alerta en forma de opciones.

Las reglas Snort las dividiremos de la siguiente manera:

CABECERA

• Acción

• Protocolos involucrados

• Direcciones IP

• Números de puerto

• Dirección de la operación

OPCIONES

• Mensaje

• Opciones de decisión

EJEMPLO 1

Veamos ahora un ejemplo de regla Snort para alertar de un escaneo nmap del tipo

TCP ping:

alert tcp $EXTERNAL_NET any -> $HOME_NET any / (msg:"Escaneo ping

VI

con nmap";flags:A;ack:0; / reference:arachnids,28;classtype:attempted-recon; sid:628;/ rev:1;)

Analicemos esta alerta:

CABECERA

• Acción de la regla: alert

• Protocolo: tcp

• Direccion IP origen: $EXTERNAL_NET (toda la red)

• Puerto IP origen: any (cualquiera)

• Direccion IP destino: $HOME_NET (toda nuestra red)

• Puerto IP destino: any (cualquiera)

• Dirección de la operación: -> (puede ser ->, <-, <>)

OPCIONES

• Mensaje: msg

• Opciones: flags:A;ack:0; reference:arachnids..(1)

Datos especificos del ejemplo:

• flags: A Establece el contenido de los flags o banderas TCP, en este caso ACK (puede tener varios valores y operadores).

• ack: 0 Caso particular para valor ACK=0, es el valor que pone nmap para TCP ping scan.

• reference: arachnids,28 Referencia un a un Advisory, alerta tipo Bugtrac, etc.

• classtype: attempted-recon Categoría de la alerta según unos niveles predefinidos y prioridades.

• sid: 628 Identificación única para esta regla Snort según unos tramos determinados.

• rev: 1 Identificación de la revisión o versión de la regla.

EJEMPLO 2

En el manual oficial de Snort como primer ejemplo tenemos:

alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";)

Acceso al demonio de administración mountd de LINUX, el cual tiene tiene diversos problemas de desbordamiento de memoria intermedia, que permiten a un atacante remoto obtener privilegios de administrador en los sistemas vulnerables.

Dos consideraciones:

1. El orden de la sección opciones. Primero las opciones y después el mensaje. El orden, pues, es indiferente.

VII

2. La opción 'content'. Es una de las opciones más importantes ya que nos permite la búsqueda de contenidos dentro del campo datos del paquete IP. Se puede añadir 'nocase' para que la búsqueda de los datos no sea sensible a las mayúsculas. Estos datos pueden estar en formato hexadecimal, texto plano o binario.

Podemos jerarquizar las reglas usando los includes. Estos includes nos permiten crear reglas dentro de otras. El formato sería:

include

Uso de variables en las reglas.

Podemos usar variables (lo hemos visto en el ejemplo anterior). Estas variables se definen en el archivo etc/snort.conf .

El formato de las variables sería:

var

Por ejemplo:

var MY_NET [102.168.1.0/24]

Con lo cual una regla usando variables quedaría de la siguiente forma:

alert tcp any any -> $MY_NET any (flags: S; msg "SYN Packet";

Otras variables que podemos definir puede ser la red externa o EXTERNAL_NET o la ubicación de un servidor Oracle, servidor SQL,etc.

Es decir, usaremos las variables para la mejor configuración de los valores de nuestra red.

Cabecera de las reglas.

Acciones.

Hemos vistos que la primera parte de la cabecera es la acción de la regla. La acción de la regla indica a Snort que debe hacer cuando detecte un paquete que coincida con el criterio de la regla. Las acciones pueden ser:

• alert genera una alerta usando el método de alerta selecciona y almacena el log.

• log archiva el log del paquete • pass ignora el paquete • activate activa la alerta y llama a una regla dinámica • dynamic cuando es llamada por una regla activate se pone en funcionamiento

Algunos ejemplos:

pass tcp any any -> $HOME_NET any (msg:"all traffic";)

pass ip 10.x.x.0/22 any -> any any (content: "Open Port * 80"; msg: \ "Open Port 80."; )

alert tcp any 110 -> (content: "filename=\"TOMOFONICA.TXT.vbs\""; \ nocase; msg: "Virus tomofonica";)

B.1 Lo Básico. La mayoría de las reglas de Snort están escritas en una línea simple. Esto fue requerido en versiones anteriores. En las versiones actuales de Snort, las reglas pueden expandirse en muchas líneas agregando una diagonal invertida al final de la línea.

VIII

Las reglas de Snort están divididas en dos secciones lógicas, la cabecera de la regla y las opciones de la regla. La cabecera de la regla contiene la acción de la regla, el protocolo, la dirección IP de destino, fuente y las mascaras de la red, y la información de los puertos fuente y destino. La sección. La sección de opciones de la regla contiene los mensajes de alerta y la información en que las partes del paquete deben ser inspeccionadas para determinar si la acción de la regla deberá ser tomada en cuenta. La figura B.1 ilustra un ejemplo de la regla de Snort.

Alert tcp any any ------122.168.1.0/64 111 content: “1000186 a si “; Msg: “mountd access”,

Figura B.1 Ejemplo de la regla

El texto de hasta el primer paréntesis es la regla principal y la sección encerrada en el paréntesis es la regla opcional. Las palabras antes de los dos puntos en la regla de opciones de sección son llamadas palabras llave. Obsérvese que la regla de sección de opción no específicamente requerida por cualquier regla, ellos son usados solo para evitar definiciones mas apretadas de paquetes para recoger o alertar (o caída para la materia). El total de los elementos en que esta maquilla una regla debe ser verdadero para la regla de acción indicada para ser aplicada cuando se toman juntas los elementos pueden ser considerados desde una posición lógica a si al mismo tiempo las diversas reglas en el archivo de la biblioteca puede ser considerada desde una gran lógica o status. B.1.1 CONTENIDOS La conclusión de palabras clave permite otros archivos de reglas para ser incluidos con las reglas de archivos indicadas sobre el comando en línea. Muchos trabajos pueden ser incluidos desde el lenguaje de programación C. leyenda los contenidos de archivos nombrado y poniendo ellos en posición en el archivo en el sitio donde es incluido. B.1.2 FORMATO

Include:<include file path/name>

Figura B.2 Ejemplo de formato de include

Observe esto donde no es punto y coma y el final de valor esta línea. Incluyo archivo sustituirán alguna variable predefinida dentro de sus propias variables de referencia. Vea la sección de variables para más información definición y uso de variables en aditivos de reglas de Snort. B.1.3 Variables Las variables pueden ser definidas en Snort. Esto es una simple sustitución de variables fijados con las palabras clave como la figura B.3

IX

B.1.3.1 Formato

Var:<name><valve> Var my_net ( 192.168.1.0/24,10.1.1.0/24 )

Alert psp amy =>$may-net any(flacs:s.,msg:”syn packet”.,)

Figura B.3 Ejemplo de una variable definida y usada. Los nombres de reglas de variables pueden ser modificadas en varias formas. Usted puede definir las variables –meta usando en $ operador. Estos pueden ser usados con los operadores madificadores de variable, ¿ y-* var definir la variable metas * $ (var-default)- remplace con el contenido de la variable var o con default si la variable es indefinida *$ (var?message)-sustituye el contenido de variable var o imprime el error message message y salida. Ver figura B.4 por ejemplo de esas reglas modificadoras en acción .

Var MY_NET 192.168.1.0/24 Log tcp any any -> $MY_NET23

Figura B.4 figura variable avanzada usada de ejemplo.

B.1.4 CONFIGURACIÓN Configuración y líneas comando opciones de Snort pueden ser especificadas en el archivo de configuración.

Config<directive>(:<valde>)

Figura B.5 Configuración B.1.5 DIRECTIVAS

- Orden

Cambio de orden de paso o reglas ( snort-o) - Alertfile

Establecer el archivo del arma de salida. Ejem: config: alerts

- Classification

Construir clasificacion de reglas (vertabla2.2)

- Decode_arp

Activar decodificador arp( snort_a)

- dump chars_only

activar monton de caracteres (snort_c)

- dump_play load

aplicación de monton capa(snort_d)

- decode_data_link

DECONIFICAR layer 2 punteros(snort-e)

- bpf-file

especificar filtros BPF (snort-F) Ejemplo: config bpf.file filename.bpf.

- set_gid

cambiar para este gid (snort-g) ejemplo. Config setgid:sbortgroup

- daemon

bifurcar como un demonio (snort-D)

- refernce_net

X

establece una red casera (snort-h) ejemplo confireference_net192.166.1.0/24

- interface

establece un interface de (snort-i):ejemplo:configinterface:X10

- alert_with-interface_name

añade un nombre de interface para alarma (snort-1)

- logdir

establece el logdir (snort-1) eljemplo: confg logdir:/car un mask

- umask cuando corre (snort-m) ejemplo: conf umask : u 22

- pkt. Count

sale despues N paquetes (snort-n) ejemplo: config pkt count:13

- n log

incapacitads logging: nota avisa cuando un paro ocurre (snort-n)

- obfuscate

ofuscatcion ip dirigido (snort-o)

no _ promisc

- modo promiscuo descapacitado (snort-p)

- quiet

incapacitar bandera y reporte de staTUS (Snort-q)

- Cheksum.mode

Tipos de paquetes para calcular checksums. Valores; nonr, noip, noicmp,

noudp ald

- Utc

Use utc en lugar del tiempo local para timesteam (snort-u)

- Verbose

Use verbose logging para stod out (snort-r)

- Domp_:playout_verbase

Monton raiz paquete iniciado con eslabon capa (snort-x)

- Show_year

Muestra año en tiempo marcado (snort-4)

- Stateful

Establecer modo de aseguramiento para flujo4(est) ver tambien tabla 4

- Min-tti

Establece un snmort ancho minimo tti para ignorar todo el trafico

- Disable_decode_alerts

Arranca las alarnas generadas por el decodificador de fase de snort

- Disable_tcpopt_experimental_alerts

Prende las alarma generadas por las opciones tcp experimental

- Disable _tcpopt_obsolete_alerts

Prende alarmas generadas por opciones TCP.

- Disable _tcpopt_ttcp_alerts

Validacion de alarmas opcion cognositivo incapacitada

- Discable_ipopt_alerts

Validacion de alarmasd ancapasitada ip opcion larga

- Dectetion

Configura la maquina de detección (ejemplo: sear-method lowmesn)

- Reference

Añadir un nuevo sistema de referencia para snort

XI

B.1.6 Reglas de puntero B.1.6.1 Acciones de reglas La regla de cabeceros contiene la información define el quien, donde y que un paquete, y bien lo que para hacer en el evento que un evento que un paquete con todos los atributos indicados en la regla debe ser mostrada. El primer articulo en la regla de acción. La regla de acción llamada Snort que puede ser cuando esto termina un paquete que comprende el criterio de la regla. Estos son 5 acciones adecuadas por default en snort alerta, log, pass, activar y dinámica.

1. Alert- genera una alerta usando métodos de selección de alarma y cuando el

paquete log

2. El paquete log-log

3. Pass- ignora el paquete

4. Activate- alarma y entonces arranca sobre otra regla dinámica

5. Dynamic- permanece ocioso hasta activar por la regla activada, entonces

actúa como una regla log.

Usted también define su propio tipo de regla y asocia uno o más conexiones con ellos. Usted puede usar los tipos de regla como acciones en reglas Snort. Estos ejemplos operan un tipo que será log para :CPDUMP. RULETYPE SUSPICIUS TYPE LOG OUTPUT LOG_TCPDUMP: SUSPICIUS.LOG. ESTE EJEMPLO CREARA UN TIPO DE REGLA LOG PARA SYSLOG Y UN MYSQL DATABASE

RULETYPE REBALERT TYPEALERT OUTPUT

ALERT_SYSLOG: LOG_AUTH LOG_ALERT OUTPUT DATABASE: LOG, MYSQT, USER=SNORT DBNAME=SNORT

HOST=LOCALHORST

Figura B.6 Ejemplo de un tipo de regla log para un archivo syslog B.1.7 Protocolos EL SIGUIENTE CAMPO EN UNA REGLA ES EL PROTOCOLO. Estos son cuatro protocolos que Snort normalmente analiza por comportamiento suspicaz_tcp, udp, icmp, e ip. En el futuro donde puede mas tales como ARP, IGRP, GRE, OSPF, RYP, IPX etc. B.1.8 IP DIRECCIONES La siguiente porción de la regla principal negocia con dirección IP y porta información para una regla dada, alguna palabra clave puede ser usada para definir alguna dirección. Snort no tiene un mecanismo para proporcionar la vista del nombre del huésped para los campos de la dirección IP en el archivo de reglas el direccionamiento es formado por un numero recto a dirección IP y CIDR BLOCK. El CIDR BLOCK indica la mascara NET que debe ser aplicada para las direcciones de las reglas introduciendo paquetes que son probados contra la regla. Un CIRD MASCARA DE/24 indica una clase C red/16 a clase B red, 4/32 indica una dirección de maquina. Por

XII

ejemplo la dirección diagonal CIRD combinación 192.168.1.1 a 192.168.1.225 alguna regla usada esta designación para decir la dirección destino deberá conectar en alguna dirección en el rango. Las designaciones CIRD nos dan una forma para designar una larga dirección de espacio de los caracteres de espacios insuficientes. En la figura B.6 las fuentes de la dirección IP fue establecida para arrancar hablando con una computadora, y la dirección fue establecida para conectar en el 192.168.1.0 clase C NET WORK. Aquí es donde un operador puede aplicar la dirección IP la negación del operador. El operado llama a SNORT a iniciar alguna dirección IP excepto la indicada por lista de direcciones IP. La negativa de operador es indicada con un a! por ejemplo, una fácil modificación en el ejemplo inicial es para hacer una alarma en algún tráfico de salidas originales de la red local con la negación del operador como se muestra en la figura B.6.

ALERT TCP !192.168.1.0/24 ANY->192.168.1.0/24 111 (content: “ I 00 01 86 a 51”; msg: “external mountd access”;)

Figura B.7 Ejemplo de dirección IP negación de regla.

Estas direcciones de las reglas IP indicadas algún paquete con una fuente de direcciones no originadas desde la red interna y dirección sobre la red interna. Usted puede también especificar listas de direcciones IP. Una lista IP es especificada, encerrada, y separada por comas lista de direcciones IP y bloques con paréntesis cuadrados. Para el comienzo la lista de IP puede no incluir espacio entre las dirección. Ver figura B.7. Por ejemplo de una lista en acción.

ALERT TCP!(192.168.1.0/24) 10.1.1. ANY -> (192.168.1.0/24,10.1.1.0/24) 111 (conteniendo:” I 00018625 I”;)

Msk:”external mountd access”;)

Figura B.8 IP Dirección lista. B.2 NUMEROS DE PUERTO Los números de Puerto pueden ser especificados en un numero de maneras, incluyendo, algunos puertos definiciones de Puerto estático es indicado por un simple numero de Puerto tal como 111 para Puerto mapa .23 para TELNET, 0 80 para HTTP, etc. Rango de puerto son indicados con operador de rango el rango del operador puede ser aplicado en un numero de formas para tomar un significado diferente, como el de la figura B.8

LOG UDP ANY ANY-> 192.168.1.0/24 I: 1024 LOG UDP. El tráfico viene de algún Puerto

y puertos de destino recorriendo desde 1 a 1024

LOG TCP ANY: 1024->192.168.1.0/24 500:

LOA TCP TRAFIC desde puertos privilegiados menor o igual a 1024 Yendo a puertos mayores o iguales a 500

Figura B.9 Ejemplos de rangos de puertos

XIII

APÉNDICE C Reporte semanal obtenido de IDS Dragon Enterasys

XIV

APÉNDICE D Revista electrónica en normas ISO 9000-2000

XV

XVI

XVII

XVIII

APÉNDICE E

Propuesta Económica

Al ser este trabajo un proyecto de solución; en este apartado se hace una propuesta económica de los costos necesarios para la implantación del IDS Snort, en la Red de ESIME Zacatenco. La implantación del IDS Snort resulta ser más económico que los IDS comerciales que actualmente están en el mercado ya que sus licencias son libres en la comunidad de Linux. Equipo Necesario para la Implantación del Sistema A continuación se muestran las tablas con las características de los equipos en los que se propone la instalación del IDS para un funcionamiento óptimo utilizando los requerimientos mínimos. Procesador: Intel XEON Doble Núcleo 3040, 2 MB Caché, 1.86 GHz, 1066 MHz FSB Memoria: DIMM 1GB, DDR2, 667 MHz (2x512 MB)

Disco Duro: 250 GB SATA., 7200 RPM Tarjeta de Red Ethernet: Gigabit Intel®PRO 1000PF Dispositivo Óptico: Combo de unidad CDRW/DVD IDE 48X

Costo: $ 12,000.00 M/N

Tabla E.1 Equipo de monitoreo 1

Procesador: Intel XEON Doble Núcleo 3040, 2 MB Caché, 1.86 GHz, 1066 MHz FSB Memoria: DIMM 1GB, DDR2, 667 MHz (2x512 MB)

Disco Duro: 250 GB SATA., 7200 RPM Tarjeta de Red Ethernet: Gigabit Intel®PRO 1000PF

Dispositivo Óptico: Combo de unidad CDRW/DVD IDE 48X Costo: $ 12,000.00 M/N

Tabla E.2 Equipo de monitoreo

Procesador: Intel XEON Doble Núcleo 3040, 2 MB Caché, 1.86 GHz, 1066 MHz FSB

Memoria: DIMM 1GB, DDR2, 667 MHz (2x512 MB) Disco Duro: 250 GB SATA., 7200 RPM

Tarjeta de Red Ethernet: Gigabit Intel®PRO 1000PF Dispositivo Óptico: Combo de unidad CDRW/DVD IDE 48X Costo: $ 12,000.00 M/N

Tabla E.3 Equipo de monitoreo 3

Según las tablas anteriores, tenemos las características del equipo que se propone para implantar el IDS Snort, con las mínimas cualidades que requiere el sistema para un funcionamiento adecuado, de esta forma damos una referencia técnica específica de las herramientas que se necesitan para una operación correcta del mismo sistema, asegurando con esto que pueda trabajar sin dificultades con un buen desempeño, minimizando costes y maximizando aprovechamiento de rendimiento.

XIX

Nota: Además, se investigó sobre los requerimientos de hardware de estos IDS comerciales, para justificar lo anteriormente mencionado se muestra una tabla con las características del equipo de la marca Enterasys del Sensor de Red Dragon Appliance. A continuación se muestran los costos de los requerimientos del sistema. El costo del Proyecto se calcula en función del hardware, del software y de la investigación realizada. De modo que el costo final está dado por: Costo Total del Proyecto = Costo de Hardware + Costo Investigación A su vez el costo del Hardware se divide en los elementos o dispositivos de comunicación y transmisión de datos. Hardware = Componentes electrónicos (servidores) Investigación = Software + Tiempo de configuración e instalación (10) + capacitación (5) I = 0 + 10,000 + 5,000 Se calculó el costo del software, en el cual gracias a la utilización de software libre reduce considerablemente el costo total del proyecto. En la tabla C se muestra el análisis del Costo del Proyecto.

Costo total del Proyecto

Costo Hardware $ 36,000.00

Investigación $ 15,000.00

Total $ 51,000.00

Tabla E.4 Costo total del Proyecto

En el presente proyecto se consideraron las siguientes variables para estimar el costo de una falla producida por ataques, virus, software malicioso, entre otros, que pueden generar un gasto adicional, o que causan pérdidas económicas: Tipo de gastos costo/hora Gastos por uso de energía eléctrica 150 Análisis para detección del error o falla 100 Compra de software (antivirus) 2500 Soporte técnico 1500 Consultoría 1000 Reposición de equipo dañado 100 Pago de horas extras a usuarios 50 Perdidas de información confidencial 500

Costo promedio por falla = n

Tipo∑

Con los datos anteriores se puede hacer la estimación promedio del costo de una falla en redes informáticas y si se suponen los tipos de consecuencias por no tener un sistema adecuado de información, el costo aproximado por falla es de $737.50, y si se tiene una cantidad determinada de anomalías en la red, la recuperación de la inversión

XX

del proyecto se dará aproximadamente después de 69.anomalías detectadas; dado que nuestro proyecto tiene un costo total de $51,000.00, entre el costo de la falla, obtenemos el resultado anterior.

XXI

APÉNDICE F Simplificación del Sistema Operativo Linux. Configuración del kernel, utilización de servicios mínimos para snort. El núcleo del Sistema Operativo o también llamado kernel, es la parte sustancial del mismo, ya que en el se encuentran las instrucciones mínimas para que el sistema funcione, el kernel no es mas que un programa con instrucciones que en la mayoría de las veces esta desarrollado en lenguaje c y algunos sectores en lenguaje ensamblador que varia dependiendo del hardware o arquitectura de cada equipo. Entre las funciones más importantes del núcleo de Linux tenemos son:

-Administrar la memoria del computador -Establecer la comunicación entre las aplicaciones y los dispositivos de hardware -Administrar los procesos

El kernel recibe grandes cantidades de actualizaciones en muy poco tiempo, comúnmente estas contienen nuevos módulos, mejoras de seguridad, mejor administración de recursos, adaptaciones a los nuevos dispositivos, etc. Existen varias versiones del kernel ya que con el tiempo aparecen mejoras en los programas para implementarse en equipos más actuales. Solamente se compila cuando tenemos dispositivos de hardware muy nuevos y nos veamos forzados a migrar a un kernel que incluya los módulos con soporte para estos. Otra razón para compilar una nueva versión es que poseemos uno muy viejo y optamos por la disyuntiva de actualizarlo para poseer mejoras con la administración de memoria. Para los fines del presente proyecto de tesis, se analizó la versión de kernel que posee la distribución de Ubuntu 7.10 con la que se trabajó para instalar el IDS Snort, y se encontró el la carpeta /boot que ahi se encuentran los archivos de nuestro kernel con la versión número 2.6.22-14-generic, además, cabe mencionar que se utilizó el shell bash, para interactuar con dicha versión, que se encuentra en la carpeta etc/bin/bash (en esta parte accedemos como superusuario, root). Este número de versión de kernel de Linux, es la versión más actual, por este motivo no es necesario el tener que recompilar el kernel para linux, ya que la versión anterior es la 2.4.X.

F.1 Secuencia de arranque del sistema Ubuntu F.1.1 Descripción general de la secuencia de arranque (boot-scripts) La secuencia de arranque varía de un sistema a otro pero se puede dividir básicamente en los siguientes pasos:

i. Arranque del hardware. ii. Cargar el SO. iii. Puesta en marcha del núcleo. iv. Init e Inittab. v. Scripts de arranque.

XXII

A continuación de describirá cada uno de estos pasos con más detalle. F.1.2 Arranque del hardware Después de pulsar el botón de encendido o el botón reset, se pasa el control a un programa almacenado en memoria de sólo lectura (normalmente PROM). En los PC a este programa se le denomina BIOS. Este programa normalmente hace una comprobación básica de la máquina y accede a memoria no volátil para leer parámetros adicionales. En el PC, esta memoria es CMOS con respaldo de batería, por lo que la mayoría de la gente se refiere a ella como CMOS, aunque fuera del mundo del PC se le llama usualmente nvram (non-volatile ram, RAM no volátil). Los parámetros almacenados en la memoria nvram varían entre sistemas, pero como mínimo el programa de arranque debe saber cuál es el dispositivo de arranque, o qué dispositivos probar como posibles dispositivos de arranque. Después se accede al dispositivo de arranque, se trae a memoria el cargador del S0, que está localizado en una posición fija de este dispositivo y se le transfiere el control a éste. F.1.3 Cargar el S0 En los PC, el cargador del SO está localizado en el primer sector del dispositivo de arranque - es el llamado MBR (Master Boot Record). En la mayoría de los sistemas, este cargador primario está limitado en base a varias restricciones. Incluso en sistemas que no son PC hay algunas limitaciones al tamaño y complejidad del cargador, así que, la limitación de tamaño del MBR en PCs (512 bytes incluyendo la tabla de particiones) hace casi imposible introducir un gestor de arranque completo dentro de él. Además, la mayoría de sistemas operativos hacen que el cargador primario llame a un cargador secundario que puede estar localizado en una partición del disco especificada. En Linux el gestor de arranque es normalmente lilo(8) o grub(8). Ambos pueden instalarse o bien como cargadores secundarios (donde el MBR instalado por el DOS apunta a ellos), o como un cargador en dos partes donde son ellos los que proporcionan un MBR especial que contiene el código de arranque necesario para cargar la segunda parte del cargador desde la partición raíz. La principal tarea del gestor de arranque es localizar el núcleo en disco, cargarlo y ejecutarlo. La mayoría de gestores de arranque permiten un uso interactivo, para poder especificar un núcleo alternativo (posiblemente una copia de seguridad en caso de que el último núcleo compilado no funcione) y para pasar parámetros opcionales al núcleo. F.1.4 Puesta en marcha del núcleo Una vez que se carga el núcleo, éste inicializa los dispositivos (a través de sus drivers), arranca el intercambiador o swapper (es un "proceso del núcleo", llamado kswapd en los núcleos Linux modernos) y monta el sistema de ficheros raíz (/).

XXIII

Algunos de los parámetros que se le pueden pasar al núcleo están relacionados con estas actividades (p.e: puede sobrescribir el sistema de ficheros raíz por defecto). Para más información sobre los parámetros del núcleo Linux lea bootparam(7). Sólo después el núcleo crea el primer proceso (en espacio de usuario) al que asigna el número 1. Este proceso ejecuta el programa /sbin/init, pasándole cualquier parámetro que no haya podido ser manejado por el núcleo. De modo que para simplificar el kernel del Linux que se empleo en esta trabajo, se configuraron algunos de los servicios del sistema, y se realizó un análisis de los programas y servicios necesarios para el IDS Snort, para que este corra de una manera más apropiada y para que no se le quiten tantos recursos al equipo; ya que el kernel es la parte más reducida del un Sistema Operativo. A continuación se muestra la forma en como se realizó la modificación del sistema para Ubuntu: F.2 Quitando aplicaciones: Primero, se pueden quitar del sistema desde el escritorio, algunas o varias de las aplicaciones las cuales son innecesarias , nunca se utilizan y le quitan recursos al equipo utilizado, esto se hace entrando como se mencionó anteriormente, desde el escritorio en: Aplicaciones->Añadir y quitar, así se observa un cuadro como el de la figura F.1; e inhabilitar las aplicaciones, tales como juegos, aplicaciones de dispositivos que el equipo no posee, en este caso se quitó el paquete de juegos AisleRiot, el Analizador de Bluetooth, el SoftPhone Ekiga, el paquete de OpenOffice, el Escáner de Imagen Xsane, el Reproductor de música Rhythmb, Gestor de Controladores Restringidos, Pidgin.

Figura F.1. Pantalla que muestra como quitar algunas aplicaciones en Ubuntu 7.10

XXIV

F.3 Deshabilitar los servicios del sistema en el Inicio: A pesar de que se pueden deshabilitar algunos servicios para optimizar el núcleo del sistema también debemos recordar que las aplicaciones que conforman nuestro Sistema de Detección de Intrusos emplean algunos servicios que no deben ser deshabilitados son los que emplean estas aplicaciones que componen nuestro sistema de seguridad.

A continuación veremos los servicios que emplean dichas aplicaciones:

Software necesario � Snort 2.8.0.2 (http://snort.org/) � PHP 5 (http://www.php.net/) � MySQL 5.0. (http://www.mysql.com/) --> service mysql � BASE 1.3.9 (http://secureideas.sourceforge.net/) � Apache 2.2.8 (http://www.apache.org/) -> apache service � ADODB 495a (http://adodb.sourceforge.net/) � PEAR (http://pear.php.net/) Primero se debe ir a Sistema -> Administración -> Servicio y desactivar todo que evidentemente no debe iniciarse en forma automática. Ver el contenido del directorio /etc/rc2.d:

ls /etc/rc2.d

K08vmware S16ssh S20apmd S20winbind S89cron

... etc

Figura F.2. Contenido del directorio /etc/rc2.d visto en la terminal de Linux.

F.4 Método Simple Para deshabilitar algunos servicios, se accede desde el escritorio en: Sistemas->Preferencias->Sesiones->Programas de Inicio. Sesiones:

Figura F.3. Deshabilitar servicios desde el escritorio en Ubuntu 7.10

XXV

Sistema->Administración->Gestor de controladores restringidos. Se deshabilitan los controladores restringidos si tu hardware no requiere drivers propietarios.

Figura F.4. Deshabilitación de Controladores Restringidos F.5 Configuración de Servicios. Accediendo desde Sistema->Administración->Servicios. Se deshabilitaron los siguientes servicios: Figura F.5. Configuración de algunos de los servicios del sistema de Ubuntu 7.10

� Ajuste de rendimiento de disco duro (hdparm). � Gestión de autoconfiguración (alsa-utils). � Gestión de dispositivos bluetooth (bluetooth).

XXVI

� Gestión de línea braille (blrtty). � Multiplexor de Terminales (screen). � Programador de acciones (anacron). � Programador de acciones (atd). � Servicio de impresoras (cupsys).

Se dejaron habilitados los siguientes servicios:

� Servidor Web (Apache2) � Servidor de bases de datos (mysql). � Servidor de bases de datos (mysql-ndb). � Servidor de bases de datos (mysql-ndb-mgm). � Soporte de informes colgados automatizados (apport). � Servicio de descubrimiento de DNS multicast (avahi-daemon). � Registro de actividad del sistema (klogd). � Registro de actividad del sistema (sysklogd). � Gestor de inicio de sesión gráfico (gdm). � Gestor de frecuencia de cpu (powernowd). � Gestión de teclas rápidas (hotkey-setup). � Gestión de energía (acpid, apmd). � Bus de comunicación del sistema (dbus).

F.6 Método Completo Se instaló un paquete que permite ver a nivel de sistema todos los servicios que se encuentran habilitados, deshabilitados, o que tiene nuestro kernel desde el inicio. Para tener la lista completa de servicios, se instaló la utilería sysv-rc-conf: sudo aptitude install sysv-rc-conf Luego se ejecutó: sudo sysv-rc-conf Con esta aplicación podemos ver los servicios con los que se cuentan en cada runlevel 0-6 y el rcS.d al momento de iniciar el sistema.

Figura F.6. Configuración de servicios. Método Completo

XXVII

Aquí se pueden seleccionar los servicios en cada runlevel, en nuestro caso se invocan los scripts de los servicios que están en el runlevel2 através del rcS.d y se dan de alta los servicios desde el boot. Esta interfaz es menos agradable pero permite habilitar y deshabilitar todos los servicios en el inicio.

• Cada línea representa un servicio. • Cada columna representa un runlevel (estado del sistema: iniciado, en uso,

detenido, reiniciado…) • El runlevel de trabajo normal bajo Ubuntu es 2. • Utiliza CTRL+N para pasar a la siguiente página de servicios y CTRL+P para ir

a la página anterior. • Utiliza las flechas para desplazarte. • Utiliza la barra de espacios para marcar o desmarcar una casilla. • Presiona Q para salir. • Por lo general para deshabilitar un servicio al inicio, hay que desmarcar las

casillas de las columnas 2 y 5 correspondientes al servicio. Para volver a habilitarlo, marca nuevamente estas casillas.

• Para una descripción humanamente comprensible de los servicios, ver el siguiente enlace.

Existen otras herramientas que muestran los servicios con un ambiente grafico como el Boot-Up Manager pero no muestran todos los servicios que se encuentran en nuestro sistema, pero nos ayudan a verificar que servicios están activos e inactivos rápidamente y habilitarlos si es necesario.

Figura F.7. Administrador de Inicio para servicios.

XXVIII

Simplemente mediante la herramienta update-rc.d, para ver como funciona es mediante: man update-rc.d. Otro modo de poder restringir nuestros servicios en el sistema es empleando un comando preestablecido por la distribución ubuntu 7.10 de linux update-rc.d F.7 Restringir Servicios en el sistema operativo. Para ver los servicios con los que cuenta el sistema podemos accesar a la ruta /etc/ como superusuario para ver el archivo services, y desactivar todos aquellos servicios que no se necesitan, comentarizándolos al principio de la línea con el simbolo #. root@briilfer-laptop:/# cd /etc root@briilfer-laptop:/etc# ls services services root@briilfer-laptop:/etc# vi services Mediante estas líneas de comando podemos accesar al archivo services con el editor vi, y poder seleccionar los servicios que se van a deshabilitar. Dentro de este archivo encontramos los servicios:

� Locales � Red � Específicos de UNIX � Protocolos de envío de datagramas � Agregados para la distribución GNU/LINUX � No oficiales

Se pueden quitar servicios en: sistema -> preferencias -> sesiones y sistema -> administración -> servicios F.8 Runlevels Los scripts que tengamos ejecutándose en un determinado momento nos marcan los servicios que el sistema operativo está ofreciendo y/o recibiendo. El hecho de que podamos tener tantos scripts diferentes hace que tengamos que plantear su organización de forma adecuada. Entenderemos un runlevel (o nivel de ejecución) como la ejecución de unos determinados scripts que a su vez proporcionan unos servicios concretos. En la instalación de un servidor es habitual diseñar una configuración para que en determinados momentos se puedan ofrecer determinados servicios y en otros no. Para permitir este tipo de funcionamiento, el sistema operativo nos proporciona diferentes niveles de ejecución que podremos adaptar a nuestras necesidades. Si bien podemos configurar el número de niveles de ejecución que queremos y la funcionalidad de cada uno de ellos, generalmente los sistemas tipo UNIX nos proporcionan 6. � Nivel 0: El nivel de ejecución 0 está configurado para parar el sistema.

� Nivel 1: Este nivel es denominado como single user, ya que sólo permite la

entrada al sistema al root del mismo. Se arrancan los daemons mínimos y sirve

XXIX

para tareas de mantenimiento.

� Nivel 2-5: Los niveles del 2 al 5 están destinados para ser configurados según las necesidades de cada instalación. Al instalar el sistema, por defecto todos son iguales. Estos niveles también se llaman multiusuario, ya que, por defecto, permiten que más de un usuario trabaje en el sistema.

� Nivel 6: El último nivel está preparado para reiniciar el sistema. Es muy parecido al 0 pero se añade una función de reinicio.

El comando necesario para cambiar de nivel de ejecución es “init” (le pasamos como parámetro el nivel de ejecución que queramos) y para ver en cuál estamos, “runlevel”. Los comandos halt, reboot, shutdown o poweroff lo único que hacen es llamar al nivel de ejecución 0 o 6 realizando, antes, alguna operación concreta (ver su manual para más información). En el fichero /etc/inittab tenemos definida toda la configuración de los runlevels: el nivel de ejecución por defecto, el número de consolas disponibles en cada uno de ellos, etc. Cada línea del fichero es una directiva con la sintaxis: <id> :<runlevels> : <action> : <process> . El primer campo es el identificador de la directiva, seguidamente encontramos en qué niveles de ejecución es válida esta directiva, la acción a realizar y el proceso a lanzar. En el siguiente ejemplo explicamos cómo configurar algunas de estas directivas: # El nivel de ejecución por defecto (en este caso, el 2) id:2:initdefault: # Scripts a ejecutar al arrancar el sistema (antes # de entrar en el nivel de ejecución por defecto) si::sysinit:/sbin/rc sysinit # Inicialización del sistema, ejecuta todos los demonios # que hay en el runlevel boot (/etc/runlevels/boot) rc::bootwait:/sbin/rc boot # Los runlevels disponibles. l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot # Definición de las consolas abiertas en cada # nivel de ejecución (la acción respawn indica # que al terminar la ejecución del proceso

XXX

# getty se lance otra vez) c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux # Comando a ejecutar al apretar CTRL+ALT+DEL ca:12345:ctrlaltdel:/sbin/shutdown -r now Como vemos, en este fichero se configura todo lo referente a los niveles de ejecución de forma muy flexible pudiendo cambiar lo que nos interese para adaptarlo mejor a nuestras necesidades. Fijémonos que, aunque aquí definamos el nivel de ejecución por defecto, también lo podríamos especificar al arrancar el sistema con el Lilo o Grub. Esto es muy útil, por ejemplo, cuando tenemos problemas graves en el sistema que no nos permiten arreglarlos adecuadamente; si arrancamos con el primer nivel (pasando 1 o single al Lilo o Grub), sólo se iniciarán las funciones más necesarias y podremos entrar para arreglar lo que haga falta. Administración de los runlevels con updaterc.d Sistemas que se inician a la System V como Ubuntu tienen diferentes runlevels que permiten poner el sistema en un estado definido. Por ejemplo "2" es el runlevel por omisión de Ubuntu, "0" apaga el sistema y "1" es el modo monousuario que permite ejecutar trabajos de mantenimiento. Al entrar a un runlevel se ejecutan diferentes guiones de inicio en el directorio /etc/init.d. Estos guiones disponen de las funciones "start", "stop", "reload" y "restart" para iniciar, terminar, recargar una nueva configuración o reiniciar el programa correspondiente. Por ejemplo: /etc/init.d/inetd stop A cada runlevel pertenece una colección de enlaces a los guiones de inicio. Estos enlaces se encuentran en los directorios /etc/rc?.d donde "?" es el correspondiente runlevel. Los enlaces tienen nombres especiales. Si empiezan con "S" inician, si empiezan con "K" terminan el correspondiente programa. Después de la letra sigue un número de dos dígitos que determina el orden de ejecución y terminan en el nombre del guión. Este trabajo se simplifica mucho con el programa update-rc.d de Ubuntu. Un ejemplo simple es: Para el caso en que estamos hay que ejecutar el comando: # update-rc.d -f vsftpd remove

XXXI

Con el que borramos el servicio para el arranque, y además, seguimos manteniendo el arranque manual mediante: # /etc/init.d/vsftpd start donde /etc/init.d es el directorio de servicios del sistema despues aparece el nombre del servicio que será dado de alta (/vsftpd), seguido de un comando de activación en este caso start. F.9 Init e inittab Cuando init comienza lee el fichero /etc/inittab para obtener más instrucciones. Este fichero define lo que debería ejecutarse en los diferentes "niveles de ejecución" (run-levels). Esto proporciona al administrador del sistema un sencillo esquema de gestión, donde cada nivel de ejecución se asocia con un conjunto de servicios (p.e.: S es mono-usuario, en el nivel 2 se inician la mayoría de servicios de red, etc.). El administrador puede cambiar el nivel de ejecución actual con init(8) y consultarlo con runlevel(8). Sin embargo, puesto que no es conveniente gestionar los servicios individuales editando directamente este fichero, inittab solamente lanza un conjunto de scripts que son los que realmente arrancan/paran los servicios individuales. F.9.1 Scripts de arranque Nota: La siguiente descripción se aplica a los sistemas basados en SYSV-R4, que actualmente siguen la mayoría de los Unix comerciales (Solaris, HPUX, Irix, Tru64) así como la mayor parte de las distribuciones Linux (RedHat, Debian, Mandrake, Suse, Caldera, Ubuntu). Algunos sistemas (SlackwareLinux,FreeBSD,OpenBSD) tienen un esquema un tanto diferente de scripts de arranque. Para cada servicio gestionado (mail, nfs server, cron, etc.) hay un único script de inicialización ubicado en un directorio específico (/etc/init.d en la mayoría de versiones de Linux). Cada uno de estos scripts acepta como único argumento la palabra ‘start’, que provoca el arranque del servicio, o la palabra ‘stop’, que provoca que se pare el servicio. Opcionalmente el script puede aceptar otros parámetros de "conveniencia" (p.e: ‘restart’, para parar y arrancar, ‘status’ para mostrar el estado del servicio). Ejecutar el script sin parámetros nos mostrará los posibles argumentos. F.9.2 Directorios de ejecución en orden Para conseguir que ciertos scripts determinados se inicien o se paren en diferentes niveles de ejecución y en un orden específico, se crearon los directorios de ejecución en orden. Se encuentran habitualmente en /etc/rc[0-6S].d. En cada uno de estos directorios hay enlaces (normalmente simbólicos) a los scripts que se encuentran en el directorio init.d. Un script principal (normalmente /etc/rc) es llamado desde inittab(5) y es el encargado de invocar a los scripts de servicios a través de los enlaces de los directorios de ejecución en orden. Todos los enlaces cuyo nombre comienza con ‘S’ son invocados con el argumento ‘start’ (por tanto, iniciando el servicio). Todos los enlaces que comienzan con ‘K’ son invocados con el argumento ‘stop’ (por tanto, parando el servicio).

XXXII

Para establecer el orden dentro de un mismo nivel de ejecución, los nombres de los enlaces contienen números de orden. Además, para hacer los nombres más claros, éstos terminan habitualmente con el nombre del servicio al que se refieren. Ejemplo: el enlace /etc/rc2.d/S80sendmail lanza el servicio sendmail en el nivel de ejecución 2. Esto ocurre después de ejecutar /etc/rc2.d/S12syslog pero antes de ejecutar /etc/rc2.d/S90xfs. Para gestionar el orden de arranque y los niveles de ejecución, tenemos que manejar estos enlaces. Sin embargo, en muchas versiones de Linux, hay disponibles herramientas que nos ayudan con esta tarea (p.e: Boot-Up Manager). Ubuntu se ejecuta en el runlevel2 y a continuación se muestran los servicios con los que el sistema arranca, que son enlaces al los scripts que se encuentran en la ruta /etc/init.d

Figura F.8. Pantalla de la Terminal que muestra los scripts del runlevel 2

Podemos visualizar los archivos que se encuentran en la ruta /etc/init.d y ver los servicios contenidos en el archivo init.d

Figura F.9. Archivos en /etc/init.d

XXXIII

Figura F.10. Contenido en init.d

Descripción de los scripts del directorio init.d, es la consola las instrucciones son: briilfer@briilfer-laptop:/etc/init.d$ grep Desc /etc/init.d/cron # Short-Description: Regular background program processing daemon # Description: cron is a standard UNIX program that runs user-specified briilfer@briilfer-laptop:/etc/init.d$ grep Desc /etc/init.d/killprocs # Short-Description: executed by init(8) upon entering runlevel 1 (single). briilfer@briilfer-laptop:/etc/init.d$ grep Desc /etc/init.d/mysql # Short-Description: Start and stop the mysql database server daemon # Description: Controls the main MySQL database server daemon "mysqld"

XXXIV

APÉNDICE G. LICENCIA GNU PREÁMBULO

Las licencias que cubren la mayor parte del software están diseñadas para quitarle a usted la libertad de compartirlo y modificarlo. Por el contrario, la Licencia Pública General de GNU pretende garantizarle la libertad de compartir y modificar software libre, para asegurar que el software es libre para todos sus usuarios. Esta Licencia Pública General se aplica a la mayor parte del software del la Free Software Foundation y a cualquier otro programa si sus autores se comprometen a utilizarla. (Existe otro software de la Free Software Foundation que está cubierto por la Licencia Pública General de GNU para Bibliotecas). Si quiere, también puede aplicarla a sus propios programas. Cuando hablamos de software libre, estamos refiriéndonos a libertad, no a precio. Nuestras Licencias Públicas Generales están diseñadas para asegurarnos de que tenga la libertad de distribuir copias de software libre (y cobrar por ese servicio si quiere), de que reciba el código fuente o que pueda conseguirlo si lo quiere, de que pueda modificar el software o usar fragmentos de él en nuevos programas libres, y de que sepa que puede hacer todas estas cosas. Para proteger sus derechos necesitamos algunas restricciones que prohiban a cualquiera negarle a usted estos derechos o pedirle que renuncie a ellos. Estas restricciones se traducen en ciertas obligaciones que le afectan si distribuye copias del software, o si lo modifica. Por ejemplo, si distribuye copias de uno de estos programas, sea gratuitamente, o a cambio de una contraprestación, debe dar a los receptores todos los derechos que tiene. Debe asegurarse de que ellos también reciben, o pueden conseguir, el código fuente. Y debe mostrarles estas condiciones de forma que conozcan sus derechos. Protegemos sus derechos con la combinación de dos medidas: � Ponemos el software bajo copyright y � le ofrecemos esta licencia, que le da permiso legal para copiar, distribuir y/o modificar el software. También, para la protección de cada autor y la nuestra propia, queremos asegurarnos de que todo el mundo comprende que no se proporciona ninguna garantía para este software libre. Si el software se modifica por cualquiera y éste a su vez lo distribuye, queremos que sus receptores sepan que lo que tienen no es el original, de forma que cualquier problema introducido por otros no afecte a la reputación de los autores originales. Por último, cualquier programa libre está constantemente amenazado por patentes sobre el software. Queremos evitar el peligro de que los redistribuidores de un programa libre obtengan patentes por su cuenta, convirtiendo de facto el programa en propietario. Para evitar esto, hemos dejado claro que cualquier patente debe ser pedida para el uso libre de cualquiera, o no ser pedida. Los términos exactos y las condiciones para la copia, distribución y modificación se exponen a continuación.

XXXV

Términos y condiciones para la copia, distribución y modificación

� Esta Licencia se aplica a cualquier programa u otro tipo de trabajo que contenga una nota colocada por el tenedor del copyright diciendo que puede ser distribuido bajo los términos de esta Licencia Pública General. En adelante, «Programa» se referirá a cualquier programa o trabajo que cumpla esa condición y «trabajo basado en el Programa» se referirá bien al Programa o a cualquier trabajo derivado de él según la ley de copyright. Esto es, un trabajo que contenga el programa o una proción de él, bien en forma literal o con modificaciones y/o traducido en otro lenguaje. Por lo tanto, la traducción está incluida sin limitaciones en el término «modificación». Cada concesionario (licenciatario) será denominado «usted». Cualquier otra actividad que no sea la copia, distribución o modificación no está cubierta por esta Licencia, está fuera de su ámbito. El acto de ejecutar el Programa no está restringido, y los resultados del Programa están cubiertos únicamente si sus contenidos constituyen un trabajo basado en el Programa, independientemente de haberlo producido mediante la ejecución del programa. El que esto se cumpla, depende de lo que haga el programa. � Usted puede copiar y distribuir copias literales del código fuente del Programa, según lo has recibido, en cualquier medio, supuesto que de forma adecuada y bien visible publique en cada copia un anuncio de copyright adecuado y un repudio de garantía, mantenga intactos todos los anuncios que se refieran a esta Licencia y a la ausencia de garantía, y proporcione a cualquier otro receptor del programa una copia de esta Licencia junto con el Programa. Puede cobrar un precio por el acto físico de transferir una copia, y puede, según su libre albedrío, ofrecer garantía a cambio de unos honorarios. � Puede modificar su copia o copias del Programa o de cualquier porción de él, formando de esta manera un trabajo basado en el Programa, y copiar y distribuir esa modificación o trabajo bajo los términos del apartado 1, antedicho, supuesto que además cumpla las siguientes condiciones: � Debe hacer que los ficheros modificados lleven anuncios prominentes indicando que los ha cambiado y la fecha de cualquier cambio. � Debe hacer que cualquier trabajo que distribuya o publique y que en todo o en parte contenga o sea derivado del Programa o de cualquier parte de él sea licenciada como un todo, sin carga alguna, a todas las terceras partes y bajo los términos de esta Licencia. � Si el programa modificado lee normalmente órdenes interactivamente cuando es ejecutado, debe hacer que, cuando comience su ejecución para ese uso interactivo de la forma más habitual, muestre o escriba un mensaje que incluya un anuncio de copyright y un anuncio de que no se ofrece ninguna garantía (o por el contrario que sí se ofrece garantía) y que los usuarios pueden redistribuir el programa bajo estas condiciones, e indicando al usuario cómo ver una copia de esta licencia. (Excepción: si el propio programa es interactivo pero normalmente no muestra ese anuncio, no se requiere que su trabajo basado en el Programa muestre ningún anuncio). Estos requisitos se aplican al trabajo modificado como un todo. Si partes identificables de ese trabajo no son derivadas del Programa, y pueden, razonablemente, ser consideradas trabajos independientes y separados por ellos

XXXVI

mismos, entonces esta Licencia y sus términos no se aplican a esas partes cuando sean distribuidas como trabajos separados. Pero cuando distribuya esas mismas secciones como partes de un todo que es un trabajo basado en el Programa, la distribución del todo debe ser según los términos de esta licencia, cuyos permisos para otros licenciatarios se extienden al todo completo, y por lo tanto a todas y cada una de sus partes, con independencia de quién la escribió. Por lo tanto, no es la intención de este apartado reclamar derechos o desafiar sus derechos sobre trabajos escritos totalmente por usted mismo. El intento es ejercer el derecho a controlar la distribución de trabajos derivados o colectivos basados en el Programa. Además, el simple hecho de reunir un trabajo no basado en el Programa con el Programa (o con un trabajo basado en el Programa) en un volumen de almacenamiento o en un medio de distribución no hace que dicho trabajo entre dentro del ámbito cubierto por esta Licencia. � Puede copiar y distribuir el Programa (o un trabajo basado en él, según se especifica en el apartado 2, como código objeto o en formato ejecutable según los términos de los apartados 1 y 2, supuesto que además cumpla una de las siguientes condiciones: � Acompañarlo con el código fuente completo correspondiente, en formato electrónico, que debe ser distribuido según se especifica en los apartados 1 y 2 de esta Licencia en un medio habitualmente utilizado para el intercambio de programas, o � Acompañarlo con una oferta por escrito, válida durante al menos tres años, de proporcionar a cualquier tercera parte una copia completa en formato electrónico del código fuente correspondiente, a un coste no mayor que el de realizar físicamente la distribución del fuente, que será distribuido bajo las condiciones descritas en los apartados 1 y 2 anteriores, en un medio habitualmente utilizado para el intercambio de programas, o � Acompañarlo con la información que recibiste ofreciendo distribuir el código fuente correspondiente. (Esta opción se permite sólo para distribución no comercial y sólo si usted recibió el programa como código objeto o en formato ejecutable con tal oferta, de acuerdo con el apartado b anterior). Por código fuente de un trabajo se entiende la forma preferida del trabajo cuando se le hacen modificaciones. Para un trabajo ejecutable, se entiende por código fuente completo todo el código fuente para todos los módulos que contiene, más cualquier fichero asociado de definición de interfaces, más los guiones utilizados para controlar la compilación e instalación del ejecutable. Como excepción especial el código fuente distribuido no necesita incluir nada que sea distribuido normalmente (bien como fuente, bien en forma binaria) con los componentes principales (compilador, kernel y similares) del sistema operativo en el cual funciona el ejecutable, a no ser que el propio componente acompañe al ejecutable. Si la distribución del ejecutable o del código objeto se hace mediante la oferta acceso para copiarlo de un cierto lugar, entonces se considera la oferta de acceso para copiar el código fuente del mismo lugar como distribución del código fuente, incluso aunque terceras partes no estén forzadas a copiar el fuente junto con el código objeto.

XXXVII

� No puede copiar, modificar, sublicenciar o distribuir el Programa excepto como prevé expresamente esta Licencia. Cualquier intento de copiar, modificar sublicenciar o distribuir el Programa de otra forma es inválida, y hará que cesen automáticamente los derechos que te proporciona esta Licencia. En cualquier caso, las partes que hayan recibido copias o derechos de usted bajo esta Licencia no cesarán en sus derechos mientras esas partes continúen cumpliéndola. � No está obligado a aceptar esta licencia, ya que no la ha firmado. Sin embargo, no hay hada más que le proporcione permiso para modificar o distribuir el Programa o sus trabajos derivados. Estas acciones están prohibidas por la ley si no acepta esta Licencia. Por lo tanto, si modifica o distribuye el Programa (o cualquier trabajo basado en el Programa), está indicando que acepta esta Licencia para poder hacerlo, y todos sus términos y condiciones para copiar, distribuir o modificar el Programa o trabajos basados en él. � Cada vez que redistribuya el Programa (o cualquier trabajo basado en el Programa), el receptor recibe automáticamente una licencia del licenciatario original para copiar, distribuir o modificar el Programa, de forma sujeta a estos términos y condiciones. No puede imponer al receptor ninguna restricción más sobre el ejercicio de los derechos aquí garantizados. No es usted responsable de hacer cumplir esta licencia por terceras partes. � Si como consecuencia de una resolución judicial o de una alegación de infracción de patente o por cualquier otra razón (no limitada a asuntos relacionados con patentes) se le imponen condiciones (ya sea por mandato judicial, por acuerdo o por cualquier otra causa) que contradigan las condiciones de esta Licencia, ello no le exime de cumplir las condiciones de esta Licencia. Si no puede realizar distribuciones de forma que se satisfagan simultáneamente sus obligaciones bajo esta licencia y cualquier otra obligación pertinente entonces, como consecuencia, no puede distribuir el Programa de ninguna forma. Por ejemplo, si una patente no permite la redistribución libre de derechos de autor del Programa por parte de todos aquellos que reciban copias, directa o indirectamente a través de usted, entonces la única forma en que podría satisfacer tanto esa condición como esta Licencia sería evitar completamente la distribución del Programa. Si cualquier porción de este apartado se considera inválida o imposible de cumplir bajo cualquier circunstancia particular ha de cumplirse el resto y la sección por entero ha de cumplirse en cualquier otra circunstancia. No es el propósito de este apartado inducirle a infringir ninguna reivindicación de patente ni de ningún otro derecho de propiedad o impugnar la validez de ninguna de dichas reivindicaciones. Este apartado tiene el único propósito de proteger la integridad del sistema de distribución de software libre, que se realiza mediante prácticas de licencia pública. Mucha gente ha hecho contribuciones generosas a la gran variedad de software distribuido mediante ese sistema con la confianza de que el sistema se aplicará consistentemente. Será el autor/donante quien decida si quiere distribuir software mediante cualquier otro sistema y una licencia no puede imponer esa elección. Este apartado pretende dejar completamente claro lo que se cree que es una

XXXVIII

consecuencia del resto de esta Licencia. � Si la distribución y/o uso de el Programa está restringida en ciertos países, bien por patentes o por interfaces bajo copyright, el tenedor del copyright que coloca este Programa bajo esta Licencia puede añadir una limitación explícita de distribución geográfica excluyendo esos países, de forma que la distribución se permita sólo en o entre los países no excluidos de esta manera. En ese caso, esta Licencia incorporará la limitación como si estuviese escrita en el cuerpo de esta Licencia. � La Free Software Foundation puede publicar versiones revisadas y/o nuevas de la Licencia Pública General de tiempo en tiempo. Dichas nuevas versiones serán similares en espíritu a la presente versión, pero pueden ser diferentes en detalles para considerar nuevos problemas o situaciones. Cada versión recibe un número de versión que la distingue de otras. Si el Programa especifica un número de versión de esta Licencia que se refiere a ella y a «cualquier versión posterior», tienes la opción de seguir los términos y condiciones, bien de esa versión, bien de cualquier versión posterior publicada por la Free Software Foundation. Si el Programa no especifica un número de versión de esta Licencia, puedes escoger cualquier versión publicada por la Free Software Foundation. � Si quiere incorporar partes del Programa en otros programas libres cuyas condiciones de distribución son diferentes, escribe al autor para pedirle permiso. Si el software tiene copyright de la Free Software Foundation, escribe a la Free Software Foundation: algunas veces hacemos excepciones en estos casos. Nuestra decisión estará guiada por el doble objetivo de de preservar la libertad de todos los derivados de nuestro software libre y promover el que se comparta y reutilice el software en general.

AUSENCIA DE GARANTÍA

� Como el programa se licencia libre de cargas, no se ofrece ninguna garantía sobre el programa, en toda la extensión permitida por la legislación aplicable. Excepto cuando se indique de otra forma por escrito, los tenedores del copyright y/u otras partes proporcionan el programa «tal cual», sin garantía de ninguna clase, bien expresa o implícita, con inclusión, pero sin limitación a las garantías mercantiles implícitas o a la conveniencia para un propósito particular. Cualquier riesgo referente a la calidad y prestaciones del programa es asumido por usted. Si se probase que el Programa es defectuoso, asume el coste de cualquier servicio, reparación o corrección.

� En ningún caso, salvo que lo requiera la legislación aplicable o haya sido acordado por escrito, ningún tenedor del copyright ni ninguna otra parte que modifique y/o redistribuya el Programa según se permite en esta Licencia será responsable ante usted por daños, incluyendo cualquier daño general, especial, incidental o resultante producido por el uso o la imposibilidad de uso del Programa (con inclusión, pero sin limitación a la pérdida de datos o a la generación incorrecta de datos o a pérdidas sufridas por usted o por terceras partes o a un fallo del Programa al funcionar en combinación con cualquier otro programa), incluso si dicho tenedor u otra parte ha sido advertido de la posibilidad de dichos daños.

XXXIX

FIN DE TÉRMINOS Y CONDICIONES Cómo aplicar estos términos a sus nuevos programas. Si usted desarrolla un nuevo Programa, y quiere que sea del mayor uso posible para el público en general, la mejor forma de conseguirlo es convirtiéndolo en software libre que cualquiera pueda redistribuir y cambiar bajo estos términos. Para hacerlo, añada los siguientes anuncios al programa. Lo más seguro es añadirlos al principio de cada fichero fuente para transmitir lo más efectivamente posible la ausencia de garantía. Además cada fichero debería tener al menos la línea de «copyright» y un indicador a dónde puede encontrarse el anuncio completo. <” PROPUESTA DE UN SISTEMA DE DETECCIÓN DE INTRUSOS PARA MONITOREAR LA RED INSTITUCIONAL DE ESIME ZACATENCO”>

Copyright (C) 19aa <IPN-ESIME ZACATENCO>

Este programa es software libre. Puede redistribuirlo y/o modificarlo bajo los términos de la Licencia Pública General de GNU según es publicada por la Free Software Foundation, bien de la versión 2 de dicha Licencia o bien (según su elección) de cualquier versión posterior.

Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA, incluso sin la garantía MERCANTIL implícita o sin garantizar la CONVENIENCIA PARA UN PROPÓSITO PARTICULAR. Véase la Licencia Pública General de GNU para más detalles.

Debería haber recibido una copia de la Licencia Pública General junto con este programa. Si no ha sido así, escriba a la Free Software Foundation, Inc., en 675 Mass Ave, Cambridge, MA 02139, EEUU.

Añada también información sobre cómo contactar con usted mediante correo electrónico y postal.

Si el programa es interactivo, haga que muestre un pequeño anuncio como el siguiente, cuando comienza a funcionar en modo interactivo: Gnomovision versión 69, Copyright (C) 19aa nombre del autor

Gnomovision no ofrece ABSOLUTAMENTE NINGUNA GARANTÍA. Para más detalles escriba «show w».

Los comandos hipotéticos «show w» y «show c» deberían mostrar las partes adecuadas de la Licencia Pública General. Por supuesto, los comandos que use pueden llamarse de cualquier otra manera. Podrían incluso ser pulsaciones del ratón o elementos de un menú (lo que sea apropiado para su programa).

Esta Licencia Pública General no permite que incluya sus programas en programas propietarios. Si su programa es una biblioteca de subrutinas, puede considerar más útil el permitir el enlazado de aplicaciones propietarias con la biblioteca. Si este es el caso, use la Licencia Pública General de GNU para Bibliotecas en lugar de esta Licencia.