Estudio de tráfico malicioso en los servicios críticos internos de la UTPL
De Computacion
ESTUDIO DE TRÁFICO MALICIOSO EN LOS SERVICIOS CRÍTICOS INTERNOS DE LA UTPL
PRIMER COMPONENTE: “Análisis de la situación actual”
Fase 1.1 Estudio del Esquema actuasdsadal de la Honeynet.
1.1.1 Honeynet: Definiciones Inmiscuidos en la inmensa masa de usuarios de internet existen usuarios con intenciones arteras contra la privacidad y respeto por la propiedad física e intelectual ajena, para ser más exactos, hago refiero a los hackers malignos, conocidos técnicamente como crackers, sujetos difíciles de identificar que intentan y mayoritariamente consiguen romper las seguridades de empresas privadas, instituciones comerciales, financieras, etc. Con el ánimo de hacer daño aunque la razón principal de su existencia es actualmente la lucrativa. Ingentes métodos, técnicas, procedimientos se han incorporado hacia el sector productivo con el objetivo primordial de proteger los datos de las empresas, sean estas de cualquier índole. A estas estrategias de protección se suma un nuevo método, que inicialmente tiene un objetivo meramente académico, no siendo una estrategia necesariamente para las organizaciones preocupadas en proteger su seguridad. Una honeynet es una red ideada para aprender del atacante, conocida informalmente como una red trampa, que bien puede ser una réplica de la red de una organización emulando sus servicios o también una red que implemente otros servicios dentro de la empresa. El objetivo primordial de los administradores de una honeynet es capturar tráfico, para por medio de éste aprender las técnicas de ataque utilizadas. El administrador de una honeynet debe poseer la habilidad necesaria para esconder y proteger la red, el atacante no debe caer en cuenta que sus acciones están siendo monitoreadas, teniendo en cuenta que estos tienen técnicas para reconocer si están en una red en producción o una honeynet. Aún menos el administrador no puede permitir que la red sirva de relay, es decir que desde la red se ataque a otra en producción dentro o fuera de la organización.
1.1.2 Revisión del estado del arte de la honeynet UTPL La honeynet UTPL nació como un proyecto de tesis, se implementó y actualmente está siendo administrada por el grupo de seguridad en el Departamento de Telecomunicaciones de la universidad. Desde su implementación extrae reportes periódicos del tráfico capturado por los sensores ubicados en los honeypots. La honeynet se encuentra ubicada fuera del espacio de direcciones de producción de la universidad, esta consideración se tomó muy en cuenta debido a que en la red de producción están ubicados servicios de TI que pueden ser susceptibles a ataques, teniendo en cuenta que una Honeynet puede ser usada como atacante de tal manera que no se pueden exponer los servicios a este posible riesgo. En la honeynet se utilizan algunas herramientas como Walleye, Sebek, Snort entre las principales, de las cuales Sebek se utiliza para realizar la captura de tráfico, la figura posterior muestra la estructura de la comunicación de Sebek para la transmisión de los datos capturados desde un Honeypot hacia el servidor que almacena los datos.
Esta estructura se utiliza en la mayoría de las honeynets que usan Sebek, este realiza la captura de datos en el honeypot y luego los transmite de forma segura e invisible al atacante hacia el servidor para su posterior análisis. Mientras que Walleye es una interfaz gráfica que presenta de ordenadamente la información previamente extraída con Sebek.
1.1.3 Revisión de la plataforma
La actual red trampa es de generación II, como se mencionó anteriormente esta se encuentra ubicada fuera de la red de producción de la universidad, con un direccionamiento de subred para 8 hosts, gráficamente se puede observar la ubicación inicial de la honeynet.
Fig 1.1.3.1 Esquema de la red de la UTPL
Fig 1.1.3.2 Esquema de red de la honeynet UTPL
Mención aparte para destacar las técnicas de engaño utilizadas en la Honeynet para despistar a los atacantes, es decir para que estos crean que realmente están atacando a un recurso importante, entre estos destacan, honeyd el software de virtualización que permite diseñar una Honeynet y Symantec Decoy Server (Man Trap) Una configuración errónea en una Honeynet puede tener implicaciones severas sobre los equipos de la red de producción si la red está operando junto a una. La Honeynet puede ser comprometida y usada como relay[3], un señuelo del verdadero atacante. El administrador debe acometer correctamente las configuraciones que eviten la salida de tráfico maligno desde la red trampa hacia alguna red en producción, servidor ajeno externo, etc. Esta medida se logra con las reglas de firewall, también implementadas en la Honeynet UTPL, junto a otras medidas como un NIDS. Tomando en cuenta las ventajas y desventajas de la honeynet [4], en la honeynet que se ha integrado en la red, se ha utilizado algunos métodos que permiten asegurar un alto rendimiento [4], de acuerdo a la fuente citada, los honeypots sobretodo deben ser mantenidos de acuerdo a una lista de pasos, ésta lista de pasos ayuda al administrador a reponer los equipos en cuanto estos lo necesiten ya sea porque el equipo se ha visto comprometido demasiado, está siendo utilizado como relay o bien necesita realizarse un backup de datos, manejando para esto imágenes de las configuraciones y de los datos totales en los honeypots.
1.1.4 Revisión del software Actualmente se utilizan para la administración y mantenimiento herramientas que vienen incluídas en la distribución Honeywall, tales como las iptables de firewall, snort, proxy ARP, snort_Inline, etc. Snort.- NIDS que lanza alarmas de ataques conocidos que son detectados por sus sensores. Snort_Inline.- NIPS que previene ataques detectados por snort, está basado en snort y puede ser configurado para realizar alguna acción específica sobre los paquetes atacantes. Iptables.- Reglas de firewall que permiten regular las conexiones de entrada y/o salida. Proxy ARP.- Permite dar acceso a internet a los honeypots ubicados en la red trampa. P0F (Passive OS fingerprinting9).- Recoge información sobre el sistema operativo de un host. Sebek.- Aplicación cliente – servidor que captura los datos ingresados por los atacantes, es decir captura todas las manipulaciones y modificaciones de los atacantes sobre los datos del honeypot. Capaz de registrar conexiones seguras levantadas desde y hacia el equipo. Se ubica muy cerca del núcleo, por tal motivo pasa desapercibido por los atacantes. El objetivo primordial como se ha explicado es recolectar los datos modificados y creados sin que la aplicación sea descubierta. Hflow.- Recolecta los datos proporcionados por el IDS Snort, Argus, POF y los datos sebek. Todos estos datos son almacenados en una base de datos del mismo nombre, elaborando un modelo relacional complejo. Wireshak.- Potente analizador de tráfico, permite ver información de los archivos exportados por sebek (.cap). Provisto de herramientas gráficas para determinar el flujo de datos, incluyendo una potente base de datos de filtros que puede ser usada para realizar análisis detallados sobre algún servicio en particular. Walleye.- Herramienta gráfica de administración de la Honeynet, permitiendo al administrador solicitar información a los honeypots. Permite ver los datos recolectados por sebek. Honeysnap.- Presenta análisis resumidos de los archivos exportados por sebek.
1.1.5 Honeynet virtuales Virtualizar sistemas permite el ahorro de tiempo, recursos y por ende dinero, una honeynet de este tipo no son un nuevo concepto, de hecho toman el concepto actual de Honeynet y las implementan de una forma diferente. Esta implementación tiene sus únicas ventajas y desventajas comparadas con las Honeynets tradicionales. Las ventajas son coste reducido y más fácil manejo, ya que todo está; combinado en un único sistema. Es decir no existen grandes diferencias entre una honeynet normal y una virtualizada en cuanto a la instalación e implementación; En protección y resultados es otro ámbito, mientras que en una honeynet normal se puede utilizar cualquier tipo de sistema operativo, en las virtualizadas se limita mucho al hardware y al programa virtualizador que se use, además un atacante puede usarla para pasar por alto los mecanismos de control y captura de datos tomando el dominio de la honeynet virtual.
Honeynet Virtual Auto-Contenida
Una Honeynet Virtual Auto-Contenida es una red entera Honeynet condensada en un sólo computador. La red entera está virtualmente contenida en un único y físico sistema. Una red Honeynet típicamente consiste de un cortafuegos para Control de Datos y Captura de Datos, y los honeypots dentro de la Honeynet.
Honeynet Virtual Híbrida
Una Honeynet Híbrida es una combinación de la clásica Honeynet y del software virtual. Captura de Datos, como por ejemplo cortafuegos, y Control de Datos, como por ejemplo sensores IDS y almacenamiento de logs, están en un sistema separado y aislado. Este aislamiento reduce el riesgo de compromiso. Sin embargo, todas las honeynets son virtualmente ejecutadas en una única máquina.
1.1.6 Resultados obtenidos Si bien la Honeynet UTPL captura tráfico malicioso valioso que sirve de aprendizaje, no cubre los servicios que actualmente la universidad brinda a sus usuarios, no tiene un servidor web, proxy, mail, dns siquiera con las mismas configuraciones y características que las utilizadas, aún más crítico es que tampoco monta servicios propios de la universidad, como el sistema financiero, ni el sistema de gestión académica por lo que es necesario montar estos servicios para que los administradores de los servidores obtengan información del riesgo que corren sus servicios al estar expuestos en la red de producción. Ahora a pesar de que la Honeynet emula débilmente algunos servicios, la información que se extrae de esta es valiosa para la investigación presente, a continuación detallo las herramientas que a priori y primordialmente serán ubicadas en la red virtual:
•Honeywall – Walleye •Sebek •Wireshark •TCPDump •Snort – Snort_Inline
Fase 1.2 Identificación de servicios internos de la UTPL.
1.2.1.- Problemática Como se menciona al final de la sección anterior, la actual red trampa montada no emula los servicios con los que la universidad actualmente funciona, aunque captura tráfico malicioso este tráfico no sirve directamente, brinda información para tomar en cuenta pero no se obtiene nada en concreto si se tuviese alguno de los servicios de la universidad montado. No se pretende dar una solución efectiva contra algún método de ataque específico, pero si hablamos de una medida que puede ayudar a prevenir distintos ataques, en principio, porque la red virtual se montará para obtener información de la estructura de los ataques, conocer nuevas vulnerabilidades, pero, distinto de la honeynet actual se montarán los mismos servicios que utiliza la universidad, con las mismas configuraciones, con el ánimo de identificar las vulnerabilidades que por muchas razones se pasan por alto y que de esta manera brinde información al administrador de cómo puede proteger aún más a su equipo. La universidad cuenta con una variedad abultada de servicios, para esto posteriormente se hará una evaluación para escoger los servicios de mayor criticidad en la red de producción interna tomando en cuenta variables como tráfico entrante, promedio, impacto si algún riesgo potencial sucede, etc.
1.2.2.- Inventario de servicios y evaluación de la criticidad Esta fase del proyecto comprende también el análisis de la importancia de los servicios en la red de la universidad, como primer paso de esta fase, se ha realizado una investigación en base a la información encontrada en el proyecto PCN [5]. Aunque en el PCN se menciona un SGA-MAD (Sistema de Gestión Académica de la Modalidad Abierta y a Distancia) y SGAMC (Sistema de Gestión Académica de la Modalidad Clásica), estos dos sistemas fueron reemplazados por el Entorno Virtual de Aprendizaje EVA, el cuál será implementado en esta fase inicial de análisis de servicios. El servicio de internet es el que contiene los servicios críticos en sí, los más necesarios para nuestro proyecto, PCN menciona: Los servicios de internet como mail, DNS, Web Hosting y Proxy involucran las tareas de administrar las cuentas de correo de todos los usuarios de la Universidad, asignación de nombres de dominios internos de las aplicaciones, brinda dominios virtuales a clientes externos, permite el acceso a internet. Por lo que estos servicios debería ser implementados, en principio, puesto que en las posteriores secciones se evaluará la criticidad de cada servicio, su importancia, cantidad de usuarios, servicios, etc.
Para la elección de los servicios se seguirá un proceso de filtrado, con las siguientes fases:
1. Encuestas.- Con el carácter de extraer información de los servidores se aplicó a todos los administradores, se puede considerar como el primer filtro, de estas encuestas se tomaron en cuenta la cantidad de usuarios que gestiona cada servidor, la importancia, la criticidad, los servicios que utiliza, además si interaccionan con otros servicios de la red.
2. Definición de los servicios críticos de acuerdo al tráfico: Se realiza el segundo filtro, aquí se extraen estadísticas del tráfico promedio y máximo tanto de entrada como tráfico de salida, esta muestra de datos se extrae en dos intervalos de una semana cada uno.
3. De acuerdo a los dos puntos anteriores se realiza una evaluación conjunta con el director de tesis para confirmar o descartar servidores.
4. Consideraciones finales.- Se pide información detallada a cada administrador de los servidores que han llegado hasta esta sección [Anexo 3].
5. A los servidores escogidos se extrae los problemas de seguridad que aparecen en los datos proporcionados por los propios administradores, además, se realiza una búsqueda online de las vulnerabilidades conocidas sobre el sistema operativo y sobre los servicios implementados en cada servidor.
1.2.3 Definición de servicios críticos de acuerdo al tráfico Luego de recabar información de cada servicio y de acuerdo a los datos resultantes de las encuestas sometidas, los servidores, fueron sometidos a una evaluación de tráfico, con la intención de conocer con más detalle si deberían o no ser parte de la red interna que se implementa, para esto, se tomó dos muestras de tráfico en un intervalo de una semana para cada muestra, con lo cual se obtuvo:
Servidor Muestra eth0 In Average Out Average In Max Out Max WEB Del 29/03 a 02/04 185.22k 2.05M 3.29M 34.75M
Del 05/04 a 09/04 379.06 k 6.73 M 13.57 M 111.48 M
DNS Del 22/03 a 26/03 35 k 59.96 k 110.09 k 188.73 k
Del 29/03 a 02/04 36.85 k 62.86 k 110-09 k 183.61 k
Proxy Del 29/03 a 02/04 734.8 K 6.43 M 49.33 M 81.27 M Del 22/03 a 26/03 1.30 M 10.20 M 16.33 M 36.83 M proxy eth1 Del 29/03 a 02/04 8.52 M 794.13 K 78.03 M 73.42 M
Del 22/03 a 26/03 10.17 M 1.02 M 38.99 M 16.16 M
De estas estadísticas se puede concluir que el servidor DNS no encajaría, por tráfico, en el nivel de los otros servidores, ciertamente registra muy poco tráfico, pero en caso de fallar este servicio toda la universidad perdería el acceso a internet además del caos que se produciría en la red interna por la interacción entre servicios, puesto que muchos utilizan los nombres de los equipos en lugar de su dirección IP. El servidor proxy tiene 2 interfaces Ethernet funcionando, obviamente es necesaria la presencia de ambas, pero la presencia del servidor no se justifica como crítica, ciertamente es un servicio de criticidad media, pero, ante su falta la universidad aún podría salir al internet con la configuración adecuada.
1.2.4 Consideraciones finales entre los servicios escogidos
Consideraciones Baan PROXY DNS EVA
Número usuarios 62 1500* 1500* 67000*
Criticidad** Alta Media Media Baja
Importancia** Alta Media Media Alta
Interracción con otros sistemas Si No No Si
Fecha de ultima actualización Dic-10 Mar-10 Mar-10 Ene-10 **Fechas tomadas de las encuestas realizadas en Abril 2010
Última vez que parchó - - - Mar-10
Lleva registro de incidentes No Si si no
Da un promedio aproximado de incidentes no No < 10 no
Considera que el equipo es el adecuado si No si no
Usa un firewall ** no Si si no
- Valor aproximado
- Según el administrador
1.2.5 Revisión de problemas de seguridad relacionados De los problemas identificados en las encuestas sometidas a los administradores, se deslindan los siguientes: o Algunos administradores no colocan los parches adecuados para sus distribuciones ni sus servicios. o Se llevan registros de los ataques a los servicios, pero, no tienen un número aproximado de ataques conocidos o en algunos casos los ataques son mínimos. o La mayoría de los administradores cree que su equipo ya no brinda las prestaciones necesarias para satisfacer las necesidades de los usuarios. De los servicios que se proporcionan todos tienen vulnerabilidades [Ver anexo B] las cuales se encuentran parchadas con las actualizaciones últimas realizadas sobre los servicios, aunque es posible que existan aún más vulnerabilidades
1.2.6 Resultados obtenidos: Servidores escogidos Luego del proceso realizado se llega al escogimiento de estos 4 servidores, de los cuales se obtuvo información detallada gracias al apoTexto en cursivarte de cada administrador:
Baan Datos generales
N° Procesadores 2
Procesador Powerpc P5
Memoria 17 GB
Disco duro 300 GB*
Raid -
S.O. AIX
Versión 5.3
Kernel Mantenimiento 8
Firewall No
Detalles de administración
Nombre ****
DIR IP ****
Ubicación Interna
Dependencia SIT - D. Financiero
Responsable *****
Estado Producción
Criticidad Alta
Importancia Alta
Usuarios 62
Interacción Syllabus
Servicios
Servicio Puerto Versión
Baan ERP 512 5.0 c
Oracle 1521 10 G
WEB
Datos generales Nombre ****
DIR IP ***
Ubicación Interna
Dependencia Gestión del conocimiento
Responsable Ing. Diana Torres
Estado Producción
Criticidad Alto
Importancia Alto
Usuarios Aprox. 2000
Interacción Servidor EVA, SGA, Mail, Servidor Oracle
Detalles de hardware
N° Procesadores 2
Procesador Intel Xeon a 1.6 Ghz
Memoria 10 GB
Disco duro 300 GB
Raid -
S.O. CentOS
Versión 4.4
Kernel 2.6.9
Firewall Si
Servicios
Servicio Puerto Versión
Apache 80 2.6
CMAP 8080, 4447, 4999, 31099 5.03.03
SSH 22 3.9
FTP 21 -
Webmin 25000 1.4
Servidor EVA(Entorno virtual de Aprendizaje) Datos generales
Nombre ****
DIR IP ****
Ubicación Interna
Dependencia Virtualización
Responsable Ing. Rodrigo López
Estado Producción
Criticidad Alta
Importancia Media
Usuarios Aprox. 67000
Interacción Mail, LDAP
Detalles de Hardware y S.O.
N° Procesadores 1 – Dual Core
Procesador Intel Xeon 1.6 Ghz
Memoria 8 GB
Disco duro 70 GB
Raid -
S.O. CentOS
Versión 5.3
Kernel 2.6.9.42
Firewall No
Servicios
Servicio Puerto Versión
Apache 80 -
Tomcat 8080 -
DNS Interno Datos generales
Nombre ****
DIR IP ****
Ubicación Interna
Dependencia UPSI – GTE
Responsable Ing. Alexander López
Estado Producción
Criticidad Media
Importancia Media
Usuarios Aprox. 1500
Interacción No
Detalles de hardware y S.O.
N°Procesadores 1
Procesador Pentium III 1.2 Ghz
Memoria 1 GB
Disco duro 80 GB
Raid 1
S.O. CentOS
Versión 5
Kernel 2.6.9-78
Firewall Si
Servicios
Servicio Puerto Versión
Named 53 9.2.4
SSH 22 3.9
SEGUNDO COMPONENTE
“IMPLEMENTACIÓN DE LOS SERVICIOS CRÍTICOS EN LA HONEYNET VIRTUAL”
Fase 2.1 Preparacion de equipos
2.1.1 Elección de herramienta virtualizadora. Esta subfase comprende el análisis de las herramientas existentes para virtualización, comparación entre aplicaciones, los beneficios y desventajas que proporcionan, además se constrastará al final cuál de ellas se ajusta a los requerimientos necesarios para montar la honeynet y los honeypots correspondientes. Entre los requisitos que deben cumplir se encuentrar:
Enmarcarse dentro de las posiblidades del hardware que se utilizará. El consumo de recursos debe ser bajo. Que soporte los S.O. a utilizar. Que permita manejar los modos Host-only. Nat y bridge principalmente. Que permita suspender los S.O. En lo posible que sea una herramienta libre.
2.1.2 Análisis de Herramientas existentes
VMWWARE [7] Vmware es un producto para realizar virtualización de sistemas operativos, en principio se creó como software privado, pero gracias al advenimiento de la cultura open source, EMC Corporation creó versiones libres para instalarse en la mayoría de plataformas basadas en unix. El software creado por esta empresa mantiene, entre los más conocidos, los productos Vmware, y las versiones libres Vmware Server y Vmware Player, las siglas VM provienen de la unión de las palabras anglosajonas Virtual Machine. Vmware es un simulador de sistemas operativos, un simulador permite una ambiente de ejecución con características similares a uno real, emulando sus características principales, tales como CPU, BIOS, tarjeta gráfica, RAM, Adaptador de sonido, puertos seriales, Disco Duro, etc. Aunque un simulador no puede emular la velocidad real de un equipo físico con un sistema anfitrión, se acerca mucho y permite usarle en ambientes de producción. Vmware permite ejecutar instrucciones directamente en el procesador, a diferencia de algunos de sus rivales, además es uno de los productos de virtualización más utilizados. Vmware tiene algunos competidores como Virtual PC (para Windows XP), Xen (paravirtualization ), Virtual Box, entre las más conocidas. Vmware Player Es un producto gratuito que permite correr máquinas virtuales creadas con productos de VMware. Las máquinas virtuales se pueden crear con productos más avanzados como VMware Workstation, o con el propio VMware Player desde su versión 3.0 (las versiones anteriores no incluyen dicha funcionalidad). Vmware Server Esta versión, a diferencia de la anterior, tiene un mejor manejo y administración de recursos; también corre dentro de un sistema operativo (host), está pensada para responder a una demanda mayor que el Workstation. Otra diferencia entre VMware Server y Workstation es que se pueden ejecutar de manera concurrente más máquinas virtuales soportando servidores con hasta 32 procesadores y/o 64 GB de memoria, ofreciendo funcionalidad de administración remota, soporta una API avanzada y funcionalidad de scripting y se puede ejecutar en modo headless. Vmware ESXi Es una version completa del producto ESX, pero con varias limitaciones, entre ellas: no permite instalar controladores (drivers) para hardware adicional, no permite utilizar las funciones avanzadas de movimiento de maquinas virtuales encendidas de un equipo fisico a otro, ni hacerlo con el almacenamiento. Vmware ESX Server Esta versión es un sistema complejo de virtualización, pues corre como sistema operativo dedicado al manejo y administración de máquinas virtuales dado que no necesita un sistema operativo host sobre el cual sea necesario instalarlo. Pensado para la centralización y virtualización de servidores, esta versión no es compatible con una gran lista de hardware doméstico. Es realmente útil, ya que solamente ocupa 10 Mb de Ram y 55 de Disco Duro, aproximadamente. Para su administración, hay que instalar un software en una máquina remota, que se conecta por entorno web.
XEN [8] Producto de Paravirtualización, desarrollada por la univesidad de Cambridge, a diferencia de vmware que hace una virtualización, xen se mezcla con el sistema operativo anfitrión dando mejores resultados aunque con un nivel mayor de dificultad y un aumento en el consumo de recursos. Los sistemas operativos pueden ser modificados explícitamente para correr Xen. Esto permite a Xen alcanzar virtualización de alto rendimiento sin un soporte especial de hardware. Es software de licencia libre lo que posibilita su mayor uso en distribuciones linux, aunque no alcanza el rendimiento de Vmware ESX Server [9] que es software privativo, está muy cerca en términos de rendimiento. Xen puede ser instalado en los siguientes sistemas Mandriva Suse Fedora Core Fedora Red Hat Enterprise Linux Xenophilia Debian Ubuntu Xen demo CD NetBSD Oracle VM Centos, entre los más conocidos.
VIRTUAL BOX [10] Software de virtualización creado originalmente por Innotex GmbH, aunque, actualmente es desarrollado por Oracle Corp. De características similares a vmware player, soporta sistemas operativos GNU/LINUX, MAC OSX, OS/2 Warp, Microsoft Windows, Open Solaris/Solaris. Nación como un producto con licencia de software propieatrio aunque a inicios del 2007 se publicó la versión Virtual Box OSE, bajo la licencia GPL2, aunque carece de algunas funcionalidades en comparación con rivales como Wmware o Virtual PC, provee la ejecución de maquinas virtuales de forma remota a través del protocolo RDP (Remote Desktop Control).
Entre las características principales se pueden mencionar:
El que permite el uso de carpetas compartidas entre las máquinas virtuales
Las últimas versiones ya incluyen ya brindan soporte necesario para que una máquina virtual pueda integrar puertos USB
Las configuraciones de virtualbox se guardan en archivos con formato xml, lo que permite que esas configuraciones puedan transferirse a otras máquinas.
Control de escritorio remoto, una máquina virtual puede actuar como un servidor RDP, lo que permite que se pueda correr la máquina virtual de forma remota.
Esta es una evaluación comparativa realizada por el sitio alemán heise , entre Vmware y Virtualbox, teniendo los siguientes resultados: make: -- Máquina real: 64 minutos -- VirtualBox: 107 minutos -- VMware: 101 minutos En el resultado superior, se escogió un sistema operativo se implementó en ambos productos y se calculó el tiempo que cada uno demoró en comparación con una máquina real al momento de hacer una compilación de kernel. grep: -- Máquina real: 7 minutos -- VirtualBox: 20 minutos -- VMware: 18 minutos En este segundo resultado se realizo un grep con un listado de más de 100MB. Razones para escoger Virtualbox OSE.
Aunque este producto no ofrece un rendimiento igual o mejor que Vmware, se acerca mucho, entre las ventajas que puedo nombrar están:
Es software libre. Consume menos recursos en el equipo anfitrión asignado. Incluye las características más comunes entre las herramientas de virtualización existentes. Facilidad de mantenimiento de las máquinas virtuales. Crea un solo archivo por cada máquina virtual. Comparte carpetas entre máquinas virtuales. Soporte de dispositivos USB Administración de máquinas virtuales de forma remota. Archivo de configuración único de facil transporte.
2.1.2 Honeynet virtual a utilizar Se usará una honeynet Virtual auto-contenida, ya que presenta algunas ventajas sobre una Híbrida, ventajas tales como: el uso de un solo equipo para el proceso de virtualización, mayor facilidad de mantenimiento, etc. Debido a que los honeypots que se administrarán y dado que no se puede permitir poner en riesgo el control total de la honeynet por un atacante, tomando en cuenta las limitaciones en términos de captura y protección
2.1.3 Pruebas de implementación
Equipo de prueba
Procesador Intel Pentium 4
RAM 1 GB
DISCO DURO 80 GB
S.O. Anfitrión Ubuntu 8.04
Maquina virtual Virtualbox
Sistemas virtualizados DNS - Centos 5.3 - 256 RAM - 8 GB HD - GUI Inhabilitada WEB - Centos 5.3 - 286 RAM - 8 GB HD - GUI Inhabilitada Honeywall
Equipo utilizado como anfitrión
Procesador Intel Core 2 Duo
RAM 4 GB *
DISCO DURO 320 GB
S.O. Anfitrión Ubuntu 9.10
- El equipo trajo inicialmente 2 GB, se adquirieron 2 GB aparte.
2.1.5 Conclusiones extraídas a partir de las pruebas
Sistemas a instalar en host anfitrión*
Las pruebas de implementación me sirvieron para identificar la configuración virtual óptima para los servidores escogidos como críticos, además mencionar que se utilizará una honeynet virtual híbrida por todas las prestaciones que presenta en comparación a una Auto-Contenida. Con las pruebas se llegó a la conclusión de que cada servidor virtual debe tener las siguientes especificaciones de acuerdo a las características del host anfitrión.
SERVIDOR S.O. RAM (GB) HD (GB)
DNS CentOS 5 ** 408 32
WEB CentOS 4.4 ** 588 61
EVA CentOS 5.3 ** 558 52
BAAN AIX** 498 72
Honeywall Honeywall 1185 81
Recursos utilizados 3237 298
- Son datos aproximados teniendo en cuenta los datos de las pruebas
- Se reemplazo por Ubuntu Server Gutsy Gibon por la limitación de la instalación de sebek.
2.1.4 Riesgos encontrados
RIESGO PROBABILIDAD IMPACTO CONSECUENCIA ACCIONES
Falta de espacio en HD 2 3 La máquina virtual podría colapsar Respaldos periódicos
Falta de RAM 2 3 Volcado de memoria: Colapso de MV. -
Configuración erronea 2 2 Captura erronea, comprometer MV, Perdida de tiempo, etc. Configurar de acuerdo a las necesidades
MV Comprometida 3 2 Atacante se apodera de maquina virtual y realiza cambios Revisión de Logs
Descripción de riesgos:
• Falta espacio en HD Si se adicionan la capacidad de discos de cada sistema, tendríamos problemas considerando que el equipo pedido trae 320 GB, los cuales serán repartidos entre las 5 maquinas virtuales y el host anfitrión. Aunque por la naturaleza del proyecto, de emular los sistemas, no necesariamente se implementarán con la misma capacidad, pero si se asignará una cantidad adecuada para cada sistema Acción preventiva: Para aplacar este riesgo es posible contar con un disco duro externo de la misma capacidad, en el cual se irá respaldando la información capturada por cada honeypot. Probabilidad: Clasificado como de importancia media, debido al uso de un disco externo la probabilidad disminuye. Impacto: Alto, si el riesgo se hace realidad, el efecto es la caída del honeypot.
• Falta de Memoria principal RAM Un riesgo de mucha importancia. Aunque son 5 maquinas virtuales no todas consumen la misma cantidad de memoria principal, las pruebas arrojan que el servidor DNS podría trabajar con 256 de RAM tranquilamente, mientras que con la máquina de prueba el servidor WEB con 281 trabaja bien. La preocupación aparece con el servidor BAAN que es el de más alto consumo en memoria principal. Acción preventiva: La placa base del anfitrión soporta hasta 4 GB, así que se elevará hasta esa cantidad la memoria principal. Probabilidad: Es muy posible que ocurra este problema. Impacto: Alto, la ocurrencia de este riesgo podría denegar el servicio del honeypot.
• Configuración errónea VER ANEXO F Este riesgo tiene más ocurrencia por un error humano antes que un problema tecnológico. Tendría efectos operativos que dificultarían la captura normal desde los honeypots, además que importaría a los administradores perdidas en términos de tiempo. Acción preventiva: Llevar a cabo una configuración de acuerdo a una metodología que cubra todos los aspectos importantes para una perfecta configuración Probabilidad: Media, es probable que ocurra, pero si se sigue la metodología, este riesgo se minimiza. Impacto: Medio, aunque funcionaría el honeypot es probable que no esté cumpliendo la labor para la que fue pensado.
• MV Comprometida Es un riesgo común y de mucha importancia, un atacante podría tomar acciones sobre el honeypot para hacer daño sobre el mismo o para utilizarlo como relay o atacante falso, aunque los honeypots virtuales limitan el accionar de cualquier atacante. Acción preventiva: Antes que acciones preventivas, se debe configurar muy bien las aplicaciones de captura, en este caso Sebek, para tener la información exacta de cómo fue comprometida la máquina. Además se puede evitar que el honeypot sea utilizado como relay prohibiendo la salida de tráfico desde el honeypot. Probabilidad: Alta, es decir el honeypot está expuesto para ser comprometido, el tema es evitar que sea usado para atacar. Impacto: Alto, si es comprometido y las configuraciones también son erróneas, es probable que el honeypot sea utilizado como un atacante falso.
Fase 2.2 Implementación de servicios
Fase 2.2.1 IMPLEMENTACIÓN DEL SERVIDOR WEB El servidor web de la UTPL cuenta con los servicios de apache y webmin, los cuales alojan la página principal de la universidad, para lo cual se instaló y configuró el servidor WEB con las siguientes características: Instalación y configuración
1. Creación de máquina virtual
a. Características principales
i. 2 procesadores
ii. 698 MB memoria RAM
iii. 61.10 de Disco Duro
iv. Habilitada la función PAE/NX, necesaria para que el SO virtualizado pueda gestionar archivos mayores a 4GB.
v. Eth0 en modo bridge.
2. Instalación de Ubuntu server 7.10 Gutsy gibbon
a. Nombre de la máquina: mpkstroff
b. Usuario: mpkstroff
c. Nombre de la cuenta: mpkstroff
d. Contraseña: --
3. Configuraciones previas del S.O.
a. Modificación de los archivos motd y motd.tail
b. Instalación de openssh-server y openssh-client
4. Instalación de servidor web apache Ver anexo E
5. Instalación de webmin Ver anexo F
6. Pruebas Ver anexo G
7. Instalación de sebek
2.2.1.2 Reglas de firewall Ver anexo I El servidor web de la utpl si utiliza un firewall, aunque la aplicación cmaps no pudo ser instalada se abrió el puerto, además se permitió el acceso a los servicios web, ssh, ftp, se permite la comunicación con el servidor EVA además con el Webmin para la administración del servidor y finalmente se cerraron los puertos que no son utilizados.
2.2.2 IMPLEMENTACIÓN DEL SERVIDOR DNS
2.2.2.1 Configuraciones generales Estas configuraciones se realizan desde el proceso de instalación del servidor hasta antes de la implementación de los servicios. El servidor DNS tiene las siguientes configuracions Nombre de la cuenta: Saramago Usuario de la cuenta: Saramago
Contraseña: Se sigue el estándar de Una letra mayúscula, números y simbolos. Dirección IP: 192.168.56.102 Durante el proceso de instalación de Gutsy Gibbon no se incluye ningún servidor de los que vienen incluidos en la distribución Se modifican los archivos motd, motd.tail, issue en, en el que se ubicó un mensaje en el cual se advierte que todas las acciones están siendo almacenadas.
root@tesis-desktop:# nano /etc/motd
root@tesis-desktop:# nano /etc/motd.tail
root@tesis-desktop:# nano /etc/issue
El servidor DNS real utiliza bind con la versión 9.2.4 en CentOS 5, aunque estas configuraciones variaron en función de la limitación de sebek, paquete que tiene implementación actualmente para ubuntu 7.10, lo que impide usar la versión antes mencionada de CentOS.
Se decidió implementar bind en esas condiciones, siguiendo este procedimiento:
1. Se configuran las características de la máquina virtual
1. Memoria principal 294 MB
2. Disco Duro 32 GB
2. Se instaló ubuntu server 7.10 Gutsy Gibbon
3. Se instala por defecto openssh-server y openssh-client.
4. Se descarga el archivo bind_9.2.4-3_i386.deb.
- El archivo está en formato RPM, así que se usa el programa alien para transformarlo en .deb y pueda ser instalable en ubuntu. Ver anexo J
5. Se instala bind9
6. Configurar DNS como Master Ver anexo K
1. Modificar archivo named.conf.local
2. Activar forwarders en named.conf.options
3. Crear zonas utpl.com y la inversa.
4. Reiniciar servicio
5. Probar servicio
7. Documentación
2.2.2.2 Reglas de firewall Ver Anexo I El servidor DNS tiene el firewall IPTABLES implementado, este servidor solamente permite el acceso a servicios de administración vía SSH y al servicio DNS, por lo que las reglas de firewall se configuraron acorde a estos parámetros, aunque también se habilitó el intercambio de paquetes entre el servidor utilizado para forward y se cerraron los puertos bien conocidos que no son utilizados en este servidor.
2.2.3 IMPLEMENTACIÓN DEL SERVIDOR EVA
2.2.3.1 Configuraciones generales Estas configuraciones se realizan desde el proceso de instalación del servidor hasta antes de la implementación de los servicios. El servidor DNS tiene las siguientes configuracions Nombre de la cuenta: gunter Usuario de la cuenta: gunter Contraseña: Se sigue el estándar de Una letra mayúscula, números y simbolos. Dirección IP: 192.168.56.104 Durante el proceso de instalación de Gutsy Gibbon se incluyó la instalación de Openssh que más adelante se necesitará, se utilizó este paso para ahorrar el paso de la instalación posterior. Se modifican los archivos motd, motd.tail, issue en, en el que se ubicó un mensaje en el cual se advierte que todas las acciones están siendo almacenadas.
root@tesis-desktop:# nano /etc/motd
root@tesis-desktop:# nano /etc/motd.tail
root@tesis-desktop:# nano /etc/issue
2.2.3.2 Instalación de Moodle 1.9.9 Ver Anexo H
Requerimientos: - Servidor Web: Apache - Base de datos: Mysql - Lenguaje: PHP
2.2.3.6 Reglas de firewall Ver anexo I El Entorno Virtual de Aprendizaje utiliza los servicios de Apache y Tomcat, el primero no tuvo ningún reparo al ser instalado, mientras que el segundo no está instalado por problemas de dependencia con el Ubuntu Server, de todas formas se abrió el puerto, se habilitaron los puertos 80 y 8080 además de permitir el envío y recepción de paquetes dns y cerrar los puertos que no son utilizados en el servidor.
2.2.4 IMPLEMENTACIÓN DEL SERVIDOR BAAN
2.2.4.1 Implementación El servidor BAAN no tiene implementado un firewall, aunque las aplicaciones Oracle 10 G Enterprise y Baan ERP 5.0c levantan los puertos 1521 y 512 respectivamente. Debido a que no se pudo instalar ninguno de los 2 servicios en la máquina virtual usada, debido a la limitación de sebek y al ser los dos servicios de licencia privada, se levanta el firewall IPTABLES para abrir los puertos antes mencionados, se permite también el intercambio de paquetes con el servidor DNS y se cerraron los puertos conocidos que no son utilizados por el servidor:
2.2.4.2 Reglas de firewall Ver Anexo I En el caso de este servidor solamente se ubicaron las reglas de firewall para tratar de indicar que se está utilizando los servicios de Oracle 10 G y el Baan ERP, aunque sin embargo no estén instalados, el resto de puertos está habilitados.
Documento completo disponible en: [1]
