Curso 2023/2024 Grado en Ingeniería Informática

Práctica 1.2. Ataques a

redes y protección
mediante firewalls II
Redes y Seguridad II

© 2024 Inmaculada Pardines – Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román. This
work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
License.
Facultad de Informática UCM

Práctica 1.2 - Ataques a redes y

protección mediante firewalls II
Objetivos
Esta práctica está pensada para que el estudiante avance en su conocimiento sobre cortafuegos y en su
comprensión de las técnicas de ataques de denegación de servicio en redes: Denial of Service – DoS,
cuando lo causa una única fuente y Distributed Denial of Service DDoS, cuando el ataque es causado
por varias fuentes.

Índice
• Ataque Smurf
• Ataque TCP SYN flooding
• Bloqueo del ataque TCP SYN flooding con iptables
• Finalización de sesión TCP
• Ataque DoS en capa de aplicación (Slowloris)

Calificación
Esta práctica se califica con 3 puntos máximo y hace media con el resto de prácticas de la asignatura

Equipo
Nombre y Apellidos Rol
Programador/a
Hua De Wu Lin

Siro Fernández García Analista

La misión principal del Programador es escribir todos los comandos indicados en la práctica en el orden
correcto para conseguir un buen aprovechamiento de los objetivos buscados en la misma.

La misión principal del Analista es tomar nota del trabajo que está haciendo su pareja de prácticas e
intentar buscar la respuesta a todas las preguntas que se plantean en la práctica. Además, es el encargado
de contestar el test asociado a la práctica.

Este cuadernillo de prácticas podrá ser requerido por los profesores y profesoras de la asignatura en
cualquier momento a lo largo del curso para comprobar y/o recalificar el aprovechamiento del
laboratorio.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 2
 Redes y Seguridad II

AVISO LEGAL

i. Toda la información proporcionada en esta práctica es solo para fines educativos. Los profesores/as
no son responsables en ningún caso del uso indebido de esta información por parte de los
estudiantes de la asignatura de Redes y Seguridad II.

ii. Esta práctica está pensada dentro del diseño docente de la asignatura Redes y Seguridad II donde
además del material aquí expuesto se imparte a los estudiantes conceptos de leyes y de
responsabilidad. No está pensada para que sea realizada fuera del contexto de la asignatura, por lo
que los profesores/as no nos hacemos responsables de la difusión y/o utilización indebida por parte
de terceros que no tengan ninguna relación con la asignatura.

iii. Esta práctica está diseñada para conocer herramientas de auditoría y aprender sobre la manera en
que actúan posibles atacantes.

iv. Los estudiantes pueden probar lo expuesto en esta práctica fuera del laboratorio de la asignatura,
aunque siempre han de hacerlo sobre una red de su propiedad y bajo su propio riesgo. Realizar
intentos de escaneo de puertos o simulaciones de ataques (sin permiso) sobre redes que no le
pertenecen es ilegal.

v. Para poder utilizar el material y la información de esta práctica fuera del entorno educativo para el
que fue creada, los estudiantes deberán firmar un acuerdo específico de auditoría de seguridad con
la persona responsable de los equipos donde se va a utilizar. En ese acuerdo deben aparecer
claramente las pruebas específicas que se van a realizar, pudiéndose referenciar específicamente
este material. En ningún otro caso fuera del estrictamente educativo permitimos la referencia
directa o indirecta a este material.

vi. Consulte las leyes de su país antes de acceder o utilizar estos materiales. En el contexto en el que se
imparte la asignatura de Redes y Seguridad II es importante tener presente el artículo 197 de la Ley
Orgánica 1/2015: “El que […] vulnerando las medidas de seguridad establecidas para
impedirlo, y sin estar debidamente autorizado, acceda o facilite a otro el acceso al
conjunto o una parte de un sistema de información o se mantenga en él en contra de la
voluntad de quien tenga el legítimo derecho a excluirlo […]” “El que […] sin estar debidamente
autorizado, intercepte transmisiones no públicas de datos informáticos que se
produzcan desde, hacia o dentro de un sistema de información […]”

Madrid, a 15 de febrero de 2020

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 3
Facultad de Informática UCM

Configuración de la red
En la práctica 1.2 vamos a usar una estructura de red similar a la que utilizamos en la práctica 1.1. Las
únicas diferencias son que desaparece el Host 2 y creamos el Servidor HTTP a partir de la
máquina virtual rys23_2.ova. Recuerda reinicializar las direcciones MAC y realizar
clonación enlazada.

IP:(192.168.1.3) IP:(192.168.1.1) IP:(192.168.2.20)

Host 1 Servidor HTTP

eth1 enp0s8 enp0s8

