En este documento vamos a investigar como hizo nuestro querido rumano de confianza la implementación de control in-band en el switch BOFUSS. Recordemos con que repositorios vamos a estar trabajando. Switch de boby in-band, a.k.a in-BOFUSS: https://github.com/NETSERV-UAH/in-BOFUSS Basic OpenFlow Software Switch, a.k.a BOFUSS: https://github.com/CPqD/ofsoftswitch13 Un poco de historia :book: Si queremos la historia más detallada nos podemos ir al papers del switch y listo... :joy_cat: Dejo el link por aqui para los interesados. Aquí vamos a seguir una descripción un poco más breve. The road to BOFUSS: The basic OpenFlow userspace software switch

En el mundo de las redes siempre se habla de interfaces tun/tap de forma indistinta, hasta ahora, yo tambien lo hacia, pero llega un momento de la vida donde uno tiene que madurar y ver de que narices va esto :joy_cat:. Vamos al meollo. En networking, las interfaces TUN y TAP son interfaces virtuales que se crean y se gestionan en espacio de kernel. Mencionar que como estas interfaces son virtuales se gestionan directamente vía softaware, no como las interfaces reales que se gestionan con unos drivers diferentes, ad-hoc de la interfaz. Los drivers TUN/TAP se crearon en los 2000 como una unión de los avances de los drivers desarrollados en las comunidades de Solaris, Linux, BSD. Actualmente los drivers solo tienen mantenimiento por los kernels de linux y FreeBSD. Ambos tipos de interfaces se utilizan para tunelado, pero no pueden ser utilizadas a la vez dado que trabajan en niveles distintos. Las TUN, de network TUNnel, emula la capa de red y puede llegar hacer FW de paquetes. En cambio las interfaces TAP, trabajan en capa 2, y emulan un equipo en capa 2. TUN se puede llegar a utilizar para routing. TAP se puede llegara utilizar para crear un bridge. Los paquetes son enviados por el sistema operativo a través de una interfaz TUN/TAP, y serán recibidos por algun programa de espacio de usuario, el cual, está enganchado directamente en la interfaz. Cualquier programa de espacio de usuario podrá pasar paquetes por las interfaces, y las interfaces virtuales se lo pasarán al stack de red pro defecto, emulando la recepción de los paquetes inyectados desde espacio de usuario.

Optimización de entornos de balanceo de recursos Optimización de rutas críticas en entornos de balanceo de recursos AI - sistemas distribuidos en red AI - clasificadores - detección de anomalías IoT + SDN en entornos industriales

El objetivo de esta actividad es obtener nociones básicas sobre algunos ataques que se pueden llevar a cabo sobre aplicaciones web identificando y explotando las vulnerabilidades que éstas sufren. Lanzar escenario El escenario empleado es La aplicación web DVWA es una aplicación web que sufre vulnerabilidades de manera expresa y tiene como objetivo ofrecer un entorno controlado de aprendizaje para poner a prueba las habilidades de las que se dispone como atacante. Para lanzar el escenario emplearemos docker, ya que es mucho más rápido y sencillo de desplegar frente a una máquina virtual. Para lanzar el escenario debemos tener instalado docker, una vez instalador podemos lanzar el escenario con el siguiente comando: docker run --rm -it -p 80:80 vulnerables/web-dvwa Una vez lanzado podemos ver como se nos abre el promt los logs del contenedor y tendremos escuchando en el puerto 80 la aplicación web vulnearble: En este punto ya tendríamos casi desplegado eñl escenario, hay que crear la BBDD interna y establecer el nivel seguridad bajo para el login web. Para ello acuda con un navegador a la dirección http://localhost.

# Apuntes Ing. Tráfico ## MPLS, MultiProtocol Label Switching ### MPLS: Introducción Es un mecanismo de reenvío de paq. mediante solución “conectiva” en redes “no conectivas”. Además, es una tecnología de paquetes que separa las dos funciones básicas de los routers. * **Plano de control**: Aprendizaje y selección de rutas mediante protocolo de encaminamiento. Requiere de una gestión de tablas de encaminamiento. * **Plano de reenvio**: El reenvio se lleva a cabo mediante una “etiqueta”

# Mininet Internals (II) <div style="text-align: justify"> En esta segunda parte sobre el funcionamiento interno de Mininet, indagaremos sobre la topología a nivel de Kernel recreada por Mininet para levantar nuestro escenario. Por último, explicaremos las distintas formas de levantar servicios en las distintas Network namespaces, necesario para recolectar información con `telegraf`. </div> ## Is Mininet using Network Namespaces? <div style="text-align: justify"> Hemos introducido anteri

# Network scenario - Mininet ## Installation methods Para la instalación del escenario se ha creado un imagen Vagrant a la cual se le aprovisionan todo todos los shellscripts necesarios para la instalación/configuración del escenario. Se ha elegido para tener todos las mismas especificaciones, de esta manera, en caso de encontrar errores podremos sacar de una forma más sencilla la trazabilidad de la causa de estos. De no querer hacer uso del metodo de instalación de Vagrant se puede seguir e

# DDoS using hping3 tool <div style="text-align: justify"> Hemos levantado un escenario de red con Mininet, pero aun no hemos hablado de como vamos a realizar nuestro ataque DDoS. A continuación, explicaremos como vamos a recrear un sencillo ataque DDoS dentro de nuestra propia red haciendo uso de la herramienta **hping3**. Al fin y al cabo el objetivo de este proyecto es desarrollar un clasificador utilizando **IA**, por lo que también será necesario tener modelos de tráfico normal, para ello

# Network scenario - Mininet ## TODO * ~~Setting up a network scenario with Mininet.~~ :heavy_check_mark: * ~~Choice of tools to recreate the DDoS attack.~~ (**ping y hping3**) :heavy_check_mark: * Run telegraf on the 'test' machine, and on the 'control' machine InfluxDB and Grafana. * Using the InfluxDB interface ([Python API](https://github.com/influxdata/influxdb-python)) create a script that implements an AI algorithm that classifies whether we are under a DDoS attack or in a normal