Ahora bien el marco de trabajo propuesto es la implementación de una aplicación firewall en

un controlador sdn ejecutando las especificaciones de openflow 1.5, para la simulación se van
a utilizar cuatro switches con openflow habilitado, mientras que Ryu será utilizado para el
controlador SDN. Se buscará implementar reglas de firewall que permitan o bloqueen
paquetes de acuerdo a la información de la cabecera tales como la Mac de destino/fuente
direcciones IP, número de puertos entre otros. Estas reglas firewall van a estar basadas en los
campos de coincidencia especificados en la versión 1.5 de openflow (44) – openflow 1.0 (12)

La aplicación firewall consiste en cuatro componentes principales el modo del firewall el

comando de traducción REST, la lista de switches y las reglas de firewall.

El módulo firewall recolectará información sobre los switch conectados en la red que ayudará
al administrador de red poder configurar reglas para cada switch en particular, y esto mientras
la aplicación firewall continuamente monitoreará las listas de control de acceso instalados en
las switches para asegurarse de que no haya ningún tipo de modificación externo ni interno

El módulo de comando traducción red decodificará los comandos recibidos de las interfaces de
usuario y notificará al módulo firewall tomando las acciones correspondientes las cuales
incluirán configuración de reglas, modificación o eliminación de reglas existente, habilitación
de diferentes dispositivos de switching para funcionalidades de firewall, entre otros.

El módulo firewall mantiene dos listas: las reglas de firewall y las listas de switches, la lista de
switches tiene un identificador de ruta de 16 dígitos de todos los switches disponibles en la red
y ayuda al administrador de red para poner reglas de firewall en un switch en particular.

La lista de reglas de firewall contiene las políticas de seguridad de la red y consiste en un

conjunto de reglas separadas para cada switch o VLAN en particular.

En el plano de datos cada switch posee una lista de control de acceso y llenada cierta cantidad
de reglas de firewall que las manda la aplicación firewall, estas reglas de firewall son basadas
en los campos de coincidencia especificados por la versión openflow 1.5.

Para la simulación del espacio de prueba SDN se crearon 5 máquinas virtuales en una
topología tipo árbol, el controlador RYU fue instalado en una máquina virtual y el resto de
máquinas virtuales fueron utilizadas como máquinas de usuarios, la aplicación firewall fue
instalado y ejecutado en la maquina virtual del controlador RYU, (PC D = máquina de prueba,
ahí se realizan las mediciones), el espacio de simulación es evaluado para 3 diferentes
escenarios el primero es utilizando 3,2 y 1 switches con reglas de firewall con el fin de analizar
el desempeño de múltiples cargas de los switches con las reglas de firewall, asimismo cada
ambiente de prueba utilizara tanto tráfico TCP udp e icmp, para ello se utilizará la herramienta
D- ITG (Distribuidted Internet Traffic Generation), el retardo promedio y en jitter promedio
para los paquetes icmp Y UDP también serán monitoreados con la misma herramienta.

Inicialmente las reglas de firewall serán cargados al switch como lista de control de acceso, las
cuales bloquearán todos los paquetes TCP en la red, tan pronto como la regla de firewall sean
cambiadas para permitir estos paquetes la respuesta cambiará como se muestra en la figura.
Por otro lado con el fin de medir el jitter en el tráfico UDP se han generado múltiples flujos
simultáneamente los cuales transmitirán 1MB de información aleatoria por cada flujo con un
tamaño de paquete de 1500 bytes, esto generará un número de flujos de entre 10 a 200. En la
figura superior se muestra la relación que entre el número de flujos y la cantidad de jitter, la
cantidad de jitter en milisegundos incrementa rápidamente con el incremento del número de
flujos pero en un número alto de flujos esta cantidad aumenta en menor grado, mientras que
en la figura inferior describe la relación entre el retraso en el tráfico icmp con el número de
flujos simultáneos a través de diferentes números de switch como se observa el número de
flujos incrementa con la cantidad de red de retraso incrementa indicando congestión en la red.

