Caratula Revista IngPDF - Dialnet · 2012. 6. 18. · Revista Facultad de Ingenier a, UPTC, Julio-Diciembre de 2 011, Vol.20, No. 31 ± CEDEC 39 I.INTRODUCCIÓN UnataquedeDenegacióndeServicio(Denialof

Revista Facultad de Ingeniería, UPTC, Julio-Diciembre de 2011, Vol. 20, No. 31 37– CEDEC

Evaluación de ataques UDP Flood utilizando escenariosvirtuales como plataforma experimentalUDP Inundation Attacks’ Evaluation, Using Virtual Environment asan Experimental Platform

Walter Fuertes*, Fernando Rodas**, Deyci Toscano**

Resumen

Los ataques por denegación de servicio (DoS) tienencomo propósito imposibilitar el acceso a los serviciosde una organización durante un periodo indefinido;por lo general, están dirigidos a los servidores deuna empresa, para que no puedan ser accedidos porusuarios autorizados. El presente trabajo se enfocaen la evaluación de ataques DoS tipo UDP Flood,utilizando como plataforma de experimentación unentorno virtual de red que permite identificar cómoactúan dichos ataques en la saturación del ancho debanda; para llevarlo a cabo se diseñó e implementóuna red híbrida con segmentación WAN, LAN yDMZ que inhabilita el acceso interno y externo a unservicio Web expuesto. Las herramientas evaluadasfueron UPD Unicorn, Longcat Flooder y UDPl.plScript de Perl; las dos primeras instaladas sobreWindows, y la última, sobre Linux. Para validar estáinvestigación se desarrolló un mecanismo de

Abstract

The Denial of Dervice Attacks (DoS) is used forprecluding access to services and resources from anorganization during an indefinite period of time.Usually, corporations apply DoS in their company’sservers, so they cannot be accessed by authorizedusers. This project focuses on the evaluation of UDPFloodDoS attacks, using as an experimental platforma virtual network environment, which enables toidentify how these attacks cause the Broadbandsaturation. In order to disable the internal andexternal access to an exposed Web service, a WAN,LAN, and DMZ segmentation network was designedand implemented.

The analyzed tools were: the UPD Unicorn, LongcatFlooder, and the UDPl.pl Perl Script. The first twowere installed in a Windows environment and thethird one was installed in a Linux. To validate this

ISSN 0121–1129

_________

* Ph.D. en Ingeniería Informática y de Telecomunicación, Ingeniero de Sistemas e Informática, Director de Postgrados, Escuela Politécnica delEjército, Sangolquí, [email protected]

** Facultadde Ingeniería de Sistemas, Escuela Politécnica Nacional, Quito, [email protected],[email protected]

Fecha de recepción: 14 de agosto de 2011

Fecha de aprobación: 19 de octubre de 2011

, pp.37-53

38 Revista Facultad de Ingeniería, UPTC, Julio-Diciembre de 2011, Vol. 20, No. 31– CEDEC

detección y mitigación de los ataques a nivel delfirewall e IDS/IPS, evitando de este modo lasaturación de la red. Finalmente, se evaluó elconsumodememoria, CPUy ancho de banda duranteel ataque, la detección y la evasión, con el fin dedeterminar cuál genera mayor impacto. Losresultados demuestran que el mecanismo detecta,controla y mitiga los ataques.

Palabras clave: Ataques de seguridad, Virtualiza-ción, Denegación de servicios, UDP Flood.

research a mechanism for detecting and mitigatingattacks a firewall and IDS/IPS levels was designedand implemented, thus avoiding the networksaturation. Finally, thememory, CPU, and broadbandconsumption during the attack, detection, and breakout, were calculated in order to determine whichgenerates the greatest impact. The results showedthat the implemented mechanism detects, monitors,and mitigates this type of attacks.

Keywords: Security Attacks, Virtualization, Denialof Services, UDP Flood.

Evaluación de ataquesUDP Flood utilizando escenarios virtuales como plataforma experimental


I. INTRODUCCIÓN

Un ataque de Denegación de Servicio (Denial ofService -DoS-) tiene el propósito de evitar que elusuario legítimo haga uso de un recurso o servicioespecífico de red o un host. Entre las variantes deeste tipo de ataque se pueden citar la inundación dela red mediante la inyección de paquetes,consumiendo el ancho de banda; la inanición derecursos, saturando la memoria; los errores deprogramación, para colapsar el procesador, y losataques DNS y enrutamiento, para convencermediante direcciones falsas y suplantación deidentidad. Para esta investigación se seleccionó elataque DoS UDP Flood, que provoca la pérdida dela conectividad de la red por la saturación del anchode banda; este ataque ocurre cuando un atacanteenvía paquetes IP con datagramas UDP, con elpropósito de colapsar el procesamiento de la máquinavíctima, hasta el punto de no permitir manejarconexiones legítimas; debido a la naturaleza sinconexión del protocolo UDP, este tipo de ataquessuele venir acompañado de técnicas de suplantaciónde identidad.

La comunidad científica ha investigado eimplementado mecanismos que permitan disminuiry mitigar estos ataques de seguridad, empleandotecnologías de virtualización, cuya aplicaciónpermite disminuir el riesgo a equipos y redes enproducción, precautelando la información y serviciosde las organizaciones. Los trabajos propuestos porKeller & Naues [1] y Ruíz et al. [2] presentanprototipos y modelos de laboratorios virtuales quepermiten disponer de múltiples máquinas virtuales,para poder dimensionar la cantidad y técnicas deataques. El trabajo propuesto por Jianga et al. [3]muestra el diseño, la implementación y la evaluaciónde Collapsar, que es una arquitectura basada enmáquinas virtuales para el centro de detención deataques de red. Abbasi & Harris [4], Fernández et.al. [5] y Galán et al. [6] presentan una metodologíapara establecer una honeynet, con el objetivo deidentificar las técnicas utilizadas por los atacantes.El trabajo propuesto por Moore et al. [7] expone latécnica análisis de backscatter, que proporciona unestimado de la actividad de ataques de Denegación

de Servicio (DoS). Otros trabajos [8, 9, 10] proponenla integración de las tecnologías de virtualizaciónpara el aseguramiento de una red, a través de laimplementación de un Sistema de Detección deIntrusos (IDS). Otros investigadores [11, 12, 13] hanutilizado las plataformas de virtualización paraimplementar técnicas de Recuperación de Desastres(DR).

En relación con la generación de varios ataques ycon los mecanismos demitigación, Fuertes et al. [14]presentan una investigación donde evalúan diversosataques reales de redes IP, con el fin de establecermecanismos de seguridad para mitigarlos. En unámbito similar, Yaar, Perrig & Song [15] presentanun filtro de flujo de Internet (Siff) que permitedetener selectivamente flujos individuales al llegara la red. Finalmente, el trabajo presentado porMirkovic & Reiher [16] propone D-WARD, unsistema de defensa contra ataques DDoS, cuyoobjetivo es la detección autónoma de estos.

El presente trabajo se enfoca en la evaluación deataques DoS tipo UDP Flood, utilizando comoplataforma de experimentación un entorno virtualde red que permita identificar cómo actúan dichosataques en la saturación del ancho de banda y cuálsería su impacto. Para llevarlo a cabo se diseñó eimplementó una red con segmentación WAN, LANy DMZ, con el propósito de inhabilitar el accesointerno y externo a un servicio Web expuesto. Lasherramientas evaluadas fueron UPD Unicorn [17] ,Longcat Flooder [18] y UDPl.pl Script de Perl [19];las dos primeras instaladas sobre un ambienteWindows, y la última, sobre un ambiente Linux. Paravalidar está investigación se desarrolló unmecanismo de detección y mitigación de los ataquesa nivel del firewall e IDS/IPS, evitando de este modola saturación de la red.

Entre las principales contribuciones de estainvestigación cabe mencionar: i) la evaluación deataques UDP Flood mediante tres herramientasgeneradoras, de cara a determinar cuál provocamayor impacto en la red, y ii) creación de reglas anivel de Firewall e IPS que permitan detectar ymitigar estos ataques.

