Ataques UDP Reflection Flood DrDoS

Existen muchos tipos de ataques de Denegación de Servicio (DoS), y hasta ahora hemos visto diferentes ataques de inundaciones DoS y DDoS basados en TCP que pueden ser mitigados en cierta manera con herramientas como FloodMon o DDoS Deflate (o mediante Iptables. ipset o APF). Vamos a ver un tipo de ataque Distributed Reflection Denial of Service (DrDoS) usando tráfico UDP en el que no necesitamos ninguna botnet (ni tener pc's infectados), simplemente una lista grande de servidores mal configurados que nos atacarán por la petición maliciosa de una tercera persona.

Un ataque de denegación de servicio distribuido supone el envío de solicitudes falsas (spoofed) a un gran número de equipos que responden a las solicitudes. Falsificando (spoofing) la dirección ip de origen el atacante consigue que respondan y ataquen "involuntariamente" a la víctima.

A diferencias de otros ataques más convencionales en el pasado que usaban una botnet de máquinas infectadas controladas de alguna manera por el atacante (irc, vía web, etc), en este caso sólo se necesita tener un gran listado de ip's vulnerables. Dichos servidores no están infectados, ni son controladas por el atacante, simplemente son servicios vulnerables que responden a peticiones maliciosas 

Un ataque de inundación UDP (Flood UDP) se inicia mediante el envío de un gran número de paquetes UDP a a puertos al azar del sistema de destino. El sistema de destino está además "obligado" a "responder" enviando muchos paquetes ICMP "Destination Unreachable", consumiendo así sus propios recursos y provocando DoS. Como UDP no requiere ningún procedimiento de configuración de la conexión para la transferencia de datos, cualquier persona con conexión a internet y suficientes conocimientos puede lanzar un ataque; no se necesita acceder al sistema, ni que forme parte de una red zombie.

Debido a la propia naturaleza del  protocolo UDP se pueden realizar este tipo de ataques, y no se pueden aplicar ciertas contra medidas anti-spoofing como Unicast Reverse-Path Forwarding (uRPF), ACLs, etc.

El protocolo UDP proporciona un procedimiento para programas para enviar mensajes a otros programas con un mínimo de mecanismo de seguridad. El protocolo está orientado a la transacción, y la entrega y protección duplicados no están garantizados. Las aplicaciones que requieren la entrega confiable ordenada de flujos de datos deben utilizar el Protocolo de Control de Transmisión (TCP).

UDP es utilizado en:

• DNS: Domain Name System

• NFS: Network File System

• NTP: Network Time Protocol

• SNMP: Simple Network Management Protocol

• DHCP: Dynamic Host Configuration Protocol

• TFTP: Trivial File Transfer Protocol

• Streaming / VoIP (Team Speak) 

• BitTorrent

• Quake Network Protocol 

UDP es utilizado muy frecuentemente también en servidores de juegos o streaming por su simplicidad, baja latencia y poder de broadcast (multicast).

Esquema normal de tráfico:

 Esquema de un Ataque:

Host A --> Atacante

Host B --> Servidor "vulnerable" UDP

Host C --> Víctima

 Esquema de un ataque amplificado y distribuido

¿Dönde está el problema? 

1. IP Spoofing

El atacante puede suplantar la ip de origen (Source Address Spoofing), udp no lo valida. No es un problema nada nuevo, ya que hay reportes en CERT desde el año 1997.

2. Amplificación (Amplification)

• El atacante hace una pequeña solicitud que genera significativamente una mayor respuesta / respuesta. Se han visto ataques que pueden generar un tráfico de hasta 300gb/sec. Se  caclcula que un atacante con una velocidad de subida uplink de 1 Gb/s podría  generar varios ataques de varios Tbit/s

3. Reflectores (Reflection)

• El atacante envía peticiones falsificados a un gran número de servidores vulnerables que responden a las peticiones. El uso falsificado de la dirección IP,  hace que la dirección "origen" es en realidad  el objetivo real del ataque, donde se envían todas las respuestas.  Cómo veremos, muchos servicios pueden ser explotados para actuar como reflectores.

Distributed Reflection/Reflective Denial of Service (DrDoS)

Reflected Denial of Service (DoS) Attack.

Amplificación: Ataques cada vez más comunes que se aprovechan del poder multiplicador, al poder amplificar el tráfico que pueden generar y enviar a la víctima.

UDP Reflection

DNS Reflection (port 53, udp) open DNS recursive Poder Amplificación del tráfico 18x/1000x

CharGen (Character Generator Procotol) port 19. GetBulk request Poder Amplificación grande: 160x

Echo (puerto 7)

QOTD: (Quote of the Day) Muy similar a CharGen (puerto 17)

NTP (Network Time Protocol) port 123 Poder Amplificación muy grande 1000x

SNMP (Simple Network Management Protocol) port 161 Poder Amplificación 880x

SSDP (Simple Service Discovery Protocol) Puerto 1900 udp SSDP Plug & Play (UPnP)

Nombre Puerto origen UDP Descripción

DNS 53 (o aleatorio) Domain Name System

CharGEN 19 Character Generator Procotol

Echo 7 File search

QOTD 17 Quote of the Day

NTP 123 Networt Time Protocol

SNMP 161 Simple Network Management Protocol

SSDP 1900 Simple Service Discovery Protocol

Se calcula que hay más 1 millón de servidores NTP vulnerables (a fecha de Enero de 2014) -Reporte de http://openntpproject.org

Se calcula que hay más 30 millones de servidores DNS recursivos (open) vulnerables (a fecha de Octubre de 2013) -Reporte de http://openresolverproject.org/

Encontrar Servidores DNS recursivos con nmap:

nmap -sU -pU:53 -sV -P0 --script="dns-recursion" -oN open-dns-resolver.txt 

Escanear con  nmap SSDP (Simple Service Discovery Protocol)

nmap -sU -p 1900 --script=upnp-info 

o bien:

nmap -sU -pU:1900 -Pn -n --script=upnp-info

Network Time Protocol es simplemente usado para inscronizar el reloj vía Internet. El demonio (daemon) NTP (ntpd) se puede utilizar como cliente y servidor. ntp amplification attack es un ataque muy común.

Tabla ejemplo según CERT-US, United States Computer Emergency Readniess Team

Protocol Bandwidth Amplification Factor Vulnerable Command

DNS 28 to 54 see: TA13-088A [1]

NTP 556.9 see: TA14-013A [2]

SNMPv2 6.3 GetBulk request

NetBIOS 3.8 Name resolution

SSDP 30.8 SEARCH request

CharGEN 358.8 Character generation request

QOTD 140.3 Quote request

BitTorrent 3.8 File search

Kad 16.3 Peer list exchange

Quake Network Protocol 63.9 Server info exchange

Steam Protocol 5.5 Server info exchange

Algunos de estos servicios están activos todavía por defecto en el daemon xinetd y el obsoleto /etc/inetd.conf 

Deshabilitar:

#chargen dgram udp wait root internal

UDP Flood  - UDP: User Datagram Protocol

Al contrario que TCP, el protocolo UDP no está orientado a conexión

Ataques por inundación UDP ¿En qué consisten?

Envío masivo de paquetes a puertos UDP aleatorios

Destinatario (víctima)

Comprueba si alguna aplicación está escuchando en ese puerto

Puerto aleatorio -> ninguna aplicación estará a la escucha

Responde con un paquete ICMP Destination Unreachable

Si el número de paquetes enviados (puertos analizados) es suficientemente elevado el destino será incapaz de responder

Detección - Ejemplo

Analizando el tráfico con herramientas de captura y análisis como:

wireshark (tshark es la versión en línea de comandos)

tcpdump

iptraf

Ejemplo de fragmento de tráfico analizado con iptraf en un ataque UDP Chargen

Mon Jun  9 20:16:27 2014; UDP; eth0; 347 bytes; from 182.220.16.2:19 to 91.126.237.80:2001

Mon Jun  9 20:16:27 2014; UDP; eth0; 235 bytes; from 182.18.128.146:19 to 91.126.237.80:2001

Mon Jun  9 20:16:27 2014; UDP; eth0; 247 bytes; from 182.18.128.146:19 to 91.126.237.80:2001

Mon Jun  9 20:16:27 2014; UDP; eth0; 247 bytes; from 182.18.128.146:19 to 91.126.237.80:2001

El servidor responde con un ICMP Destination Unreachable

Mon Jun  9 20:16:27 2014; ICMP; eth0; 576 bytes; from 91.126.237.80 to 182.18.128.146; dest unrch (port)

Ya que el log generado por iptraf puede ser muy largo y grande podemos usar algunos comandos para ordenar las ip's que más atacan por número de veces que aparecen:

cat ip_traffic-1.log | grep ":19 to 91.126.237.80:2001" | awk '{ print $11 }' | awk -F: '{ print $1 }' | sort | uniq -c | sort -n > listado-ips-conexiones.log

El resultado sería HITS - IP

   1056 - 49.50.228.5

   1066 - 176.197.159.6

   1124 - 50.202.107.101

   1134 - 64.38.225.40

   1160 - 173.215.169.2

   1185 - 66.135.35.85

   1256 - 66.118.174.178

   1795 - 213.176.143.42

   2038 - 182.18.128.146

En sólo dos minutos de tráfico capturado la ip 182.18.128.146 ha generado 2038 hits

Podemos comprobar como efectivamente la ip 182.18.128.146 tiene el puerto 19 abierto y responde enviando texto:

telnet 182.18.128.146 19

Ejemplo de respuesta CharGen:

Podemos ver de una manera muy gráfica como efectivamente UDP CHARGEN envía 200 a 1000 veces veces más datos de lo que recibe, dependiendo de la implementación

Escanear con nmap:

nmap -sU -p 19

  

Ejemplo de gráfica con Monitorix, con 40 millones de paquetes:

En nuestra caso una sencilla regla con iptables evitaría el problema:

-A INPUT -p udp -m udp --sport 19 -j DROP 

Pero el ataque puede tener un random port de origen y destino:

iptables -A INPUT -p udp -m limit --limit 5/s  -j RETURN

iptables -A INPUT -p udp -m limit --limit 5/s  -j LOG

Ejemplo Ataque NTP Port 123 udp

Paquetes capturados con tcpdump en formato pcap

Máximo 50 ficheros de 100MB cada uno sólo tráfico UDP

 tcpdump -n udp  -C 100 -W 50 -w /tmp/traffic.pcap & 

O con tshark (máximo 250 ficheros de 100MB)

tshark -b filesize:10000 -a files:250 -w /tmp/traffic.pcap & 

Fragmento:

Source port: ntp (123)

Length: 448

Network Time Protocol (NTP Version 2, private)

Implementation: XNTPD (3)

Request code: MON_GETLIST_1 (42)

Podemos ordenar las 50 ip's atacantes por número de paquetes (hits) con un filtro usando tshark

 tshark -T fields -e ip.src -r /tmp/traffic.pcap | sort | uniq -c | sort -n | tail -50

[..] top 10

hits - ip

  17768 - 212.227.126.49

  18133 - 212.227.126.37

  18357 - 80.82.78.2

  18629 - 206.197.60.7

  18645 - 94.20.20.40

  19357 - 193.110.75.146

  19743 -  202.10.82.10

  21386 -  208.118.234.238

  26894 -  85.111.0.148

  28985 -  118.69.250.27

Analizando el fichero pcap de 1 minuto de duración con Wireshark portable para Windows, Conversations -->  ordenado por paquetes:

Ejemplo ataque DNS Reflection:

# tcpdump -i eth0 -nnn port 53 and not port 22

Mediante awk, sed podemos ver las ip's que atacan con más fuerza para después poderlas ordenar por número de hits:

tcpdump -i eth0 -nnn port 53 and not port 22 | awk '{print $3}' | sed 's/\./ /g' | awk '{print $1"."$2"."$3"."$4}' >> /root/udp_flood.log

Mostrar las ips con más número de hits:

cat /root/udp_flood.log | sort | uniq -c | sort -n

Logear tráfico con iptables:

-A INPUT -p udp --sport 123 -j LOG  --log-prefix "Ataque 123 udp ntp " --log-level 4

Ejemplo 

Feb 18 20:09:30 ns2 kernel: Ataque 123 udp ntp IN=eth0 OUT= MAC=XX 

SRC=194.78.180.122 DST=IP LEN=468 TOS=0x00 PREC=0x00 TTL=50

ID=17019 DF PROTO=UDP SPT=123 DPT=8363 LEN=448 

Verificar servidor NTP vulnerable con nmap:

nmap -sU -pU:123 -Pn -n --script=ntp-monlist 194.78.180.122

Resultados:

Nmap scan report for 194.78.180.122

Host is up (0.037s latency).

PORT    STATE SERVICE

123/udp open  ntp

| ntp-monlist:

|   Target is synchronised with 127.127.1.1 (reference clock)

|   Public Servers (1)

|       204.124.183.210

|   Other Associations (527)

|       91.126.240.73 (You?) seen 10 times. last tx was unicast v2 mode 7

|       180.96.80.229 seen 10573 times. last tx was unicast v2 mode 7

|       94.177.106.114 seen 2061 times. last tx was unicast v2 mode 7

|       127.0.0.1 seen 2303 times. last tx was unicast v2 mode 6

|       113.82.114.157 seen 2076 times. last tx was unicast v2 mode 7

|       114.80.252.46 seen 218 times. last tx was unicast v2 mode 7

|       61.49.57.18 seen 1187 times. last tx was unicast v2 mode 7

|       49.67.208.168 seen 3425 times. last tx was unicast v2 mode 7

|       183.61.233.247 seen 1127 times. last tx was unicast v2 mode 7

|       81.97.24.75 seen 5622 times. last tx was unicast v2 mode 7

|       173.61.103.240 seen 37578 times. last tx was unicast v2 mode 7

|       111.78.226.130 seen 2027 times. last tx was unicast v2 mode 7

|       60.222.246.6 seen 506 times. last tx was unicast v2 mode 7

|       183.61.234.99 seen 1110 times. last tx was unicast v2 mode 7

|       198.50.241.229 seen 2793 times. last tx was unicast v2 mode 7

|       111.176.137.39 seen 1914 times. last tx was unicast v2 mode 7

|       80.60.16.43 seen 90 times. last tx was unicast v2 mode 7

|       176.31.115.196 seen 124 times. last tx was unicast v2 mode 7

|       185.25.204.79 seen 3 times. last tx was unicast v2 mode 7

|       185.62.188.231 seen 1266 times. last tx was unicast v2 mode 7

O con ntpdc

ntpdc -c monlist ip_servidor_ntp

También podemos usar el módulo u32 de iptables para dropear los paquetes:

iptables -I  INPUT -p udp --dport 123 -m u32 --u32 "0x1C=0x1700032a && 0x20=0x00000000" -m comment --comment "NTP amplification packets" -j DROP

iptables -I INPUT -p 17 -m multiport --ports 123 \-m u32 --u32 "0>>22&0x3C@8&0xFF=42" -j LOG --log-prefix="NTP MONLIST "

Drop all NTP pakets with request code 42

-A INPUT -p udp -dport 123 -m u32 --u32 0x0>>0x16&0x3c@0x8&0xff=0x2a -j DROP 

Ejemplo Ataque Simple Service Discovery Protocol SSDP (upnp) 1900 UDP

 SSDP (SSDP). Este protocolo es parte de la función Universal Plug and Play (UPnP) estándar del protocolo. SSDP viene habilitado en millones de dispositivos domésticos y de oficina - incluyendo routers, servidores de medios, cámaras web, televisores inteligentes e impresoras - para permitir que descubran uno al otro en una red, establecer comunicación y coordinar actividades.

SSDP no está diseñado para ser un protocolo de Internet enrutable, y punto. De hecho, nunca se va a convertir en un estándar. El Proyecto de Internet elaborado por ITEF expiró en abril de 2000. Más tarde, se convirtió en parte del UPnP (Universal Plug and Play).Un descubrimiento de multidifusión y el mecanismo de búsqueda que utiliza una variante de multidifusión de HTTP a través de UDP. 

SSDP (SSDP) es un protocolo que se anuncia y se ve para servicios de red. En los sistemas Windows, el servicio SSDP controla la comunicación para el Universal Plug and Play (UPnP).

Según https://ssdpscan.shadowserver.org/ se calcula que actualmente (2015) hay más de 14 millones de dipositvos vulnerables en todo el mundo.

HD Moore de Rapid7 creado una utilidad que tanto escanear para la comunicación SSDP y le notificará si el sistema era vulnerable a exploits UPnP

"UPnP SSDP M-SEARCH Information Discovery"

msf > use auxiliary/scanner/upnp/ssdp_msearch

En el primer paso del proceso de ataque, una solicitud SOAP (M - SEARCH) se envía a un UPnP - dispositivo activado, El paquete M - Search  identifica los dispositivos vulnerables. El dispositivo responde a la solicitud con la ubicación HTTP de su archivo de descripción de dispositivos, un archivo XML.

O buscar con nmap: 

nmap -sU -pU:1900 -Pn -n --script=upnp-info  74.193.198.x

 Resultado ejemplo:

Nmap scan report for 74.193.198.x

Host is up.

PORT     STATE SERVICE

1900/udp open  upnp

| upnp-info:

| 74.193.198.158

|     Server: Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0

|     ST: upnp:rootdevice

|     USN: uuid:1b3a60b8-1dd2-11b2-a962-c354ab4f61f7::upnp:rootdevice

|_    Location: http://192.168.0.1:65530/rootDesc.xml

 La respuesta deberá ser enviada en el siguiente formato

HTTP/1.1 200 OK

CACHE-CONTROL: max-age = seconds until advertisement expires

DATE: when response was generated

EXT:

LOCATION: URL for UPnP description for root device

SERVER: OS/version UPnP/1.1 product/version

ST: search target

USN: composite identifier for the advertisement BOOTID.UPNP.ORG: number increased each time device sends an initial announce or an update message

Multicast:

M-SEARCH * HTTP/1.1

HOST: 239.255.255.250:1900

MAN: "ssdp:discover"

MX: seconds to delay response

ST: search target

USER-AGENT: OS/version UPnP/1.1 product/version

Unicast:

M-SEARCH * HTTP/1.1

HOST: hostname:portNumber

MAN: "ssdp:discover"

ST: search target

USER-AGENT: OS/version UPnP/1.1 product/version

Contramedidas - Mitigación

Es casi imposible mitigar el ataque desde el lado de la víctima....

- Los paquetes del DDoS (Ataque de denegación de servicio distribuido) podrían venir de cualquier parte del mundo

Podemos limitar con iptables el tráfico udp

# Limitar el UDP flood

# Crear la cadena para UDP flood

iptables -N cadena-udp-flood

# Saltar a la cadena cuando el UDP es detectado

iptables -A INPUT -p  udp -j cadena-udp-flood

# Limitar la velocidad UDP  a 10/segundos con limite de 20

iptables -A cadena-udp-flood -m limit – -limit 10/s – -limit-burst 20 -m comment – -comment “Limite velocidad UDP” -j RETURN

# Logear

iptables -A cadena-udp-flood -m limit – -limit 6/h – -limit-burst 1 -j LOG – -log-prefix “Probable udp flood “

# Baneados durante 5 minutos los que más floodean

iptables -A cadena-udp-flood -m recent – -name blacklist_300 – -set -m comment – -comment “BlackList origen IP” -j DROP 

Módulo limit (iptables)

Diferencias entre limit y limit burst

Usando el módulo limit

-m limit

Podemos hacer uso de limit y limit burst

 iptables -I FORWARD -p udp -m limit --limit 200/s --limit-burst -j DROP

Con --limit se especifica una media (average), no un caudal. Por ejemplo: decir 200/s (200 por segundo) puede significar que en el primer minuto se reciben 50 paquetes y en el segundo también 50 o puede significar que en el primer minuto se reciben 100 y en el segundo 50... la media sigue siendo 200/segundo.

El limite puede ser

/second (/s)

/minute (/m)

/hour (/h)

/day (/d)

--limit-burst especifica un máximo, si no se especifica un --limit-burst por defecto vale 5 y significa que se aceptaran los primeros 5 paquetes y luego se esperara hasta alcanzar la media para seguir aceptando.  

Módulo Recent (iptables)

El módulo de IPTables recientes tiene algunas limitaciones. Por defecto, sólo hace un seguimiento de las 100 más recientes 100 IPs, y los últimos diez paquetes de cada una. Si tienes una gran cantidad de direcciones IP de origen de golpe, estos límites pueden no ser suficientes.

Soluciones - Mitigación - Contramedidas

Los servidores vulnerables deberían ser cerrados o configurados correctamente:

DNS En Bind DNS los servidores que sean "Open resolvers" deben usar Response Rate Limiting (RRL). usar ACL'S

Chargen (Character Generator Procotol) totalmente obsoleto, actualmente no se utiliza para nada. Diseñado en el año 1980.

Echo no amplifica

NTP (Networt Time Protocol) no responder al comando, orden "monlist" es vulnerable se pueden filtrar consultas mediante "restrict"

SNMP (Simple Network Management Protocol) distinguir entre public y private además de usar ACL. Deshabilitar SNMPv1 y v2, usar v3 y proteger con contraseña.

El Grupo de Trabajo de la Red de la Internet Engineering Task Force (IETF) publicó Best Current Practice documento 38 en mayo de 2000 y Mejores Prácticas actuales 84 marzo 2004 que describe como un proveedor de servicios de Internet puede filtrar el tráfico de red en su red para rechazar los paquetes con direcciones de origen no puede llegar a través del recorrido del paquete actual

Los paquetes falsos deberían prohibirse en el origen (BCP38) Network Ingress Filtering: Defeating Denial of Service Attacks que emplea "IP Source Address Spoofing"

Implementar (para evitar IP Spoofing)

BCP38 (RFC2827)

BCP84 (RFC3704)

¿Qué es BCP38?

El documento BCP38 corresponde al estándar RFC2827: Filtrado de redes en ingreso: derrotando los ataques de denegación de servicio que utilizan direcciones IP de origen falsificadas (Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, en el inglés original). Es decir, es un documento que explica estos ataques, y recomienda a los operadores de redes las mejores forma de evitarlos.

Los ataques de Denegación de Servicio (DoS), y sus primos aún peores de Denegación de Servicio Distribuido (DDoS), siempre han sido difíciles de manejar. Y si a eso le sumamos que los paquetes que componen el ataque podrían tener su origen falsificado, no solo se hace más dificil detener el ataque, sino también se hace imposible deternimar desde dónde viene.

La solución a este problema, descrito en el RFC2827 escrito hace 13 años atrás por Paul Ferguson y Daniel Senie, es bloquear los paquetes IP en el momento de entrar a Internet si es que tienen direcciones IP falsificadas -- es decir, direcciones IP que no fueron asignadas al dispositivo que los está enviando. Existe un pequeño número de casos en los que esos paquetes not son fraudulentos, pero ese porcentaje es tan bajo que se pueden manejar como excepciones mantenidas a mano, incluso en ambientes donde tales paquetes serían bloqueados en su origen -- el título 'Filtrado en ingreso' mencionado en el RFC. 

La idea es simpple. Dropear (drop, descartar) los paquetes que entran la red (border router) cuya dirección de origen no es la misma que la dirección de red asignada de la red de origen

Implementar filtros ingress/egress filter en el border router del ISP:

Para verificar si en su red se ha implementado el filtrado de entrada, puedes descarga las herramientas de código abierto del proyecto Spoofer:

http://spoofer.cmand.org/index.php

Ejemplos:

Mitigated by Sevi

DoS UDP Misuse

DoS IP Private Misuse

DoS TCP SYN Misuse

DoS TCP RST Misuse

DoS Fragmentation Misuse 

Reporte PPS (Packets per second, paquetes por segundo) y BPS (Bits per second) 

Herramientas - Tools

scapy (python)

hping3

packit

nemesis

r2dr2-udp-drdos-tool

LOIC (Low orbit Ion Canon) (udp flood directo), no hay spoofing, por lo tanto no amplifica) 