Router 1 Red 2: 192.168.2.0/24

Red 1: 192.168.1.0/24 MTU 1500
MTU 1500
enp0s8 enp0s9
(192.168.1.10) (192.168.2.10)

Figura 1

Máquina Clonar
Kali Kali
Host1 consola_rys2
Router 1 rys23_2
Servidor HTTP rys23_2

Si en el entorno donde estás realizando la práctica ya existen las máquinas Host 1, Kali y Router 1,
no necesitarás hacer la clonación, sino que puedes reutilizarlas. Comprueba que las distintas
interfaces de las máquinas están conectadas a las redes internas que se indican en la Figura 1.

REVISA LA PRÁCTICA 0 PARA SABER CÓMO HAY QUE CONFIGURAR LA RED PARA OBTENER LA FIGURA 1
Comprueba que todas las máquinas están correctamente conectadas, haciendo, por
ejemplo, un ping de Host1 a Kali y un ping de Host 1 a Servidor HTTP.

Pasos específicos para esta práctica:

1) está correcto en las reutilizadas.
2) Crea en Kali un directorio llamado Slowloris ($ mkdir Slowloris) y entra en él ($ cd
Slowloris).

3) Bájate de Github el kit Slowloris:

[kali] $ git clone https://github.com/gkbrk/slowloris.git

4) Configura las interfaces de red de las máquinas que no hayas reutilizado y comprueba que todo
5) En la máquina Servidor HTTP apaga el servidor apache 2 y arranca el servidor web con python:
[servidor] $ sudo systemctl stop apache2
[servidor]$ sudo python3 -m http.server 80 --bind 192.168.2.20
Una vez hecho esto, no cierres ese terminal para que el servidor siga arrancado.
© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 4
 Redes y Seguridad II

6) Define en cada máquina los encaminadores correspondientes para que estas máquinas puedan
alcanzar la red a la que no pertenecen. Por ejemplo, en Kali:
[kali] $ sudo ip route add 192.168.2.0/24 via 192.168.1.10
En el servidor HTTP vamos a definir el encaminador como un encaminador por
defecto (para que pueda funcionar el ataque TCP SYN):
[servidor] $ sudo ip route add default via 192.168.2.10
7) Desconecta todas las máquinas del exterior (en la ventana de VirtualBox, sobre cada máquina,
selecciona Configuración ->Red y desmarca la opción Cable conectado del adaptador de red 1).

Hacer este apartado en casa antes del laboratorio

Comando hping3
Hasta ahora hemos utilizado el comando ping, un comando que se utiliza para enviar paquetes ICMP a
un host específico. Esta herramienta es muy sencilla y no permite prácticamente ninguna modificación
de los paquetes, ni utilizar otros protocolos para el envío de información.

Hping3 es una herramienta más avanzada que nos va a permitir modificar los paquetes que se envían a
través de los protocolos de la pila TCP/IP, de manera que podamos disponer de un control mucho mayor
de estos paquetes, pudiendo adaptarlos en función de nuestras necesidades.

Desde la máquina de Kali haz un man hping3 para ver todas las posibilidades de este comando:

Puedes apuntar aquí las utilidades de hping3 que te resulten más interesantes. Entre ellas:

--icmp:

--flood:

-d:

--rand-source:

-S:

--spoof:

Algunas opciones más …

Hping3 es una herramienta muy buena para comprender el funcionamiento de los protocolos de la pila
TCP/IP. Los usos más comunes de hping3 son:

▪ Examinar reglas de firewalls.

▪ Escaneo avanzado de puertos.

▪ Examinar el rendimiento de la red utilizando diferentes protocolos.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 5
Facultad de Informática UCM

▪ Path MTU discovery.

▪ Transferir ficheros entre dos servidores, aunque las reglas de firewall sean bastante restrictivas.

▪ Auditar la pila TCP/IP.

▪ …

Si quieres utilizar hping3 para auditar la robustez de tu firewall aquí puedes encontrar información
interesante: https://iceburn.medium.com/testing-firewall-rules-with-hping3-e175fa104a6d

== BONUS TRACK ==

Puedes probar, por ejemplo, desde Kali:

$ sudo hping3 192.168.2.20 -t 1 --traceroute -c 1

Para saber que saltos realiza el paquete ICMP hasta llegar al Servidor HTTP

Esta herramienta también nos permite enviar paquetes bajo el protocolo TCP, para realizar un escaneo
“hping3 –S [IP Destino] –p [Puerto]”, obteniendo un segmento SYNC+ACK si el puerto está
abierto o un segmento RST+ACK si el puerto está cerrado.

$ sudo hping3 -S 192.168.2.20 -p 80 -c 1