Fuertes, Rodas, Toscano


El documento ha sido organizado como sigue: elcapítulo 2 presenta el fundamento teórico; en el 3 sedescribe el diseño y la configuración de la topologíade la red experimental utilizada para la evaluaciónde las herramientas de generación de ataques UDPFlood; en el 4 se presentan, analizan y evalúan losresultados; en el 5 se discuten los resultados y,finalmente, en el capítulo 6 se establecen lasconclusiones y se señala el trabajo futuro.

II. FUNDAMENTO TEÓRICO

A. Virtualización

Es la forma de particionamiento lógico de un equipofísico en diversas máquinas virtuales, para compartirrecursos de hardware, como CPU, memoria, discoduro y dispositivos de entrada y salida [20]; estoimplica hacer que un recurso físico, como unservidor, aparezca como si fuera varios recursoslógicos a la vez.

B. Escenario virtual de red

Puede ser definido como un conjunto de equiposvirtuales (tanto sistemas finales como elementos dered –enrutadores y conmutadores–) conectados entresí en una determinada topología desplegada sobreuno o múltiples equipos físicos, el cual emula unsistema equivalente y cuyo entorno deberá serpercibido como si fuera real [21]. El escenario virtualde red encapsula un conjunto de aplicaciones dentrode una red lógica, que permite configuraciones delos servicios de red de manera realista. En el caso deesta investigación, se ha utilizado este conceptoporque la virtualización es una tecnología potencialpara reproducir una topología de red real.

C. Denegación del servicio

De acuerdo con la World Wide Web Security FAQ[22], un ataque de Denegación de Servicio esdiseñado para que una computadora o una red nosean capaces de proveer los servicios normales. Losataques comunes de DoS tienen como objetivo elancho de banda de la red o su conectividad. En losataques de ancho de banda, la red es inundada por