HOIC (High Orbit Ion Cannon)

SLOWLORIS

Scapy es una biblioteca de manipulación de paquetes para elaborar paquetes. La biblioteca Scapy permite crear protocolos de paquetes fácilmente y simplifica el IP spoofing.

from scapy.all import *

    packet = IP(dst=ssdpserver,src=target)/UDP(sport=1900,dport=1900)/Raw(load=data)

Dónde DATA es el payload

Low Orbit Ion Cannon (abreviado LOIC) es una aplicación diseñada para realizar un ataque de denegación de servicio durante el proyecto Chanology, desarrollada por Praetox, usando el lenguaje de programación C# (Existe también un fork en C++ y Qt llamado LOIQ). La aplicación realiza un ataque de denegación de servicio del objetivo enviando una gran cantidad de paquetes TCP, paquetes UDP o peticiones HTTP con objeto de determinar cuál es la cantidad de peticiones por segundo que puede resolver la red objetivo antes de dejar de funcionar. 

High Orbit Ion Cannon , es la herramienta que sustituyo a L.O.I.C por la diferencia en su efectividad de dejar fuera de servicio un sitio web.

Características:

Posee una alta velocidad en las tareas de multi-thread HTTP Flood (inundación HTTP). 

Capaz de saturar simultáneamente más de 256 websites. 