Ataque Smurf
Se trata de un ataque en el que la máquina que realiza el ataque genera paquetes ICMP Echo Request
suplantando la dirección IP de la máquina objetivo como dirección IP origen (ver Figura 2). Además,
utiliza como dirección IP destino una dirección IP de broadcast, de forma que los mensajes Echo Request
llegarán a todas las máquinas de la red destino, que enviarán mensajes Echo Reply a la máquina objetivo,
porque es su IP la que consta como IP origen del mensaje Echo Request. En este caso, se trata de un
ataque DoS reflejado, ya que a la máquina objetivo le llegarán mensajes Echo Reply enviados por todas
las máquinas de la red. El efecto se amplificará cuantas más máquinas tenga la red, de modo que si el
número de máquinas es lo suficientemente grande los mensajes Echo Reply enviados pueden llegar a
colapsar a la máquina objetivo.
Este ataque es muy conocido y los SO actuales por defecto ignoran las peticiones de ping a
direcciones de difusión, evitando que la máquina responda a dicho tipo de ping.
Ejercicio 1: Ataque SMURF desde Kali al Servidor HTTP.
1. Abre el Wireshark en el Servidor HTTP.

2. En la máquina Kali ejecuta:

$ sudo hping3 --icmp --flood --spoof 192.168.2.20 192.168.1.255
Escucha el tráfico entrante al Servidor por la interfaz enp0s8. ¿Qué máquinas están contestando al falso
ping de broadcast?

Ninguna

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 6
 Redes y Seguridad II

IP:(192.168.1.3)

IP:(192.168.1.1) IP:(192.168.2.20)

eth1 Host 1 Echo Replies Servidor HTTP

enp0s8 enp0s8
Echo Request de
Broadcast a Red 1
Router 1 Red 2: 192.168.2.0/24
Red 1: 192.168.1.0/24 MTU 1500
MTU 1500
enp0s8 enp0s9
(192.168.1.10) (192.168.2.10)

Figura 2

3. ¿Puedes conectarte al servidor desde Host 1? (Ejecuta wget 192.168.2.20).

Sí, sí puede

4. Detén el ataque (Ctrl+C).

5. Para que este ataque funcione debes desactivar la opción del sistema operativo que hace que la má-
quina NO responda a las peticiones de broadcast. Desactívala en todas las máquinas de la Red 1 (Host
1, Kali y Router 1).
$ sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts=0
5. En el Wireshark de Servidor HTTP selecciona Captura ->Volver a iniciar.

6. Vuelve a realizar el ataque.

Escucha el tráfico entrante a Servidor HTTP por la interfaz enp0s8, ¿qué tipo de mensajes se capturan
con el Wireshark? ¿Qué máquinas están contestando al falso ping broadcast?

Foto a y 52

¿Puedes conectarte al servidor desde Host 1? (Ejecuta wget 192.168.2.20). Si todavía te puedes conectar,
¿notas alguna diferencia con la conexión de antes?

Foto terminal a y 52

6. Detén el ataque.
¿Por qué no consigues dejar fuera de servicio al Servidor HTTP? ¿Qué tendrías que añadir en Red 1 para
amplificar el ataque?

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 7
Facultad de Informática UCM

La red puede tener pocos dispositivos, lo que limita la amplificación del ataque.
Cuantos más dispositivos estén conectados a la Red 1, mayor será la amplificación del
ataque.

Ataques de capa de transporte

Este tipo de ataques explotan vulnerabilidades de los protocolos de la capa de transporte (TCP o UDP).
Esta explotación puede tener como objetivo la realización de un ataque DoS, como los ataques TCP SYN
Flooding o los ataques de inundación UDP. El éxito de estos ataques se basa en el consumo de recursos.
Otro tipo de ataques sobre este protocolo son ataques a la integridad de los datos, estos ataques consisten
en la suplantación de una de las partes implicadas en la comunicación. Esta suplantación se puede
realizar desde el principio, para iniciar una conexión; o bien, para finalizar o secuestrar una conexión ya
existente. Este tipo de ataques requieren la falsificación de direcciones IP y números de puerto, y en el
caso del protocolo TCP, también de los números de secuencia.
En esta sección vamos a reproducir dos ataques que explotan vulnerabilidades del protocolo TCP: un
ataque TCP SYN Flooding (ataque DoS) y un ataque de finalización de sesión.

TCP SYN Flooding

Vamos a simular otro ataque de tipo DoS, pero esta vez diseñado para hacer uso de las vulnerabilidades
del protocolo TCP. La máquina desde la que se realizará el ataque es la máquina Kali y la máquina
objetivo del ataque es el Servidor HTTP.

IP:(192.168.1.3) IP:(192.168.1.1) IP:(192.168.2.20)