un gran volumen de tráfico que conduce alagotamiento de los recursos de red disponibles, detal forma que usuarios legítimos no pueden accedera ellos. En los ataques de conectividad, uncomputador es inundado por un gran volumen desolicitudes de conexión que conduce a unagotamiento de todos los recursos del sistemaoperativo, por tanto, el computador no es capaz deprocesar las solicitudes de usuarios legítimos.

D. Tipos de ataques de denegación de servicios

Los ataques DoS pueden ser divididos en cincocategorías, basados en los niveles de protocoloatacados:l Ataques a nivel de dispositivo de red: causadosmediante el aprovechamiento de los errores odebilidades en el software o hardware, agotandorecursos de los dispositivos de red [23];

l Ataques a nivel de Sistema Operativo: tomanventaja de la forma de los protocolos que seimplementan en ellos; este ataca el InternetControl Message Protocol (ICMP) [24];

l Ataques a nivel de aplicaciones: aprovechan loserrores en las aplicaciones de red sobre los hostobjetivos o mediante el uso de aplicaciones paraconsumir los recursos de su víctima [25];

l Ataques de inundación de datos: utilizan el anchode banda disponible para una red, host o undispositivo en su mayor extensión mediante elenvío de cantidades masivas de datos porprocesar;

l7 Ataques basados en las características de losprotocolos: toman ventajas de las característicasdel protocolo.

E. Ataque UDP Flood

Un ataque UDP Flood es posible cuando un atacanteenvía paquetes UDP a un puerto randómico de unequipo víctima; cuando este recibe un paquete UDP,determina la aplicación que está esperando en elpuerto destino; si no existe ninguna aplicaciónesperando en el puerto mencionado, entonces generaun paquete ICMP de destino inalcanzable al origen.El envío excesivo de paquetes UDP puede producirla caída del sistema [26].



III. CONFIGURACIÓN DEL EXPERIMENTO

A. Herramientas

Para implementar este experimento se utilizaronherramientas de código abierto y de libredistribución; a continuación se detallan:

1) Sistema de virtualización: Como plataforma devirtualización se utilizó VMware Workstation [28]sobre Windows 7; su objetivo fue configurarmúltiples computadoras virtuales interconectadasentre sí, implementando un escenario virtual de red.

2) Firewall: Como firewall se utilizó PfSense [29],que es una distribución basada en FreeBSD; suobjetivo es disponer de un cortafuego que permitaestablecer seguridad entre zonas de confianza comoLAN y la DMZ. El PfSense permite proteger unared de accesos ilícitos, redirigir paquetes haciamáquinas de la red interna, otorgar accesos solodesde sitios conocidos, etc.; las conexiones SSH yHTTP fueron habilitadas para permitir laadministración de este desde una interfaz Web.

3) Sistema de Detección de Intrusos (IDS): ComoIDS se utilizó Snort [30], que está disponible dentrode la distribución de PfSense; su objetivo fue vigilarel tráfico de la red, examinar los paquetes en buscade datos sospechosos y detectar las primeras fasesde cualquier ataque. Las reglas básicas de Snortfueron descargadas y actualizadas desde su sitiooficial, utilizando el oinkcode obtenido después delregistro como usuario.

4) Web Server: Como servidor Web se utilizóApache2 [31] sobre la versión estándar de UbuntuServer; su objetivo fue servir páginasWeb solicitadaspor equipos cliente mediante el uso de navegadoresWeb. El módulo de seguridad mode_evasive fueinstalado para prevenir o anular ataques de DoS.Además, se integró el servidor Web con el servidor

de aplicaciones por medio del mod_jk de Apache.

5) App Server: Como servidor de aplicaciones seutilizó Tomcat 6 [32] sobre la versión estándar deUbuntu Server; su objetivo fue proporcionarservicios de aplicación a las computadoras clientes.La versión de jdk 1.6 fue instalada para habilitar elservidor de aplicaciones.

6) Herramientas para inyección de paquetes UDP:

Como herramientas para generación y envío depaquetes UDP se utilizó Longcat, UDP Unicorn yun script en Perl (UDPl.pl); las dos primerasfuncionaron sobre plataformasWindows, y la última,sobre cualquier distribución de Linux o Windowscon soporte Perl. El Firewall de Windows de lasmáquinas atacantes fue desactivado, y una regla anivel del Firewall fue agregada, con el objetivo depermitir pasar un gran volumen de paquetes UDP.

7) Captura de tráfico: Como herramientas paracaptura de tráfico se utilizó Tcpdump [33] yWireshark [34] sobre el Firewall y el Web Serverrespectivamente; su objetivo fue identificar yanalizar el tráfico que circula por la red, analizar lospaquetes de datos en una red activa desde un archivode lectura previamente generado.

B. Diseño de la topología experimental