Construido sobre sistema de scripts para permitir el despliegue de 'boosters'(refuerzos): secuencias de comandos diseñadas para frustrar contramedidas y aumentar la potencia de salida del DoS.

Selección de Boost previamente creados (Targets ya predeterminados).

Posibilidad de regular la cantidad de threads para el ataque (piensa en cada thread como en un cañón).

Posibilidad de regular la cantidad de threads para el ataque (piensa en cada thread como en un cañón).

Desarrollado en lenguaje REAL BASIC.

No requiere de instalación, y sólo utiliza un ejecutable.

Herramientas que permiten falisifcar (spoof) la dirección ip real del atacante mediante la propia naturaleza del protecolo UDP.

HPing (hping3) es una herramienta en linea de comandos que nos permite crear y analizar paquetes TCP/IP, y como tal tiene un muchas utilidades: hacer testing de firewalls, escaneo de puertos, redes y como no… también tiene la capacidad de provocar un SYN Flood Attack (DDoS).

hping3 [opciones] host

Opciones básicas

-c número paquetes

-i intervalo espera (uX para esperar X microsegundos, eg. -i u1000)

--fast alias -i u10000 (10 paquetes/segundo)

--faster alias -i u1000 (100 paquetes/segundo) 

--flood envío de paquetes sin espera (lo más rápido posible)