Host 1 Servidor HTTP

eth1 enp0s8 enp0s8

TCP SYN
Router 1 Red 2: 192.168.2.0/24
Red 1: 192.168.1.0/24 MTU 1500
MTU 1500
enp0s8 enp0s9
(192.168.1.10) (192.168.2.10)

Figura 3

Ejercicio 2: Ataque TCP SYN Flood desde Kali al Servidor HTTP.

Como se ha explicado en teoría, el mecanismo SYN cookies se utiliza para mitigar este tipo de
ataques.
Para entender y simular este ataque vamos a seguir los siguientes pasos:

1. Comprueba que el Servidor HTTP tiene activado por defecto el mecanismo SYN cookies y, por lo
tanto, NO es vulnerable a este tipo de ataques.
[Servidor] $ sudo sysctl net.ipv4.tcp_syncookies
Si el valor que se obtiene es 1, el mecanismo está activado.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 8
 Redes y Seguridad II

Si se utiliza el mecanismo SYN cookies la información sobre las conexiones que no han finalizado el
handshake va en el número de secuencia (calculado mediante el mecanismo SYN cookies). Si este
mecanismo está desactivado el sistema usará la cola SYN para guardar información sobre las
conexiones pendientes de completar el proceso 3-way handshake, es decir, conexiones en las que se
ha intercambiado el SYN, el SYN+ACK, pero que no han recibido el ACK previo al establecimiento
de conexión. Si esta cola se llena, porque la máquina tiene muchas conexiones pendientes, la
máquina no podrá aceptar más conexiones, lo que resulta en un ataque DoS. Por lo tanto, el ataque
TCP SYN Flooding se basa en el llenado de la cola SYN. El tamaño de esta cola se establece a través
de la configuración global del sistema. Podemos chequear esta configuración, y conocer el tamaño de
la cola SYN, usando el siguiente comando (el SO establece este valor basándose en el total de memoria
que tiene el sistema; cuanta más memoria, más grande será este valor):

[Servidor] $ sudo sysctl net.ipv4.tcp_max_syn_backlog

128
Apunta su valor: ______________

2. Abre el Wireshark (con sudo) en Router 1, escuchando en la interfaz enp0s9.

3. En la máquina Kali ejecuta:

[kali] $ sudo hping3 -S --flood -p 80 --rand-source 192.168.2.20
El parámetro -S sirve para activar el flag SYN de la cabecera TCP.

3. Observa los paquetes capturados por el Wireshark en la interfaz enp0s9 de Router 1. ¿Qué tráfico
llega y sale del Servidor HTTP?

Foto 10 y 2

4. En el Servidor comprueba el número y estado de las conexiones del servidor ($ sudo netstat -nt).
¿En qué estado se encuentran las conexiones existentes? ¿Eso qué significa?

Foto 10 y 3
Tiene 5 maquinas
conectadas a ella

5. Desde Host1, prueba a conectarte al servidor web ejecutando wget 192.168.2.20.

¿El resultado del ataque es el esperado? ¿Ha funcionado?

No, ha funcionado al conectarse pero el ataque no ha sido efectivo

6. Detén el ataque (ctrl+C en Kali). Observando el Wireshark del Router 1 (enp0s9), espera a que el
servidor termine de contestar a la inundación de TCP SYN.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 9
Facultad de Informática UCM

== TIPS ==
El mecanismo SYN cookies permite aumentar el número de conexiones pendientes sin aumentar el
espacio dedicado (SYN backlog), a costa de incrementar el consumo de CPU.

Al recibir SYN (x), el servidor envía un número de secuencia calculado con una función matemática
secreta: SYN(w), ACK(x+1) y no escribe la conexión en la tabla hasta que no recibe un ACK(w+1), que
supone llega de un cliente legítimo.

7. En el Servidor HTTP, desactiva el mecanismo TCP SYN cookies:

[servidor] $ sudo sysctl net.ipv4.tcp_syncookies=0
8. Comprueba con netstat -nt que ya no hay conexiones pendientes.
9. Selecciona Captura-> Volver a iniciar en el Wireshark de Router1.
10. Repite el ataque desde la máquina Kali:
[kali] $ sudo hping3 -S --flood -p 80 --rand-source 192.168.2.20
11. Desde Host 1, prueba a conectarte al servidor web haciendo wget 192.168.2.20.
¿Has podido conectarte? ¿Ha funcionado el ataque? Si la respuesta es positiva, explica a qué es de-
bido. ¿Qué está sucediendo en el Servidor para que no pueda aceptar la solicitud de conexión de Host
1?

No hemos podido conectarnos, porque el ataque ha funcionado. Esto se debe a que