Finalmente se concluye con la importancia de SDN y el protocolo openflow en cuanto a las

flexibilidad de la red a través de la programabilidad para la seguridad de las redes, el firewall
propuesto es validado en plataformas de simulación y la implementación de firewalls en
versiones como openflow 1.5 eleva la esperanza de que se incluya en versiones. Posteriores de
openFlow para mejorar ciertos temas de seguridad aparte de la implementación de políticas
de seguridad la aplicación de seguridad podrían incluir características como inspección de
paquete detección de intrusos y mejoras de seguridad en la red.
2--------------------------------------------------------------------------

El controlador sdn provee de múltiples funcionalidades las cuales pueden ser usadas para
implementar firewalls definidos por el usuario sin comprar una licencia de firewall o un
hardware físico los cuales al menos son muy costosos, existen dos controladores que son
tradicionales en cuanto a las implementaciones sdn las cuales son Pox basado en Python y
open light basado en Java.

Para este proyecto se han usado plataformas virtuales como virtualbox ejecutando sistemas
operativos Windows 10 y se han creado dos máquinas virtuales separadas teniendo a los dos
controladores ya mencionados open day light y pox con el fin de comparar las salidas entre los
dos mientras se utilizan scripts de firewalls definidas en el controlador. Asimismo, se ha usado
la herramienta IPERF la cual es muy popular en cuanto a las mediciones de ancho de banda
para comparar las salidas de ambos controladores en diferentes condiciones de medida

El experimento principal fue hecho parecer una red virtual con el fin de probar reglas de
firewall idénticas en dos diferentes controladores pox y ODL y comparar el desempeño de
ambos para la simulación de red se ha utilizado mininet que es un emulador que visualizará la
red completa también se ha usado una topología de prueba que tiene un solo switch
conectado a múltiples hosts luego se va a bloquearán la comunicación entre 2 host específicos
utilizando política de firewall entonces con la presencia de estas políticas se harán las
mediciones de la salida de ambos controladores y se establecerá una comparación entre sus
valores promedios. Sin embargo un factor importante a tener en cuenta es sobre las
limitaciones basadas en el espacio de prueba que crea mininet ya que no puede exceder el
ancho de banda o la potencia de procesamiento del servidor además a veces el controlador
puede no ser detectado al ser incorporado externamente.

Para las pruebas se establece al host 1 como cliente y a host 3 como servidor, ambos host se
comunicarán a través del puerto 5566 el cual será definido también en el controlador y se
tomarán las mediciones de ancho de banda utilizando la herramienta y IPERF varias veces con
intervalos de tiempo de un milisegundo

En cuanto los resultados tomando mediciones sin límite de ancho de banda para intervalos de
tiempo de 10, 20 y 30 segundos como resultado de esto tenemos que el controlador ODL
alcanza un valor medio de 32.75 gigabits por segundo el cual es más alto que el controlador
box el cual alcanzó solamente 25.07 gigabits por segundo, Por otro lado también se realizaron
mediciones de jitter y pérdida de paquetes en transmisiones UDP para diferente valor de
ancho de banda tomando mediciones en 500, 600, 700, 800 y 1000 Mbps como resultado de
esto se tiene que el valor medio de Pox se encuentra en 0.1106% en pérdida de paquetes
mientras que o di l tiene un valor de 0.048%.

Se llega a la conclusión de que open day light tiene una menor pérdida de paquetes teniendo
un mejor desempeño que Pox , el jitter también es relativamente más bajo en open day light
que en Pox, el valor más alto obtenido para este es 0.038 y para open day light es 0.034 por
tanto open day light tiene mayor consistencia en menores valores de jitter y menor variación
de latencia en cuanto a transferencia de paquetes.
4--------------------------------------------------------------------------------------------------------------

Este trabajo de investigación se centra principalmente en la protección contra 3 ataques

