Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Buscador

Entradas Mensuales

Suscripción

¿Quieres recibir las últimas novedades del blog en tu correo?

¡Suscríbete al feed!

Foro de elhacker.net - Noticias

elhacker.NET en Facebook

Entradas populares

  • La BIOS está siendo reemplazada por UEFI (EFI), mucho más amigable y gráficamente superior.¿Tendré problemas para instalar Windows y Linux...
  • La popular distribución orientada a auditorías de seguridad Kali Linux 2017.1 ya está disponible. Esta es la primera versión del año 2017, ...
  • Los Sistemas de Prevención y Detención de Intrusos (IPS/IDS) proporcionan un nivel adicional de seguridad en las redes de datos previniendo ...

PostHeaderIcon Ataques UDP Reflection Flood DrDoS (Inundación mediante Amplificación)




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 IPhace que la dirección "origen" es en realidad  el objetivo real del ataque, donde se envían todas las respuestasCó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)
  • LDAP/CLDAP: Puerto 389 UDP. Hasta 250.000 dispositivos vulnerables. Poder amplificación hasta 70x.

NombrePuerto origen UDPDescripción
DNS53 (o aleatorio)Domain Name System
CharGEN19Character Generator Procotol
Echo7File search
QOTD17Quote of the Day
NTP123Networt Time Protocol
SNMP161Simple Network Management Protocol
SSDP1900Simple 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

ProtocolBandwidth Amplification FactorVulnerable Command
DNS28 to 54see: TA13-088A [1]
NTP556.9see: TA14-013A [2]
SNMPv26.3GetBulk request
NetBIOS3.8Name resolution
SSDP30.8SEARCH request
CharGEN358.8Character generation request
QOTD140.3Quote request
BitTorrent3.8File search
Kad16.3Peer list exchange
Quake Network Protocol63.9Server info exchange
Steam Protocol5.5Server 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 dispositivos 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.

Evitar el Spoofing: BCP38


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:


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


3 comentarios :

kuse dijo...

Muy buen artículo, felicidades. De hecho lo había visto en: http://hardc0dexploit.blogspot.com.es/2014/07/ataques-udp-reflection-flood-drdos.html

Anonymous Arab-أنونيموس العرب dijo...
Este comentario ha sido eliminado por el autor.
abel dijo...

buen articulo. felicidades.

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.