hemos desactivado la protección del syncookies al ponerlo a 0.

12. Observa los paquetes capturados por el Wireshark en la interfaz enp0s9 de Router 1. ¿Qué tráfico
llega y sale del Servidor HTTP? ¿Qué diferencias observas con respecto a la situación en la que el
mecanismo SYN cookies estaba funcionando? ¿A qué crees que es debido?

Foto diez y once Que el router sigue

recibiendolo, pero el
servidor antes lo
ignoraba y ahora no. El
motivo es haber
desactivado el
syncookies.

Este ataque se puede evitar (independientemente de si se usa el mecanismo SYN cookies) utilizando una
regla de firewall. ¿Dónde se debería colocar el firewall?

Sí, si ponemos la regla en el router.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 10
 Redes y Seguridad II

Conviene haber pensado las reglas de iptables antes de la sesión de laboratorio. Si os

surgen dudas o no sabéis como frenar alguno de los ataques podéis solicitar una
tutoría antes de la sesión de laboratorio

Vamos a hora a probar las reglas de firewall que sirven para mitigar este ataque.
Ejercicio 3: Configuración del firewall de Router 1.
Vamos a configurar el firewall del Router 1 para proteger al servidor HTTP de este tipo de ataques.
Configuramos el router con una política DROP por defecto en todas las cadenas, y después, vamos a
añadir reglas que permitan a un usuario legítimo acceder al servidor, pero que a la vez sirvan para frenar
posibles ataques. Pasos a seguir:
1. Cambiar la política a DROP por defecto de todas las cadenas del Router 1. Ejecuta el siguiente
comando para la cadena INPUT y después haz lo mismo para las cadenas FORWARD y OUTPUT.
[Router 1] $ sudo iptables -P INPUT DROP

2. Comprueba que no funciona ni un ping ni una conexión web de Host 1 al Servidor HTTP.
3. Introduce la regla o reglas necesarias para que todas las máquinas de Red 1 puedan hacer conexiones
web al Servidor HTTP (puedes revisar la práctica 1.1).
Comprueba la configuración del firewall con iptables –L -v.

Escribe aquí la regla o reglas introducidas indicando claramente la cadena afectada

sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.2.20 --dport 80 -m state --state NEW -j ACCEPT

4. Comprueba que no se puede hacer ping desde las máquinas de Red 1 ni al Router 1 ni al Servidor
HTTP, pero sí se permiten conexiones web con el servidor (usa el comando wget). Qué regla habría
que añadir para permitir al menos el ping desde la Red 1 a la interfaz de red del router que está
conectada a la Red 1 (no hace falta que lo compruebes).

sudo iptables -A INPUT -p icmp -s 192.168.1.0/24 -d 192.168.1.1 -j ACCEPT

Con esta configuración tendríamos un firewall muy restrictivo, pero que permitiría que los usuarios
de la Red 1 puedan acceder a la información almacenada en Servidor HTTP.
Si el servidor es accesible desde el exterior podrá ser víctima de posibles ataques, como el TCP SYN
Flooding. Es posible filtrar, mediante el uso de un cortafuegos, un número excesivo de intentos de
inicio de conexión desde una misma dirección IP logrando así bloquear este ataque. Esta medida no
es completamente efectiva ya que el atacante puede ocultar su dirección IP mediante técnicas de IP
Spoofing haciendo parecer, de cara al cortafuegos, que cada paquete de inicio de conexión proviene
de un origen distinto (tal y como habéis hecho vosotros en esta práctica al usar la opción -- rand-
source). Por lo tanto, el método más efectivo para combatir este tipo de ataques es el mecanismo de
SYN cookies.
Para que entendáis cómo se puede realizar un filtrado en el router, vamos a añadir al firewall una
regla capaz de detener un ataque TCP SYN Flooding si es lanzado utilizando la misma IP como IP
origen (en este caso, la de Kali).

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 11
Facultad de Informática UCM