Modo funcionamiento (si no se especifica, default mode TCP)

-0 --rawip RAW IP mode

-1 --icmp ICMP mode

-2 --udp UDP mode

-8 --scan SCAN mode

-9 --listen listen mode

-a --spoof spoof dirección origen

--rand-source especificar dirección de origen aleatoria

UDP/TCP

-s --baseport puerto de origen

-p --destport puerto destino

-S --syn flag SYN

-R --rst flag RST

Packit (apt-get install packit) es una herramienta para la captura e inyección de paquetes que permite personalización paquetes: TCP, UDP, ICMP, IP, ARP, RARP, Ethernet header

packit [-t protocolo] opciones

Opciones básicas de inyección de paquetes

-t protocolo TCP (defecto), UDP, ICMP, ARP

-c número Número de paquetes a inyectar (0: continuo)

-w número Intervalo (en seg.) entre cada conjunto de paquetes (def. 1)

-b número Número paquetes a inyectar en cada intervalo (0: máximo)

-s dirección IP origen (spoofing)

-sR Establece dirección IP origen aleatoria

-d dirección IP destino

-dR dirección Establece una dirección destino aleatoria

-S puerto Indica puerto origen en TCP y/o UDP

-D puerto Indica puerto destino en TCP y/o UDP

-F flags Flags TCP : S(SYN), F(FIN), A(ACK), P(PSH), U(URG), R(RST)

-h Host Response: salida por pantalla 20