---
# System prepended metadata

title: DDoS using hping3 tool

---

# 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 se hará uso de la herramienta **ping**, y de tráfico malicioso.

</div>

## Back to our Scenario

<div style="text-align: justify">

Antes de pasar a ver como podemos realizar el ataque debemos repasar la topología de nuestro escenario. Como se puede ver en la siguiente figura disponemos de tres switches OVS, un controlador Ryu, y multiples host divididos entre todos los switches. Ahora bien, **¿Qué capacidad tienen los enlaces?**

![escenario](https://i.imgur.com/aeteCr9.png)

Según la [wiki](https://github.com/mininet/mininet/wiki/Introduction-to-Mininet) de Mininet, no están limitados, es decir, dependerá del tráfico que pueda mover nuestra máquina. Por lo que para que nuestro proyecto tenga coherencia y no sea tan dependiendte del hardware que se esté usando para correr las pruebas, se va a limitar el ancho de banda de los enlaces que hay entre los switches y los enlaces que hay entre estos últimos y los host. De esta manera se podrá recrear más facilmente el ataque de DDoS, ya que el limite vendrá impuesto por nosotros, no por las limitaciones de nuestra máquina.

Una vez más, se puede ver como la implementación de Mininet al hacer uso de las bondades del Kernel de Linux nos obligará hacer un diseño del ataque pensando en primera instancia en el propio funcionamiento interno de Mininet. 

<br>

</div>

### How to limit our links

<div style="text-align: justify">

<br>

Para limitar los enlaces que unen los switches vamos hacer uso de la API que nos da Mininet. Esta API, lo que hace en verdad es actuar como wrapper del **tc** ("*traffic controller*")  que modificará el **planificador** ("*Network Scheduler*") del stack de red del Kernel de Linux. 

```python
net = Mininet( topo=None,
               build=False,
               host=CPULimitedHost,
               link=TCLink,
               ipBase='10.0.0.0/8')

```
<br>

Para llevar este proceso a cabo deberemos a la hora de crear el objeto de Mininet en primera instancia indicar que queremos que los Host estén limitados en CPU (**CPULimitedHost**) y que los enlaces sean del tipo **TCLink**, para así, como ya dijimos antes darle un factor más de credibilidad a las pruebas. De esta forma veremos que las limitaciones vienen impuestas por nuestras restricciones y **NO** por las características del hardware donde se lleven a cabo las pruebas.

``` python
    net.addLink(s1, h1, bw=10)
    net.addLink(s1, h2, bw=10)
    net.addLink(s1, s2, bw=5, max_queue_size=500)
    net.addLink(s3, s1, bw=5, max_queue_size=500)
    net.addLink(s2, h3, bw=10)
    net.addLink(s2, h4, bw=10)
    net.addLink(s3, h5, bw=10)
    net.addLink(s3, h6, bw=10)
```
<br>

De forma adicional se deberán indicar las restricciones de los enlaces de nuestra topología. Esto lo realizaremos con estas lineas de código, donde, indicamos los **anchos de banda máximos** y en el caso de los enlaces intermedios indicaremos también el **tamaño de la cola máxima**. Esto lo hemos indicado ya que no nos parecía coherente que los dispositivos intermedios de la red que normalmente tienen limitaciones en memoria para implementar buffers, tengan en nuestras pruebas memoria *infinita* (Amortiguando así nuestro ataque DDoS en las pruebas, cuando en la realidad los buffer de esos switchs se desbordarían induciendo perdidas). 

Hemos puesto un valor de **500 paquetes** de cola máxima atendiendo a los modelos del fabricante por excelencia, Cisco :satisfied: . Como se puede ver en el siguiente [enlace](https://www.cisco.com/c/en/us/support/docs/routers/7200-series-routers/110850-queue-limit-output-drops-ios.html), en función del modelo y de los tipos de colas, estas pueden soportar entre 64 paquetes hasta 1000 paquetes. Hemos decidido 500, como un valor intermedio y estandar para nuestro proyecto. Con toda estas limitaciones, nuestro escenario quedaría tal que así:

![limits](https://i.imgur.com/pzCf5GJ.png)

Cualquier persona que haya estudiado un poco de redes podrá identificar perfectamente el cuello de botella que tiene nuestra red :triumph: . Precisamente por esto, haremos uso de una red mal dimensionada y vulnerable a ataques DDoS de tipo flood para así, poder ver de una forma más explícita el efecto que supone el ataque al tráfico no malicioso.
</div>

## hping3 tool

<div style="text-align: justify">

Esta herramienta tiene una gran variedad de configuraciones para realizar exploración de red, traceroutes, enviar pings, ataques de tipo flood a distintos niveles.. En resumen, nos brinda un gran abanico de posibilidades para conformar paquetes y enviarlos a distintos sitios, con unas cadencias determinadas. Además, también se puede especificar la dirección IP origen, utilizando nuestra IP, otra IP o una random. Nosotros simplemente nos quedarmeos con el ping basico, paquetes **ICMP - Echo request (Type = 8, Code = 0)**, y aumentaremos la velocidad de envío por simplicidad. De esta manera conseguiremos colapsar el core de la red perpetrando así el DDoS.

* Para más información sobre la [herramienta](https://tools.kali.org/information-gathering/hping3).

</div>

### Installation

<div style="text-align: justify">

La herramienta ya está instalada en la máquina `test`, ya que se añadió su instalación en el aprovisionamiento de la máquina. De querer instalarla lo podríamos hacer de la siguiente manera:

```
sudo apt-get install hping3
```

</div>

### Usage

<div style="text-align: justify">

Como ya comentabamos el uso de esta herramienta es muy amplio pero nosotros nos vamos a quedar con un funcionamiento muy especifico para así acotar la complejidad del proyecto. El comando que utilizaremos será el siguiente:

```
hping3 -V -1 -d 1400 --faster {IP_destino}
```

Con estos parametros le estamos indicando lo siguiente

*    `-V` , para que trabaje en modo verbose.
*    `-1`, para que genere paquetes ICMP, que por defecto serán ICMP - Echo request.
*    `-d 1400`, añadimos un payload innecesario para la petición pero útil para acaparar el ancho de banda de la red. En este caso se ha elegido 1400 bytes para que no haya fragmentaciones en capa dos.
*    `--faster`, para que genere 100 paquetes por segundo :dizzy_face: .

<br>

La herramienta `hping3` da la posibilidad de enviar paquetes aun más rapido con el parametro **`--flood`**. Con este parametro la herramienta generaría los paquetes tan rapido como nuestra máquina se lo permita. En primera instancia se pretendió hacer uso de este parametro, pero se observó que todos los paquetes generados eran descartados, por ello se hizo uso del parametro `--faster` que  nos brinda la cadencia suficiente para el proposito de nuestro proyecto. 

</div>

---

## Demo

<div style="text-align: justify">

Antes de empezar, vamos a explicar el escenario que se va a recrear para ejemplificar el ataque DDoS. Haremos uso de nuestro escenario de red, donde pondremos **hping3** a funcionar en el **Host1** hacia el **Host4**, a la par desde el **Host2** trataremos de comunicarnos al Host4 con un **ping** normal, para así emular una comunicación no maliciosa que se ve afectada por el hping3, el ataque DDoS.

![ataque](https://i.imgur.com/awt7e5v.png)



Empecemos, primero vamos a levantar nuestro escenario. Una vez levantado como lo hacemos siempre:

```bash
sudo python3 scenario_basic.py
```

Vamos abrir dos terminales con el comando xterm, h1 y h2. De forma adicional vamos ha abrir wireshark para hacer debug de manera opcional. 

```bash
mininet> xterm h1 h2
mininet> h4 wireshark &
```

<br>

Ponemos a funcionar hping3 desde el Host1, según los parametros comentados anteriormente:

<span style="display:block;text-align:center">

![ddos](https://i.imgur.com/Uei0gb5.png)

</span>

<br>

Ponemos a funcionar tráfico normal desde la máquina Host2, un simple ping y vemos como la red está colapsada por el ataque DDoS. 

<span style="display:block;text-align:center">

![ping](https://i.imgur.com/yjfSJoD.png)

</span>

<br>

Si detenemos el ataque DDoS que estaba corriendo en la máquina Host1, podemos comprobar que el flujo de la comunicación vuelve a la normalidad en poco tiempo.

<span style="display:block;text-align:center">

![ping_ok](https://i.imgur.com/5fkmrEu.png)

</span>

<br>

Como se ha podido ver el ataque ICMP ha resultado exitoso. Nuestro trabajo de aquí en adelante consistirá en detectarlo, y a poder ser mitigarlo. Para trabajar de una manera más sencilla, el comando de hping3 y el comando utilizado con ping se encapsularán en dos scripts de python. De esta forma no tendremos que estar poniendo todos los parametros del comando cada vez que queramos lanzar un ataque. Podrán encontrarlos en:

* Ataque: [`src/ddos.py`](https://github.com/GAR-Project/project/blob/master/src/ddos.py)
* Tráfico normal: [`src/normal.py`](https://github.com/GAR-Project/project/blob/master/src/normal.py)

<br>


---

<br>
</div>

## Video

<div style="text-align: justify">

Aquí se puede ver los pasos seguidos para hacer la replica del ataque DDoS. Cualquier duda que pueda surgir en la recreación del ataque no duden en ponerse en contacto con nosotros. (Hacer click en la imagen :smirk_cat:).

<br>

<span style="display:block;text-align:center">

[![demo_proyecto](https://img.youtube.com/vi/ofZPmV6_y_M/0.jpg)](https://www.youtube.com/watch?v=ofZPmV6_y_M)

</span>

</div>