En iptables podemos encontrar un módulo llamado connlimit, que permite restringir el número de
conexiones paralelas desde una misma IP a un servidor, pudiéndose además especificar una
dirección IP de cliente (o bloque de direcciones de cliente). Debe ser especificado con -m connlimit,
seguido por la opción --connlimit-above n, donde n es el número de conexiones máximas
permitidas.
El número de conexiones paralelas permitidas para un mismo cliente debe ser lo suficientemente
alto como para que los usuarios legítimos puedan acceder al servidor, y lo suficientemente bajo para
frenar un ataque DoS. Por ello, es necesario que, antes de aplicarlo a un sistema, se tenga
conocimiento de cuál es la tasa habitual de este tipo de conexiones, para poder determinar el valor
adecuado de --connlimit-above y no perjudicar el funcionamiento normal del sistema. Por
ejemplo, si se añade la siguiente regla en el router no se permitirían conexiones a un servidor HTTP
desde cualquier máquina si el número de conexiones solicitadas por esa máquina es superior a 10:
[Router 1] $ sudo iptables -A FORWARD -p tcp –-syn --dport 80 -m connlimit --
connlimit-above 10 -j DROP
5. Añade al firewall una regla que no permita pasar (DROP) los paquetes provenientes de cualquier IP
de la red interna si el número de conexiones solicitadas es superior a 5. Ten en cuenta al definir
esta regla, que el firewall ya tiene introducidas reglas que permiten conexiones TCP
con el puerto 80 y que el orden de las reglas importa (lee el siguiente recuadro para saber
cómo tienes que definir esta regla).

Regla: sudo iptables -I FORWARD 1 -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j DROP

Recuerda que el orden en que escribes las reglas en el firewall es importante

Para introducir una regla en algún orden concreto primero debemos saber en qué línea del fichero
deberíamos introducirla (antes de la primera regla, o de la tercera …). Para saber las reglas existentes
y su ordenación se utiliza:
$ sudo iptables -nvL --line-numbers
Para insertar una regla antes de otra regla ya insertada se utiliza:
$ sudo iptables -I INPUT 1 <nueva regla>
Con este comando se inserta la nueva regla antes de la regla 1 en la cadena INPUT.

Si te has equivocado al poner una regla la puedes borrar con:

$ sudo iptables -D <la regla completa sin -A>

Por ejemplo, para borrar la regla del connlimit

$ sudo iptables -D FORWARD -p tcp –-syn --dport 80 -m connlimit --connlimit-

above 10 -j DROP

6. Repite el ataque desde Kali eliminando la opción --rand-source:

[kali]$ sudo hping3 -S --flood -p 80 192.168.2.20

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 12
 Redes y Seguridad II

7. Prueba a conectarte al servidor desde Host1 (wget 192.168.2.20), ¿puedes? Sí puedo

8. Detén el ataque.
9. Vuelve a activar el SYN cookies en Servidor HTTP:

[servidor] $ sudo sysctl net.ipv4.tcp_syncookies=1

10. Borra la regla “extra” del firewall, ya que ahora está protegido desde el sistema operativo del servi-
dor.

[Router1] $ sudo iptables -D FORWARD <nº=posición de la regla>

== TIPS ==

El CCN-CERT ha publicado una guía muy completa sobre mitigación de ataques DoS, puedes consultarla
en: https://www.ccn-cert.cni.es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/528-ccn-
stic-820-proteccion-contra-denegacion-de-servicio/file.html
En ella se describen ataques basados en las mismas premisas que los que has simulado en esta práctica
(flooding con spoofing) y técnicas de mitigación usando firewalls similares a los que vas a probar en este
último apartado. Así podemos leer:
“67. Mediante el uso de cortafuegos, como iptables, es posible limitar la ratio de conexiones entrantes
desde un mismo cliente logrando disminuir el impacto del ataque. En caso de especificar un límite de
conexiones entrante demasiado bajo se corre el riesgo de impedir conexiones legítimas disminuyendo
así la fiabilidad de la contramedida.”
Gran parte de los ataques DoS hacen uso de IP Spoofing:
“22. La defensa más común contra IP Spoofing es el ingress/egress filtering. Esto es un conjunto de
reglas que se aconseja aplicar en cualquier router que comunique dos o más redes distintas en una
organización.”

Ejercicio 4: Finalización de una conexión TCP (Reset TCP).

Cierra en el Servidor HTTP el servidor web Python 3 con Ctrl+C

Un ataque de finalización de conexión consiste en abortar de forma ilegítima una conexión establecida
entre dos máquinas. En nuestro caso, vamos a hacer que la máquina Kali aborte la conexión establecida
entre las máquinas Host1 y el Servidor HTTP. Este tipo de ataque se puede realizar sobre cualquier
servicio que utilice el protocolo TCP como protocolo de la capa de transporte.
Cuando se realiza un ataque de este estilo se necesita conocer las IPs, los números de puerto y el número
de secuencia. En nuestro caso, la máquina atacante va a estar en la misma red que la máquina víctima,
por lo que puede escuchar los mensajes que circulan por esta red usando Wireshark.

1. Configura el adaptador de red 2 de la máquina Kali en “Modo promiscuo”. Para ello ir a VirtualBox y
sobre la máquina Kali selecciona Configuración -> Red.

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 13
 Facultad de Informática UCM

2. Abre el Wireshark en Kali (escuchando en eth1) o selecciona Capture-> Restart si ya lo tenías