La generación de ataques de Denegación deServicios, DoS, utilizando UDP Flood, y sumecanismo de mitigación requirieron de la creaciónde una infraestructura de red similar a la utilizadapor cualquier red en producción. Es así que para eldiseño e implementación de la topología de pruebase requirió de un enrutador que posibilitó la salida aInternet, un computador con Windows7 y un equipoanfitrión de Virtualización que permitió crear losdiferentes componentes de la implementación,convirtiéndola en una plataforma híbrida, tal comose muestra en la Fig. 1.



Fig. 1. Diseño para la generación y mitigación de ataques UDP Flood

C. Implementación de la plataforma experimental

Las pruebas se ejecutaron en el equipo anfitriónVMware, bajo Windows7, con procesador Core5,memoria 4Gb y almacenamiento 500 Gb. En lasmáquinas virtuales se instaló pfSense FreeBSD comofirewall, Ubuntu Server 10.10 como Web Server,Ubuntu Server 10.10 yWindows XPcomo estacionesde trabajo.

El siguiente procedimiento ha sido utilizado paraimplementar el diseño propuesto en un entornovirtual: i) En primer lugar, se ha sincronizado el relojmediante el protocolo de temporización de red (NTP)en el equipo anfitrión; ii) Luego se ha creado laprimera máquina virtual VMware, en la cual se hainstalado el sistema operativo FreeBSD con Pfsensecomo firewall y con Snort como IDS/IPS,configurando tres interfaces de red (WAN, LAN yDMZ); iii) Posteriormente, se ha creado una segundamáquina virtual VMware, en la cual se ha instaladoel sistema operativo Ubuntu Server con Tomcat 6como servidor de aplicaciones, yApache2 comoWebserver, configurando una sola interface de red en laDMZ; iv) A continuación, se ha clonado la segundamáquina virtual, con el fin de reducir el tiempo de

instalación y con la finalidad de administrar elfirewall desde la LAN. Adicionalmente se instaló elprograma Udpl.pl Script de Perl para generar ataquesdesde la LAN; v) Luego, se ha creado una terceramáquina virtual VMware, en la cual se ha instaladoel sistema operativo Windows XP y los programasLongCat Flooder y UDP Unicorn de forma quepermitan generar ataques desde la LAN, y,finalmente, vi) Se ha conectado con una estación detrabajo externa, en la cual se ha instalado el sistemaoperativo Windows XP y los programas LongCatFlooder y UDP Unicorn de forma tal que se puedangenerar ataques desde la WAN.

En este punto cabe señalar que el enrutador de laFig. 1 es un dispositivo físico que conecta al equipoanfitrión tanto hacia el Internet como a las máquinasvirtuales.

D. Configuración del firewall

Para la conexión de los segmentos de red detalladosen la Fig. 1 se requirió la creación de un mecanismode mitigación basado en reglas a nivel de firewallque permitieron redirigir los paquetes de LAN a laWAN y viceversa (ver Fig. 2).



Para la publicación del servicioWeb se requirió crearuna regla de traducción de direcciones de red (NAT,Network Address Translation) dentro del firewall, lacual permitió redirigir los paquetes de la DMZ a laWAN y LAN, habilitando el acceso al servicio desdela red interna y red externa. Además, se requirió creardos reglas dentro del Snort que permitieron filtrartodos los paquetes provenientes de la WAN y LAN ala DMZ, bloqueando la IP origen y generando alertasen la consola administrativa del Snort.

Debido a que los servidores y estaciones de trabajose agrupan en segmentos de redes diferentes dentrode la LAN, DMZ y WAN fue necesario definir 3interfaces de red virtuales, que se detallan acontinuación (ver Fig. 2):

l Interface “em0” (en eth0): es una interfaceVWware tipo puente (brigde) apuntando a la redexterna WAN y conectada al enrutador para

permitir el acceso a Internet;l Interface “em1” (en eth1): es una interfaceVMware tipo bridge apuntando al segmento dered interna LAN;

l Interface “em2” (en eth2): es una interfaceVMware tipo bridge apuntando al segmento dered de la zona desmilitarizada DMZ.

E. Generación de ataques

La generación de ataques UDP Flood se realizóejecutando los programas UDP Unicorn y LongCatFlooder en una máquina virtual con Windows XPdesde la LAN, para un primer caso (interno), y enuna estación de trabajo con Windows XP desde laWAN, para un segundo caso (externo). Además, serealizó un tercer caso ejecutando el script de perlUdpl.pl en una máquina virtual con Ubuntu Serverdesde la LAN. Para todos estos ataques fue necesarioconfigurar los siguientes parámetros: dirección IP

Fig. 2. Configuración de firewall



de la máquina víctima (Web Server), tamaño delpaquete y número de hilos.

Estos ataques se caracterizaron por generar unconsiderable volumen de tráfico en la red y porcomprometer la disponibilidad del servicio Webexpuesto para usuarios legítimos. Este volumen seevidenció comparando la cantidad de paquetesrecibidos utilizando Tcpdump y la disponibilidad alobservar un consumo de recursos de CPU, RAM,memoria virtual a través de las herramientas delsistema operativo.