específicos el ping flood (PF) el cual ocurre cuando se envían paquetes icmp request
sobrecargando el host objetivo el cual tendrá de responder a estos paquetes, se tiene también
el ataque ping of death (PoD) cuál es un paquete icmp desnaturalizado y que tiene un gran
tamaño causando también una sobrecarga en el host, por último se tiene el ataque Black nurse
el cual tiene la capacidad sobrecargar dispositivos de red incluidos firewalls enviando tráfico
de entre 15 a 25 megabits como una promedio de paquetes de 40 KA 50 k, este ataque
combina los dos ataques anteriores mencionados ya que envía una cantidad grande de Icmp
request y que a su vez estos tienen un gran tamaño.

Tomando en cuenta el controlador ONOS utilizaremos la aplicación oneping ,esta aplicación

permite hacer un ping de un host a otro solamente una vez después de 60 segundos se podrá
permitir hacer un ping nuevamente. el objetivo de esta aplicación es proteger contra ataques
Ping Flood, la desventaja es que permite cualquier otro paquete como resultado los atacantes
pueden reconocer nuestra red, peor aun actualmente los ataques Black nurse llevan también
adicionalmente ataques ping flood y ping of death por tanto en este trabajo de investigación
se propondrá protecciones de firewall utilizando el controlador ONOS para estos ataques
mejorando la aplicación existente oneping

La aplicación firewall agregará algunos códigos a la aplicación oneping para archivos de política
y match de paquetes entrantes con reglas contenidas en el archivo de políticas.

El algoritmo a utilizar va a determinara si la fuente y dirección de destino del paquete son

compatibles con la regla predefinida, se permitirá al paquete realizar el ping una vez de
cualquier otra forma el paquete será bloqueado, ahora después de permitir los paquetes la
aplicación revisa que la carga del paquete no sea mayor que el valor límite preestablecido
teniendo un límite teorico para el paquete IP de 65535 bytes incluyendo la cabecera IP de 20
bytes y la cabecera icmp de 8 bytes teniendo un valor de carga 65507 sin embargo el valor
límite para el tamaño del paquete ping en esta investigación será definido como 56 bytes
debido a que es un valor común de tamaño para un paquete ping solo si el tamaño del
paquete entrante es menor que el valor límite el paquete será permitido de cualquier otra
forma se bloqueará asumiendo que es un ataque Ping OF DEAD, los paquetes serán
comparados con una regla después de otra desde arriba hacia abajo, hasta que la regla de
compatibilidad sea encontraba y el proceso será detenido.

Se concluye teniendo que los firewalls son un excelente mecanismo de seguridad en tanto
redes tradicionales como en redes SDN ya que se puede establecer una barrera segura entre
un ambiente interno y externo, Por otro lado el controlador ONOS está desarrollado para
permitir un control de varias plataformas de redes en por tanto es esencial el desarrollo de
aplicaciones de seguridad en este tipo de controlador, en este trabajo se utilizó la aplicación
oneping para filtrar paquetes de CAPA 2, sin embargo esto se puede extender a una aplicación
firewall la cual puede filtrar no solo paquetes icmp sino paquetes TCP IP udep entre otros.
3--------------

Pox es actualmente distribuido con componentes que habilitan el filtrado en capa dos y
también poseen la habilidad de bloquear paquetes entrantes basados en la dirección Mac en
este trabajo de investigación se describe la adición de filtro de capa 3 y especialmente el filtro
basado en las 7 de los 12 atributos específicos en el protocolo openflow(MAC, IP, PUERTO
()TCP Y UDP y la capa de transporte)

En las redes definidas por software las topologías de red tienen tres componentes principales
los switch, los host y el controlador el filtrado de paquetes puede ser implementado tanto en
la switch como en el controlador la razón de seleccionar los switches como elementos de
filtrado es para reducirle la carga al controlador y por lo tanto reducir la latencia.

Tambien Es cierto que el controlador openflow no implementa seguridad por sí mismo pero un
controlador puede ser programado en el sentido de que pueda asegurar la topología de red
que está controlando.