abierto.
3. Añade una regla a Router 1 para que se puedan hacer conexiones ssh desde la Red 1 al servidor (el
puerto ssh es el 22).

sudo iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.2.20 --dport 22 -m state --state NEW -j ACCEPT

En un principio, podemos pensar que el servidor está bien protegido porque solo admitimos conexiones
http y conexiones ssh (estas últimas, son además conexiones seguras). Sin embargo, es vulnerable a un
ataque de finalización de conexión, que aborta una conexión previamente establecida, provocando una
denegación de servicio (DoS). Según el tipo de conexión cancelada, esto puede provocar que se aborte
una transferencia de archivos (ftp) o una sesión de ssh.

4. Intenta conectarte desde Host1 al servidor http vía ssh

[Host 1] $ ssh 192.168.2.20

5. Comprobar en el servidor que se ha establecido la conexión.

[servidor] $ netstat -nt

6. Vamos a comprobar en el Wireshark (máquina Kali) los mensajes tcp que se están compartiendo
entre Host1 y Servidor. Una manera fácil de verlo es poniendo un filtro ip.dst==192.168.2.20 en el
recuadro que hay debajo de los iconos. Como esta en modo promiscuo el Wireshark capturará todos
los paquetes que circulan por la Red 1, incluso los que no van dirigidos a la máquina Kali.

7. Observamos los mensajes TCP que se están enviando y nos quedamos con el último, observamos la
cabecera porque necesitamos esos datos para reproducir un mensaje TCP legítimo (direcciones IP,
números de puerto y números de secuencia).

8. Desde Kali lanzamos mediante hping al servidor HTTP suplantando a Host 1 un mensaje que cancele
la conexión:

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 14
 Redes y Seguridad II

[Kali] $ sudo hping3 <ip destino> --spoof <IP_Host 1> -p <puerto ssh> -s <puerto
cliente> -R -A -M <Sequence number (raw)> -L <ack number (raw)> -c 1

Escribe en el siguiente recuadro el comando que has ejecutado utilizando los valores que son
correctos en tu caso.

Foto 10 y treinta y mucho

Las opciones -R y -A hacen referencia a unos flags del protocolo TCP, ¿cuáles son y por qué son
necesarios para que este ataque tenga éxito?

-R en hping3: Activa el flag RST (reset). Este flag indica que la conexión se debe cerrar inmediatamente.
-A en hping3: Activa el flag ACK (acuse), necesario para que el segmento parezca la continuidad de una
conexión ya establecida.

9. Comprueba en Servidor HTTP que la conexión se ha cerrado (netstat -nt) y que desde Host 1
ya no puedes acceder vía ssh al servidor sin reinicializar la conexión. Lo ha cerrado correctamente

Ataques de capa de aplicación

Los ataques a la capa de aplicación hacen referencia a un tipo de comportamiento malicioso diseñado
para dirigirse a la capa "superior" del modelo OSI y/o TCP-IP, donde se producen las solicitudes
comunes de Internet como HTTP GET y HTTP POST. Estos ataques a la capa 7, a diferencia de los
ataques a la capa de red y de transporte vistos en esta práctica, son especialmente eficaces debido a que
consumen recursos del servidor además de los recursos de la red.
Este tipo de ataques son más difíciles de detectar porque resulta complicado distinguir entre el tráfico
de un ataque y el tráfico normal. Por ejemplo, cuando una botnet lleva a cabo un ataque de inundación
HTTP contra un servidor, es difícil de reconocer porque cada bot realiza solicitudes de red
aparentemente legítimas, el tráfico puede no estar falsificado y puede parecer que tiene un origen
"normal".

En la máquina Servidor HTTP arranca el servidor web apache (comprueba que estás en el
directorio /home/usuario):
[servidor] $ sudo systemctl start apache2

Ejercicio 5: Ataque DDoS HTTP con Slowloris

Slowloris es un programa para producir ataques de denegación de servicio sin utilizar mucho ancho de
banda, funciona permitiendo que un atacante sobrecargue un servidor web objetivo al abrir (y mantener
abiertas) muchas conexiones HTTP simultáneas. La herramienta abre peticiones HTTP en el servidor
indicándole que se va a realizar una transferencia más larga de lo normal (el servidor puede interpretar
que se está intentando descargar un archivo muy grande o que se está comunicando con un PC o una
red muy lenta), es decir, que para el servidor se trataría de peticiones aparentemente válidas. Este ataque
entra en la categoría de lo que se conoce como ataques "bajos y lentos". El servidor atacado solo tendrá
un número determinado de hilos disponibles para gestionar conexiones concurrentes. Cada hilo del
servidor intentará mantenerse en servicio mientras espera a que se complete la solicitud lenta, lo que
nunca ocurre. Cuando se haya superado el máximo de conexiones permitidas, el servidor no responderá
© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 15
Facultad de Informática UCM