IV. RESULTADOS EXPERIMENTALES

Para el monitoreo de los paquetes inyectadosgenerados por las herramientas de ataques UDPFlood se tomaron algunas mediciones de cada unade ellas, considerando, en un primer caso, un ataquegenerado desde la red interna, y, en un segundo caso,generado desde la red externa.

Se realizaron pruebas para cada herramienta y cadacaso con 15, 30 y 45 hilos.Acontinuación se tomaronlos datos de consumo de CPU, memoria, memoriavirtual, paquetes enviados y paquetes recibidosutilizando el Monitor del Sistema y Tcpdump [33];

estas lecturas fueron tomadas cada minuto duranteun período de 15 minutos. Una vez realizadas las 5pruebas de cada herramienta se calcularon lospromedios para cada minuto, y con esos valores segeneraron las figuras que se analizan a continuación.

A. Ataque de DoS con UDP Unicorn

Para realizar este ataque de DoS se utilizó comoherramienta UDP Unicorn, que es un utilitario decódigo abierto escrito en lenguaje C, para win32 demultihilos queutiliza librerías deWinSock para crearsockets UDP e inundar la máquina víctima [17].

La Fig. 3 muestra el consumo de CPU, memoriafísica y memoria virtual para ataques realizados con15, 30 y 45 hilos. Como se puede observar, el CPUse vio saturado y no podía procesar peticiones alrealizar un ataque con 15 hilos a los 13 minutos, con30 hilos a los 9 minutos y con 45 hilos a los 7minutos. Así mismo, la memoria física se viosaturada al realizar un ataque con 15 hilos a los 8minutos, con 30 hilos a los 5 minutos y con 45 hilosa los 3 minutos. Por último, la memoria virtual sevio saturada al realizar un ataque con 15 hilos a los16 minutos, con 30 hilos a los 9 minutos y con 45hilos a los 7 minutos.

Asímismo, la memoria física sevio saturada al realizarun ataque con 15 hilos a los 8 minutos, con 30 hilos alos 5 minutos y con 45 hilos a los 3 minutos. Por

último, la memoria virtual se vio saturada al realizarun ataque con 15 hilos a los 16 minutos, con 30 hilosa los 9 minutos y con 45 hilos a los 7 minutos.

Fig. 3. Tiempo de saturación de recursos para UDP Unicorn

18

16

14

12

10

8

6

4

2

0

cpu Memoria Memoria virtual

Tiempounmin

15 hilos

30 hilos

45 hilos



Al aplicar el mecanismo de mitigación (ver Fig. 4) sepuede apreciar que las cantidades de paquetescapturados y borrados son similares, mientras que loscapturados sean de 15, 30 y 45 hilos, prácticamente

son iguales; esto indica que con UDP Unicorn elfirewall acepta cierta cantidad y luego lo bloquea yno acepta ningún paquete más que venga de lamáquina atacante.

B. Ataque de DoS con Longcat Flooder

Para un ataque tipo DoS también se puede utilizarLongcat Flooder, herramienta de inundaciónmultiprotocolo que ha llegado a ser popular debido asu simplicidad de uso y sus características. Losprotocolos soportados sonTCP (SYN flooding), UDPyHTTP [18].

La Fig. 5 muestra el consumo de CPU,memoria físicay memoria virtual para ataques realizados con 15, 30y 45 hilos. Como se puede apreciar, el CPU se viosaturado y no podía procesar peticiones al realizar unataque con 15 hilos a los 16 minutos, con 30 hilos alos 12 minutos y con 45 hilos a los 8 minutos. Lamemoria física se ve saturada al realizar un ataquecon 15 hilos a los 8 minutos, con 30 hilos a los 5minutos y con 45 hilos a los 3 minutos. Por último, lamemoria virtual se ve saturada al realizar un ataquecon 15 hilos en 16 minutos, con 30 hilos en 9 minutosy con 45 hilos a los 7 minutos.

Con los datos capturados por Tcpdump, se pudodeterminar que la cantidad de paquetes fuedirectamente proporcional al número de hilos, esdecir, a mayor número de hilos, mayor será lacantidad de los paquetes capturados y recibidos,

mientras no existen paquetes borrados, como sepuede ver en la Fig. 6.

C. Ataque de DoS con script en Perl

La tercera herramienta utilizada para un ataque tipoDoS en este trabajo de investigación fue la realizacióndeun script tomado desde flood.pl. Para la instalaciónse realizó la copia del archivo fuente en flood.pl, ycomo requisitos previos, la distribución de PERL 5.8,por lo general preinstalado en un sistema Unix / Linux[19].

La Fig. 7 muestra el consumo de CPU, RAM ymemoria virtual para ataques realizados con 15, 30 y45 hilos. Tal como se puede observar, el CPU se viosaturado y no podía procesar peticiones al realizar unataque con 15 hilos a los 9 minutos, con 30 hilos a los6 minutos y con 45 hilos a los 6 minutos. La RAM seve saturada al realizar un ataque con 15, 30 o 45 hilosa los 4 minutos.

