El Flag ReSeT (RST) provoca la caida de la conexión, normalmente se usa para recuparación de errores. El atacnte ijecta un marco con el flag RST activo, provocando que el receptor corte la conexión inmediatamente.

El ataque tiene los siguientes requisitos:

• RST se encuentra dentro del rango permitido
  • En todos los estados salvo SYN-SENT, todos los fragmentos RST son validados revisando sus campos SEQ (Número de secuencia).
  • Un reset es válido si el número de secuencia está dentro del rango
  • En el estado SYN-SENT el RST es aceptable si el campo ACK reconoce el SYN
  • Número de escuencia entre RCV.NXT y RCV.NXT+RCV.WND
  • Rangos históricos < 64 kbytes.
• Right 4-tuple
  • Se deben conocer la IP y puerto del server
  • Se deben conoce la Ip y el puerto del cliente

• El atacante inspecciona los datos enviados por el primer equipo al segundo equipo
• Antes de que el primer equipo envíe el siguiente paquete, el atacante genera un paquete RST válido con:
  • Misma Dirección IP
  • Mismos Puertos TCP
  • Número de secuencia correcto.

• El atacante inspecciona el tráfico del segundo equipo al primero
• Antes de que el primer equipo envíe el siguiente paquete, se genera un paquete RST válido
  • Misma IP
  • Mismos puertos TCP
  • Número de secuencia correcto

Es un ataque difícil de realizar, las direcciones de ambos extremos no suelen ser conocidas, aunque se suelen conocer las direcciones de los servidores, las de los servidores suelen ser desconocidas. Los puerto de los dos extremos suelen ser desconocidos, el de server a veces es conocido, pero el de los clientes suele ser impredecible. El número de secuencia tampoco es conocido. Las conexiones suelen tener un tiempo de vida muy corto y el rango del número de secuencia valido cambia, por lo que cualquier intento de adivinar estos datos es poco útil.

Por otro lado, los protocolos tienen un amplio tiempo de vida y las direcciones se pueden saber por adelantado.

• Solo aceptar el segmento RST si el número de secuencia es el primero en el rango (proveido por el sistema operativo)
• Filtrar paquetes spoofeados a nivel IP (Tiene que ser realizado por los servidores de autenticación en los extremos)
• Usar tmarcas de tiempo como defensa adicional: PAWS (Protection Against Wrapped Sequences)
• Paquetes TCP autenticados (TCP-AO)

Una tacante agota la tabla de conexiones

1. El atacante envía paquetes SYN con su dirección real pero nunca completa las conexiones (Filtrado fácilmente del lado del servidor)
2. El atacante envía paquetes SYN con direcciones suplantadas (El receptor suplantado envía RST y el servidor elimina la conexión)
3. El atacante envía paquetes SYN con direcciones suplantadas que no responden (Ataque DoS)

Para defendernos de SYN Flood podemos hacer lo siguiente:

• Dropear conexiones
• Reducir el uso de memoria para conexiones noe stablecidas
• No almacenar nada (Como se establece la conexión entonces?)

Se cifra la información de conexión dentro del ISN

• Primeros 5 bits: número lentamente incremental basado en el tiempo
• Siguientes 3 bits: Se codifica el MSS anunciado del cliente
• Últimos 24 bits: Hash secreto de la IP y portes del cliente y los primeros 5 bits.

Cuando se recibe un ACK sin una conexión establecida:

1. Se sustrae 1 del número ACK
2. Se Recalcula el hash y se compara con los últimos 24 bits, si el hash coincide, se almacena la ifnormación de la conexión.

Este mecanismo no necesita cooperación por parte del cliente.

Las SYN Cookies tienen algunos puntos negativos:

• Falta de espacio para negociar opciones
  • MSS: solo 3 bits, aproximadamente 65000 valores
  • SACK: No hay espacio para el
  • Rangos grandes: No hay espacion para ellos
• Soluciones:
  • Incrementar los bits para codificación de información (Reduce la resistencia del hash)
  • Usar SYN Cookies solo cuando se está bajo ataque, mejor tener mal rendimiento que perder el servicio
  • Tomar ventaja de otras opciones para incrementar el espacio
    • Marca de tiempo del servidor enviada de vuelta en CAK, usa la parte final para cofigicar información

Busca agotar la thread pool de un servidor web:

1. Se hacen muchas peticiones HTTP incompletas
2. Se envían encabezados periódicamente para mantenerlos abiertos
3. Nunca cerrar y sie el server cierra, volver a abrir

Esto se puede mitigar de la siguiente manera:

• Incrementar el número de hilos (Poco efectivo)
• Limitar Tiempo de conexión, conexiones por IP…
• Proxy inverso en la nube: No se envía nada al servidor web.

Este ataque también se puede realicar sobre QUIC

La ausencia de autenticación tiene los siguientes problemas:

• Identificación de conexión
  • Puerto e IP de destino: Conocidos
  • Puerto de origen: puede ser adivinado
  • IP de origen: Puede ser suplantada
• La falta de autenticación puede llevar a:
  • Ataques DoS: RST attack y SYN flooding
  • Ataques de inyección de datos.