a ninguna conexión adicional y se producirá una denegación de servicio.

Un ataque Slowloris se produce en 4 pasos:

1) El atacante abre múltiples conexiones con el servidor objetivo mediante el envío de múltiples
encabezados de solicitudes HTTP parciales, con encabezados aleatorios y otras técnicas para
pasar desapercibido.
2) El servidor abre un hilo para cada solicitud entrante y una vez que se haya completado la
solicitud el hilo se cerrará. Si una conexión es excesivamente larga, el servidor la cerrará,
liberando el hilo para la siguiente solicitud.
3) Para evitar que el servidor cierre las conexiones, el atacante le envía periódicamente
encabezados de solicitud parciales para mantener activa cada solicitud. Básicamente, dice:
"¡Todavía estoy aquí! Solo soy lento, por favor, espérame".
4) Resultado: el servidor objetivo nunca es capaz de liberar ninguna de las conexiones parciales
abiertas mientras espera a que termine la solicitud. Una vez que todos los hilos disponibles están
en uso, el servidor será incapaz de responder a las solicitudes legítimas, provocando una
denegación de servicio.

Slowloris destaca por su capacidad de hacer daño con muy poco consumo de ancho de banda, solo se
necesitan unos pocos cientos de solicitudes para que el ataque tenga éxito.

1) Abre el Wireshark en la máquina de Kali escuchando por la interfaz eth1.

2) Ejecuta en Kali dentro del directorio donde se encuentre el fichero slowloris.py:

[kali] $ cd Slowloris/slowloris
[kali] $python3 slowloris.py 192.188.2.20 -s 1

3) Detén el comando anterior y comprueba los mensajes capturados por el Wireshark.

Figura 4

Deberías de ver lo mostrado en la Figura 4. Al ejecutar el comando se ha abierto una conexión

TCP en el servidor HTTP. A través de esta conexión se ha mandado una solicitud HTTP con un
número aleatorio en el encabezado (podéis verlo marcado en la parte inferior de la figura).
© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 16
 Redes y Seguridad II

4) Lanza ahora el ataque:

[kali] $python3 slowloris.py 192.188.2.20 -s 500

Qué indica la s __________

indica el numero de sockets (conexiones simultaneas)

5) Intenta acceder al servidor desde Host 1 (wget 192.168.2.20). Si NO puedes acceder, eso sig-
nifica que el ataque ha tenido éxito.

Una de las formas de prevenir un ataque de Slowloris es limitar el tiempo que un cliente puede
permanecer conectado. A continuación, vamos a intentar detener el ataque modificando el fichero de
configuración del servidor apache para limitar el máximo tiempo permitido por solicitud HTTP (en un
servidor comercial habría que tener cuidado con cómo se hace esta restricción ya que podría afectar a su
rendimiento).

6) Detén el ataque.

7) Cambiamos la configuración del módulo que controla el tiempo de espera de una respuesta.
Para ello accedemos al directorio /etc/apache2/mods-enabled, donde se encuentran todos
los módulos que intervienen en la configuración del servidor. De entre ellos, nos interesa el fi-
chero reqtimeout.conf. Abre este fichero con sudo nano reqtimeout.cof modifica los valores
de tiempos por:

RequestReadTimeout header=2-4,MinRate=5000
RequestReadTimeout body=2,MinRate=5000

Para más información visitar https://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html.

Explica qué significan los valores que has reducido y en qué afectan:

-RequestReadTimeout header=2-4,MinRate=5000:
2-4: El servidor espera entre 2 y 4 segundos para recibir todos los encabezados HTTP. Si en 2 segundos no se está
recibiendo nada (o si no se acaba en 4), se cierra la conexión.
MinRate=5000: Si la velocidad de recepción de datos cae por debajo de 5000 bytes/segundo en el envío de
encabezados, Apache cerrará la conexión.

-RequestReadTimeout body=2,MinRate=5000 hace lo mismo, pero aplicado al cuerpo (body) de la petición HTTP (por
ejemplo, en un método POST grande).
8) Reinicia el servidor de apache:

[servidor] $ sudo systemctl restart apache2

9) Vuelve a lanzar el ataque.

10) Intenta acceder al servidor desde Host 1 (wget 192.168.2.20). ¿Ha funcionado el ataque?
___________
No

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 17
Facultad de Informática UCM

ANOTACIONES

© 2024 Inmaculada Pardines - Marcos Sánchez-Élez - Guadalupe Miñana - Sara Román.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. 18