Al aplicar el mecanismo demitigación y con los datoscapturados por Tcpdump, se pudo determinar que lacantidad de paquetes durante los 15 minutos es solode recepción, ya que los datos capturados y borradosson casi nulos, como se puede ver en la Fig. 8.

Fig. 4. Cantidad de paquetes procesados con Tcpdump para UDP Unicorn

45

40

35

30

25

20

15

10

5

0

Capturados Recibidos Borrados

CantidadenGb

15 hilos

30 hilos

45 hilos



Fig. 5. Tiempo de saturación de recursos para Longcat Flooder

18

16

14

12

10

8

6

4

2

0

cpu Memoria Memoria virtual

Tiempoenmin

15 hilos

30 hilos

45 hilos

Fig. 6. Cantidad de paquetes procesados para Longcat Flooder

15 hilos

30 hilos

45 hilos


Fig. 7. Tiempo de saturación de recursos para UDPl_perl

15 hilos

30 hilos

45 hilos

Cpu Memoria Memoria virtual



D. Análisis comparativo de las tres herramientas

utilizadas

Luego de analizar el comportamiento de las tresherramientas fue necesario compararlas paradeterminar la que mayor riesgo e impacto genera ala red de una organización:

1) Comparación del consumo del CPU: Se observóque Longcat Flooder fue la herramienta que enmayorporcentaje hizo uso del CPU, y fue constante duranteel ataque. La herramienta Udpl_perl saturó el usode CPU en el momento inicial del ataque y fuedisminuyendo rápidamente. Finalmente, UDP

Unicorn tuvo un consumo intermedio entre las dosherramientas anteriores, como se puede observar enlas Figs. 9, 10 y 11. Nótese además que al minuto 8el porcentaje de uso del CPU es muy bajo, esto sedebió a que el firewall filtró los paquetes, bloqueóla IP de la máquina atacante y generó alertas en laconsola administrativa del IDS.

2) Comparación del uso de memoria real: Alcomparar el consumo de memoria, se observó quees la más afectada para este tipo de ataque; es asícomo en un promedio de 6 a 7 minutos la máquinavíctima ya tenía saturada su RAM (consumo al100%), como se puede ver en las Figs. 12, 13, y 14.

Fig. 8. Cantidad de paquetes procesados para Script UDPl_perl

15 hilos

30 hilos

45 hilos


Fig. 9. Comparación del consumo de CPU con 15 hilos

15 hilos

longcat

udpl_perl

unicorn




Fig. 12. Comparación del consumo de la memoria con 15 hilos

15 hilos

longcat

udpl_perl

unicorn

Fig. 10. Comparación del consumo de CPU con 15 hilos

30 hilos

longcat

udpl_perl

unicorn

Fig. 11. Comparación del consumo de CPU de las tres herramientas

45 hilos

longcat

udpl_perl

unicorn


Es necesario mencionar que a pesar de que el IDSdetuvo el ataque evitando el paso de paquetes hacia lamáquina víctima, el uso de memoria se mantiene enlos niveles más elevados, y el proceso de restauración(niveles estables de uso de CPU y memoria) tomó unperíodo de aproximadamente 1 hora.

3) Comparación de la memoria virtual:Al analizar el

uso de la memoria virtual, se observó que los tiempospara la saturación fueron menores a medida queaumentaba el número de hilos, como sepuede observaren las Figs. 15, 16 y 17. Amedida que se incrementa elnúmero de hilos para cada herramienta, elcomportamiento tiende a ser muy similar, así, al tener45 hilos, las 3 herramientas llegan al 100% de uso dememoria al minuto 7.


Fig. 14. Comparación uso de memoria con 45 hilos

45 hilos

longcat

udpl_perl

unicorn

Fig. 13. Comparación del uso de la memoria con 30 hilos

30 hilos

longcat

udpl_perl

unicorn



Fig. 15. Comparación uso de memoria virtual con 15 hilos

15 hilos

longcat

udpl_perl

unicorn

30 hilos

longcat

udpl_perl

unicorn



45 hilos

longcat

udpl_perl

unicorn


V. DISCUSIÓN

Como se muestra en las figuras del capítulo deResultados, la generación de ataques de denegaciónde servicios utilizando Longccat, UDP Flooder yScript de Perl con procesamiento multihilo provocala inundación de la red y el máximo consumo derecursos de la máquina víctima, es así como en unlapso menor a 10 minutos, y teniendo inactivas lasreglas del IDS, la máquina víctima no es capaz deprocesar peticiones de usuarios legítimos. Elproblema de saturación de la red puede agudizarse,aún más, a medida que se incremente el número dehilos concurrentes y se elimine el tiempo de esperaentre hilos de ejecución. La evaluación de estasherramientas para detectar y medir ataques UDPFlood traerá beneficios a los administradores yencargados de la red debido a que permitirá alertary dimensionar el tráfico y tipo de paquetes generadospor este tipo de ataques.