La red definida por software tiene un vasto campo y muchos scripts en cuanto a filtrado de
paquetes que han sido implementados usando diferentes controladores y simuladores de
topología esta investigacion se ha enfocado en los scripts de filtrado de paquetes que han sido
implementados usando el controlador POX y escritos en Python y se evaluará un número de
scripts de filtrado de paquetes encontrados en gitlhub que facilitarán al usuario implementar
filtrado de paquetes en su topología sdn estos scripts de filtrados serán evaluados basados en
sus atributos que ellos utilizan para filtrar el tráfico

La mayoría de estos scripts de filtro de paquetes son contienen valores separados por comas
como la dirección de fuente dirección destinos y así los cuales son considerados como
atributos preliminares para filtrar un paquete el usuario necesita modificar este archivo cada
vez que un nuevo tráfico de flujo llegue al switch.

La adición de reglas a través de la interfaz de línea de comando es parte esencial de hacer un

controlador capaz de filtrar tráfico como un cuando un nuevo tráfico llegue al switch la tabla
mostrada representa muchos scripts que hacen uso de los atributos soportados por el
protocolo de Flow el script número 17 considera todos campos, sin embargo solo tiene
capacidad de blacklisting.

Simulación

El experimento desarrollado para esta investigación se uso una máquina virtual Linux el
emulador de redes mini net y el controlador Pox, después de investigar acerca de los
componentes de seguridad de pox los script Python fueron integrados al controlador con el fin
de proveer funcionalidades de filtrado de capa dos, adicionalmente también se agregaron
funcionalidades de Black list and Y wITHE list

Se utilizaron también dos terminales en donde en una se ejecutó el simulador minet para
representar la topología y un segundo terminal donde se ejecutó el script Python que agregara
las características de filtrado junto con el controlador.
El comando utilizado en la terminal del mini net mostrado en la parte superior creará una
topología con 7 host conectados a un solo switch por otro lado el script Python colocado en el
en ese directorio y nombrado como sdn_ firewall abrirá una ventana de comando en el
terminal POX el componente preexistente de Pox Pox.Py se ejecutara junto con el script
Python implementado para esta investigación después de que el comando se ejecuta en
ambos terminales las reglas podrán ser añadidas de la línea de comandos utilizando variables
implementadas en el script Python (mac fuente, ip, puerto, etc).

Ahora bien el script Python permite añadir o borrar reglas específicas, limpiar todas las reglas
listar las reglas todo esto desde la interfaz de línea de comandos utilizando las variables.

Dentro de la lógica del script Python se tienen ciertos bloques de comandos que añadirán
funciones específicas

El primer bloque describe la función de carga para habilitar la lista blanca esta regla va a tener
una prioridad de 65535 y añade tmbien que las reglas sean ejecutadas en orden descendente
por prioridad

El segundo bloque muestra las funciones que nos permiten bloquear o permitir las reglas a los
switches esto tiene capacidad de considerar 7 diferentes atributos a la vez que hace las
decisiones de filtrado de paquetes

El tercer bloque representa la función de borrado de reglas con prioridad especifica

El cuarto bloque representa la función de limpiar todas las reglas de la tabla de flujo de los
switches

El quinto bloque representa la función de listar las reglas activas

Contribución al conocimiento

Los resultados experimentales muestran que al añadir el componente POX no solamente se

provee seguridad encapados tales como el filtrado basado en direcciones Mac sino también se
provee una seguridad en capa 3 ea través del filtrado de direcciones IP y seguridad en capa
cuatro a través del filtrado de la capa de transporte por nuero de puertos.

Cox tiene capacidad solo de inspeccionar los campos de direcciones IP o Mac de destino
fuente, pero en El Mundo real los firewalls deben de tener de capacidad de poder examinar
más campos de los paquetes

La interfaz de línea de comandos del script Python es más amigables para usar por los usuarios
de forma que puedan manejar mejor el tráfico cuando se llega al switch finalmente estos
scripts también implementan las listas negras y listas blancas