Las estadísticas obtenidas en este trabajo deinvestigación permitieron diseñar un esquemaefectivo de mitigación, que fue configurado a nivelde Firewall e IDS. La aplicación de este diseño demitigación traerá beneficios inmediatos a losadministradores y encargados de la red, debido a lafacilidad del establecimiento de reglas a nivel deFirewall e IDS.

Como limitante, existe la necesidad de manteneractualizada la base de reglas del IDS, dado que sepueden presentar más tipos de ataques o variacionesde estos. Esto se puede resolver con la subscripciónal sitio oficial de Snort [30], de donde, por un pagoespecial, se pueden descargar mensualmente lasreglas actualizadas, facilitando la administración ycreando un mecanismo de protección seguro para lared de la organización.

Los valores presentados en este trabajo deinvestigación son referenciales y dependen de lascapacidades de la máquina anfitrión en donde selevantaron todos los componentes del ambiente deexperimentación.

Una de las mayores ventajas que presenta el presente

trabajo fue la creación de un entorno virtual dondese puede reproducir la funcionalidad de una red deservicios telemáticos; esto facilitó la evaluación dealgunos escenarios de experimentación o pruebas yla validación de algunas herramientas relacionadascon un ataque de Denegación de Servicios. El usode entornos virtuales permite la ejecución de pruebasde seguridad informática, el ahorro de tiempo y ladisminución de costos de experimentación, encomparación con pruebas en un escenario conequipos reales.

Finalmente, después de realizado el análisiscomparativo entre las herramientas que generanataques UDP Flood se identifica que el Script dePerl es la herramienta que mayor consumo de anchode banda genera y, por tanto, mayor saturación alequipo y a la red dentro de nuestro ambiente deexperimentación; esto se debe a que establece unaconexión y escritura nativa de bytes que, junto alprocesamientomultihilo, tamañomáximo de paquetey no definición de tiempo de espera entre hilos deejecución, consigue el mayor consumo de recursos.

VI. CONCLUSIONES Y TRABAJO FUTURO

El presente trabajo se enfocó en el análisis yevaluación de herramientas que generan ataques DoSde tipo UDP Flood dentro de un ambientevirtualizado, con el fin de mejorar las técnicas deseguridades ante este tipo de ataques. Paraimplementar este trabajo se creó una topología dered virtual segmentando los accesos por la LAN,WAN y DMZ y obteniendo el ambiente virtualnecesario para generar ataques de UDP Flood conherramientas como UDP Unicorn, Longcat Floodery UDPl.pl Script desarrollado en Perl. Para validaresta investigación se desarrolló un mecanismo dedetección y mitigación de los ataques a nivel delfirewall e IDS/IPS, evitando de este modo lasaturación de la red. Sobre la máquina víctima serealizó el análisis de consumo de CPU, memoria yancho de banda. Los resultados demuestran que elmecanismo detecta, controla y mitiga estos ataques.

Como trabajo futuro se plantea realizar el análisispara herramientas deDoS de tipo SYN Flood, HTTP



Flood e ICMP Flood, con el fin de identificar el tipode inundación que mayores daños provoque al anchode banda de una red corporativa.

AGRADECIMIENTOS

Los autores de este proyecto desean agradecer a laEscuela Politécnica Nacional, Facultad de Ingenieríade Sistemas y a la Dirección de Posgrados de laEscuela Politécnica del Ejército por las facilidadesprestadas durante el desarrollo de esta investigación.

REFERENCIAS

[1] J. Keller, R. Naues. Design of a virtualcomputer security lab. Fern Universititat inHagen-Germany. Available: http://www.fernuniversitaet-hagen.de/imperia/md/content/fakultaetfuermathematikundinformatik/pv/97-08/547-045_1_.pdf

[2] J. Ruiz, D. Fernández, F. Galán, L. Bellido.Modelo de Laboratorio Docente de Telemática

basado en Virtualización Distribuida.Universidad Politécnica de Madrid.

[3] X. Jianga, D. Xua, Y. Wang. “Collapsar:AVM-based honeyfarm and reverse honeyfarmarchitecture for network attack capture anddetention”. Journal of Parallel and DistributedComputing (2006) Volume 66, Issue 9, pages

1165-1180. Available: http://www.mendeley.com/research/collapsar-a-vmbased-honeyfarm-and-reverse-honeyfarm-architecture-for-network-attack-capture-and-detention/

[4] F. H. Abbasi, R. J. Harris. Experiences with aGeneration III Virtual Honeynet. School ofEngineering and Advanced Technology(SEAT), Massey University, New Zealand.

[5] H. Fernández, J. Sznek, E. Grosclaude.Detección y limitaciones de ataques clásicos

con Honeynets virtuales. Publicado en el VCongreso de Seguridad Informática 2009,(CIBSI’09), realizado del 16 al 18 de noviembrede 2009, Montevideo, Uruguay.

[6] F. Galán, D. Fernández. Use of VNUML inVirtual Honeynets Deployment. IX Reuniónespañola sobre criptología y seguridad de lainformación (RECSI), Barcelona, pp. 600-615,Sep. 2006. ISBN: 84-9788-502-3.

[7] D. Moore, G. Voelker and S. Savage. InferringInternet Denial-of-ServiceActivity. Departmentof Computer Science and EngineeringUniversity of California, San Diego.

[8] P. Li, T. Mohammed. Integration of

Virtualization Technology into Network

Security Laboratory. In Proc. 38thASEE/IEEEFrontiers in Education Conference, Saratoga,NY, 10/2008.

[9] T. Garfinkel and M. Rosenblum. A VirtualMachine Introspection Based Architecture for

Intrusion Detection. In Proc. Network andDistributed Systems Security Symposium, pp:{191-206}, 2003.

[10] K. Ali. Algorizmi: A Configurable VirtualTestbed to Generate Datasets for Offline

Evaluation of IDS. Electronic Theses andDissertations, University of Waterloo, 2010.

[11] E. Damiani, F. Frati, D. Rebeccani. The opensource virtual lab: a case study. In proceedingsof the workshop on free and open sourcelearning environments and tools, hosted by:FOSLET 2006; pp. 5-12, Italy nel, 2006.

[12] Co-innovation lab Tokyo. Disaster RecoverySolution Using Virtualization Technology,White paper. Available: http://www.cisco.com/en/US/prod/collateral/ps4159/ps6409/ps5990/N037_COIL_en.pdf.

[13] P. Ferrie P. “Attacks on Virtual MachineEmulators”, Symantec White Paper, 2008.

[14] W. Fuertes, P. Zapata, L. Ayala y M. Mejía.Plataforma de Experimentación de Ataques

Reales a Redes IP utilizando Tecnologías de

Virtualización, Memorias del Tercer Congreso



de Software Libre CONASOL-2010. Talara,Perú, dic. 2010.

[15] A. Yaar, A. Perrig, D. Song. SIFF: “A StatelessInternet FlowFilter toMitigate DDoS Flooding

Attacks”, C. Mellon University.

[16] J. Mirkovic, P. Reiher.D-WARD:A Source-EndDefense Against Flooding Denial-of-Service

Attacks. IEEE.

[17] UDPUnicorn.Available: http://sourceforge.net/projects/UDPunicorn/

[18] Longcat Flooder. Available: http://partyvan.info/wiki/Longcat_Flooder

[19] Perl flood script. Available: http://sourceforge.net/projects/freeman015/

[20] F. Galán, D. Fernández, W. Fuertes, M. Gómezand J. E. López de Vergara. Scenario-basedvirtual network infrastructure management in

research and educational test beds with

VNUML. Annals of Telecommunications, Vol.64, No. 5, pp. 305-323, May 2009.

[21] W. Fuertes and J. E. López de Vergara. Anemulation of VoD services using virtual network

environments. In Proc.GI/ITG Workshop onOverlay and Network Virtualization, Kassel-Germany, March 2009.

[22] S. Lincoln D. & J. N. Stewart. The World WideWeb Security FAQ, Available: http://www.w3.org/Security/Faq/

[23] D. Karig and R. Lee. Remote denial of serviceattacks and countermeasures. Technical ReportCE-L2001-002, Department of Electrical

Engineering, Princeton University, Princeton,NJ, Oct. 2001.

[24] M. Kenney. Malachi, “ping of death”.Available: http://www.insecure.org/sploits/ping-o-death.html, Jan. 1997.

[25] Finger bomb recursive request, http://xforce.iss.net/static/47.php.

[26] L. D. Stein and J. N. Stewart. The World WideWeb Security FAQ, versión 3.1.2. Available:http://www.w3.org/Security/Faq, Feb. 2002.

[27] NetworkDicctionary. [Online]. Available: http://www. networkdictionary.com/security/u.php,Nov. 2005.

[28] VMWare: http://www.vmware.com/. Últimacomprobación, junio 2011.

[29] Pfsense: http://www.pfsense.org/. Últimacomprobación, junio 2011.

[30] Snort: https://www.snort.org/. Últimacomprobación, junio 2011.

[31] Apache: http://apache.org/. Últimacomprobación, junio 2011.

[32] Apache Tomcat: http://tomcat.apache.org/download-60.cgi. Última comprobación junio2011.

[33] Tcpdump: http://www.tcpdump.org/. Últimacomprobación, jun. 2011.

[34] Wireshark: http://www.wireshark.org/. Últimacomprobación, jun. 2011.



Documents

Caratula Revista IngPDF - Dialnet · 2012. 6. 18. · Revista Facultad de Ingenier a, UPTC, Julio-Diciembre de 2 011, Vol.20, No. 31 ± CEDEC 39 I.INTRODUCCIÓN UnataquedeDenegacióndeServicio(Denialof