MANUALDEHACKER-COM-DDOS-ATAQUE-2

MANUAL ATAQUE DDOS 2

ATAQUE DDOS MANUAL DISTRIBUITED DENIAL OF SERVICE


3.DoS sencillos

Logica poca, pero bueno, siempre hay algun bicho raro por ahi…
Solo enumero algunos, para saber que existen, pero no tienen la belleza del DDoS ñ_ñ

  * X-Servers:

    Es facil tirar un X-Server. Si el StickyBit no esta puesto en el directorio /tmp.. borrando el archivo /tmp/.X11/x0 o /tmp/.x11-unix/x0 (normalmente los directorios son estos 2 .X11 o
    .x11-unix)

  * Creando multiples procesos:

      #include <sys/types.h>
      #include <unistd.h>
      #include <iostream.h>

      main()
      {
         while(1)
         {
           system("sync");
           fork();
         }
      }


  * Linux & Time service:

   El InetD en linux se viene abajo si se envian muchos paketes SYN a los puertos time-37 o daytime-13

4.Tipos de Denegaciones

Syn Flood
^^^^^^^^^

Cuando dos procesos establecen una comunicacion usan el modelo Cliente/Servidor para establecer la conexion. La aplicacion del Servidor ‘escucha’ todo lo que mandan por los puertos. La identificacion del Servidor se efectua a traves de la direccion IP del sistema en el que se ejecuta y del numero de puerto del que depende para la conexion. El Cliente establece la conexion con el Servidor a traves del puerto disponible para luego intercambiar datos.

La informacion de control llamada HandShake (saludo) se intercambia entre el Cliente y el Servidor para establecer un dialogo antes de transmitir datos.

Los paquetes o segmentos TCP tienen banderas que indican el estado del mismo.

El protocolo TCP de Internet, sobre el que se basa la mayoria de los servicios (incluyendo el correo electronico, el web y el IRC) implica esta conexion entre dos maquinas. El establecimiento de dicha conexion se realiza mediante lo que se llama Three-Way Handshake (‘conexion en tres pasos’) ya que intercambian tres segmentos. En forma esquematica se tiene:

  1. El programa Cliente (C) pide conexion al Servidor (S) enviandole un segmento SYN (Synchronize Sequence Number). Este segmento le dice a S que C desea establecer una conexion.
  2. S (si esta abierto y escuchando) al recibir este segmento SYN (activa su indicador SYN) y envia una autentificacion ACK a modo de acuse de recibo a C. Si S esta cerrado envia un indicador RST.
  3. C entonces ACKea (autentifica) a S. Ahora ya puede tener lugar la transferencia de datos.

Cuando las aplicaciones conectadas terminan la transferencia, realizaran otra negociacion a tres bandas con segmentos FIN en vez SYN.

La tecnica TCP SYN flooding, implementa un flood de ‘media-apertura’, dado que nunca se abre una sesion TCP completa. El Cliente envia un paquete SYN pero no responde al paquete ACK ocasionando que la pila TCP/IP espere cierta cantidad de tiempo a que el host hostil responda antes de cerrar la conexion. Si se crean muchas peticiones incompletas de conexion (no se responde a ninguna), el Servidor estara inactivo mucho tiempo esperando respuesta. Esto ocasiona la lentitud en los demas servicios. Se puede ver el numero de conexiones SYN_RECV de un sistema utilizando el netstat.

El problema es que muchos sistemas operativos tienen un limite muy bajo en el numero de conexiones semiabiertas que pueden manejar en un momento determinado. Si se supera ese limite, el servidor sencillamente dejara de responder a las nuevas peticiones de conexion que le vayan llegando. Las conexiones semiabiertas van caducando tras un tiempo, liberando ‘huecos’ para nuevas conexiones, pero mientras el atacante mantenga el Syn Flood, la probabilidad de que una conexion recien liberada sea capturada por un nuevo SYN malicioso es muy alta.

La potencia de este ataque reside en que muchos sistemas operativos fijan un limite del orden de 5 a 30 conexiones ‘semiabiertas’, y que estas caducan alcabo de un par de minutos. Para mantener el servidor fuera de servicio, un atacante solo necesita enviar un paquete SYN cada 4 segundos (algo al alcance de, incluso, un modem de 300 baudios).

La principal ventaja de esta tecnica es que pocos sitios estan preparados para detecarlos, con lo que el firewall no los pararia. La desventaja es que en algunos sistemas Unix, se necesita ser root para construir estos paquetes SYN.

TCP FIN Flooding
^^^^^^^^^^^^^^^^

Puede pasar que no te interese que algun tipo de filtro detecte los paquetes SYN. Esto es logico si tenemos pocas maquinas desde las que atacar, si a eso le sumamos que el firewall de la victima nos para los pocos paquetes, tal vez consumamos algo de ancho de banda… pero poco mas. Asi que si conseguimos saltarnos el firewall, esos pocos paquetes iran al corazon de la pila de red.

Para subsanar este inconveniente los paquetes FIN. Este tipo de flood esta basado en la idea de que los puertos cerrados tienden a responder a los paquetes FIN con el RST correspondiente. Los puertos abiertos, en cambio, suelen ignorar el paquete en cuestion.

Este es un comportamiento correcto del protocolo TCP, aunque algunos sistemas (entre los que se hallan los de Microsoft) no cumplen con este requerimiento, enviando paquetes RST siempre, independientemente de si el puerto esta abierto o cerrado.

Este ultimo es un ejemplo en el que se puede apreciar que algunas vulnerabilidades se presentan en las aplicacion de tecnologias (en este caso el protocolo TCP nacido en los años ´70) y no sobre sus implementaciones. Es mas, se observa que una implementacion incorrecta (la de Microsoft) soluciona el problema. ‘Muchos de los problemas globales de vulnerabilidades son inherentes al disño original de algunos protocolos’.

Como ya se explico en el TCP SYN Flooding el protocolo TCP se basa en una conexion en tres pasos. Si el paso final no llega a establecerse, la conexion permanece en un estado denominado ‘semiabierto’.

Antes de utilizar esta tecnica convendria averiguar el comportamiento de la victima ante un FIN a un puerto abierto y a uno cerrado. Y despues, segun lo que pase, combinar, adaptar y crear paquetes al gusto del consumidor.

Connection Flood
^^^^^^^^^^^^^^^^

Los servicios TCP orientados a conexion, que son la mayoria (telnet, ftp, http, smtp, nntp…) tienen un limite maximo de conexiones simultaneas soportadas; cuando este limite se alcanza, cualquier conexion nueva es rechazada.

De forma similar al Syn Flood, si un atacante es capaz de monopolizar el limite definido con conexiones de su propiedad, que simplemente son establecidas pero por las que no se realiza ninguna comunicacion posterior, el sistema no proporcionara servicio.

Al igual que antes, las conexiones expiran progresivamente con el paso del tiempo, pero un ataque constante de apertura de conexiones mantendra continuamente el limite en su valor maximo. La diferencia esta en que en este caso la conexion se ha establecido y por tanto se conoce la identidad del atacante (direccion IP), y a su vez, la capacidad del sistema o sistemas atacante/s debe ser lo suficientemente elevada como para mantener abiertas todas las sesiones que colapsan el servidor atacado.

Existe una variante de estos ataques basada en el uso de un cliente que establezca conexiones contra un sistema, pero que no las finalice de forma correcta, de modo que en el servidor los sockets correspondientes a estas comunicaciones seguiran estando activos y consumiendo recursos, concretamente en el estado TCP denominado TIME_WAIT.

Para evitar la existencia de un ataque basado en el cierre incorrecto de las conexiones, el sistema servidor puede controlar el tiempo que un socket TCP puede permanecer en el estado TIME_WAIT, evitando asi un consumo de recursos excesivo.

  • HP-UX y Solaris:

Para ello se emplea el siguiente comando limitando el tiempo a 60 segundos:

ndd –set /dev/tcp tcp_time_wait_interval 60000

  • Linux (2.2):

Igualmente, se limita el tiempo de vida del socket en este estado:

/sbin/sysctl –w net.ipv4.vs.timeout_timewait 60000

  • Linux (2.4):

En este caso, se limita el numero de sockets en este estado. En el caso de que se supere el numero, se destruiran sockets en ese estado, generandose un warning:

echo 512 > /proc/sys/net/ipv4/tcp_max_tw_buckets

  • Windows NT, 2000, XP:

A traves del editor del registro (regedt32.exe) debe localizarse la clave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Bajo la misma es necesario añadir el valor:

Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD
Value: 30-300 segundos (defecto: 240 segundos)

Land Attack
^^^^^^^^^^^

Este ataque permite bloquear un sistema, mediante el envio de un paquete SYN cuya direccion IP fuente y destino es la misma. Existe una variacion de este ataque, basada en que los puertos origen y destino tambien son iguales.

Para ello es necesario enviar paquetes IP mediante la tecnica de spoofing. Debe tenerse en cuenta que algunos sistemas IDS detectan la primera situacion y otros la segunda. Por tanto, podria darse algun caso en el que se establezca una conexion a la propia maquina, se envie por tanto un paquete [127.0.0.1:puerto_cliente ==> 127.0.0.1:puerto_servidor], y el sistema IDS lo detecte como un ataque cuando en realidad no lo es. Este ejemplo, aplicable a un gran numero de las vulnerabilidades mencionadas, refleja la estrecha linea existente entre un ataque real y una situacion convencional, denotando que sudeteccion y automatizacion no es trivial.

Este ataque se puede prevenir filtrando los paquetes recibidos cuya direccion de origen sea la misma que la de alguno de los ordenadores de la red interna.

Supernuke o Winnuke
^^^^^^^^^^^^^^^^^^^

Un ataque caracteristico (y quizas el mas comun) de los equipos con Windows es el Nuke, que se aprovecha del error llamado ‘Windows OOB bug’. OOB significa out-of-band.

Este DoS funciona de la siguiente manera: se establece una conexion TCP/IP con la direccion de destino, usando el puerto 139 (el puerto de NetBIOS). Despues el programa envia los datos empleando una marca llamada MSG_OOB (o Urgente) en el encabezamiento del paquete, que indica al Winsock del ordenador que envie los datos llamados ‘datos fuera de banda’ (out-of-band-data). Tras la recepcion de esta marca, el servidor Windows al que se ha dirigido espera una indicacion de la posicion del paquete, en la que terminan los datos urgentes a los que deben seguir los datos normales, pero el indicador OOB del paquete, creado por WinNuke, indicara el final del marco, donde no encontrara datos que sigan a los datos urgentes. Con todo ello, lo que se provoca es que la maquina Windows no sepa como enfrentarse al problema e interrumpe la comunicacion de la red, produciendose de esta forma una denegacion del servicio a todos los usuarios que intentan comunicarse con el servidor.

Un ataque WinNuke suele exigir el reinicio del ordenador para asi poder restablecer la comunicacion con la red.

Tanto Windows 95 como NT 3.51 y 4.0 son vulnerables a estos ataques, a menos que se instalen los parches proporcionados por Microsoft, mientras que Windows 98/ME y 2000/XP no son vulnerables a este ataque. Desgraciadamente aun quedan muchas redes en las que se usan los sistemas operativos mas antiguos de Microsoft, y muchas veces no se han aplicado las actualizaciones y los paquetes de servicio correspondientes.

Teardrop I y II/Newtear-Bonk-Boink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Al igual que el Supernuke, los ataques Teardrop I y Teardrop II afectan a fragmentos de paquetes. Algunas implementaciones de colas IP no vuelven a armar correctamente los fragmentos que se superponen, haciendo que el sistema se cuelgue. El problema es que los campos de desfase de estos fragmentos, que se supone que indican la porcion (en bytes) del paquete original que contiene cada uno de los fragmentos, se pueden superponer.

Windows NT 4.0 de Microsoft es especialmente vulnerable a este ataque. Aunque existen parches que pueden aplicarse para solucionar el problema, muchas organizaciones no lo hacen, y las consecuencias pueden devastadoras.

Los ataques tipo Teardrop son especialmente peligrosos ya que existen multitud de implementaciones (algunas de ellas forman paquetes), que explotan esta debilidad. Las mas conocidas son aquellas con el nombre Newtear, TearDrop2, SynDrop, Bonk y Boink.

Por ejemplo, normalmente los campos de desfase de dos fragmentos pueden aparecer de la siguiente forma:

Fragment 1: (offset) 100 - 300
Fragment 2: (offset) 301 - 600

Esto indica que el primer fragmento contiene los bytes del 100 al 300 del paquete original, mientras que el seguno contiene los bytes del 301 al 600.

Sin embargo, los campos de superpuestos suelen tener esta forma:

Fragment 1: (offset) 100 - 300
Fragment 2: (offset) 200 - 400

Cuando el ordenador de destino intenta volver a montar estos paquetes, no puede conseguirlo, provocandose un cuelgue o reinicio del ordenador.

Paquetes fragmentados
^^^^^^^^^^^^^^^^^^^^^

Esta tecnica es una modificacion de las anteriores. En lugar de enviar paquetes completos, particionamos en un par de pequeños fragmentos IP. Asi, se logra partir una cabecera IP en distintos paquetes para hacerlo mas dificil de monitorizar por los filtros que pudieran estar ejecutandose en la maquina objetivo. Haciendo que se sobrecargue el sistema del a victima.

Existen dos formas de afrontarlo:

  • Metodo directo:
    Existe un valor TMIN que indica la longitud minima de la cabecera TCP requerida para contener toda la informacion de transporte relevante, desde el punto de vista de los filtros de paquetes. La medida se toma desde el comienzo de la cabecera TCP en el paquete original (sin fragmentar). El control se basa en analizar los paquetes con un offset de cero frente a este valor, para no permitir paquetes con un valor de TMIN menor.
  • Metodo indirecto:
    Este se basa en el analisis de un paquete TCP, de forma que cuando es fragmentado, si los campos que definen los flags no se encuentran en el paquete inicial, este se deja pasar, pero al recibirse el siguiente fragmento, en base al campo FO, Fragment Offset, se descarta, con lo cual se bloquea el proceso de reconstruccion del paquete original.

Finger Bomb
^^^^^^^^^^^

La mayoria de las instalaciones de fingerd dejan redireccionar a otro host.

Ejemplo:

$finger @sistema.dos.com@sistema.uno.com

Finger en el ejemplo tendra que ir a traves del sistema.uno.com y despues al sistema.dos.com. Todo lo que el sistema.dos.com sabe es que el sistema.uno.com esta contactandole usando finger. Este metodo puede ser usado para esconderte, pero tambien para hacer uso de un truco sucio. Ejemplo:

$ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.que.atacamos.com

Todos esos signos @ ocasionaran que finger llame a host.que.atacamos.com una y otra vez. El efecto es desastroso para host.que.atacamos.com resultando en un alto uso del ancho de banda y falta de memoria debido a todos los procesos creados.

La solucion es instalar un fingerd que no soporte redirecciones, por ejemplo el finger GNU. Tambien puedes desinstalar el servicio finger.

Email Bombing
^^^^^^^^^^^^^

En un ataque de email se envian muchos mensajes identicos a una o varias direcciones del host. El efecto en el objetivo es un alto uso del ancho de banda y menos espacio de disco. Cuando envias muchos mensajes a una direccion inexistente del host desde otra inexistente, el mensaje crecera debido a las cabeceras. Ira de un lado a otro creciendo. Por mas odioso que se vea este ataque es bastante efectivo y aun no es ilegal en muchos paises latinoamericanos y europeos.

Ejemplo:
Envia un mail de 100k a noexiste@host.atacado.com desde una direccion que no exista como noexiste@esta.direccion.zus Cuando el mensaje llege a host.atacado.com como no existe la direccion noexiste regresara el mensaje a noexiste@esta.direccion.zus y como esta direccion tampoco existe, regresara ahora como un mensaje de 300k y asi…
Si lo haces con dos cuentas del mismo servidor, todo sera mas rapido (y menos doloroso :P).

Otra forma de abusar el email y servidores norteamericanos es juntar varios remailers. Por ejemplo:

Suponiendo que tenemos nosotros una cuenta en Geocities. Digamos uno@geocities.com y le decimos que queremos que el mail que llegue a esa direccion lo mande a dos@bigfoot.com. Ahora en la cuenta dos@bigfoot.com le decimos que lo mande a tres@iname.com. Y en la cuenta tres@iname.com le decimos que lo mande a uno@geocities.com. Despues mandamos un mega o dos a uno@geocities.com que lo mandara a dos@bigfoot.com y de ahi a tres@iname.com y de nuevo a uno@geocities.com… Si mandas 5 megas a saber que puede pasar!

MAC flooding
^^^^^^^^^^^^
Esta tecnica intenta colgar o reiniciar los perifericos de red (routers por ejemplo) inundandon las tablas con MACs falsas.

DNS flood
^^^^^^^^^

El ataque DNS flood saca partido de las diferencias de tamaño entre una solicitud DNS y su respuesta, haciendo que todo el ancho de banda de la red este atascado por falsas respuestas DNS. El atacante utiliza los servidores DNS como amplificadores, para multiplicar el trafico DNS.

El atacante comienza enviando pequeñas solicitudes DNS, que contienen la direccion IP spoofeada de la victima, a cada servidor DNS. Las respuestas devueltas a las pequeñas peticiones son mucho mayores que si se devolvieran muchas respuestas al mismo tiempo, congestionandose el vinculo y produciendose la negacion de servicio.

Una de las soluciones para este problema es que los administradores configuren los servidores DNS para responder con una respuesta de ‘rechazado’, que tiene un tamaño mucho menor que una respuesta de resolucion de nombre, cuando reciben las solicitudes DNS de fuentes sospechosas o inesperadas.

Bucle UDP/Snork UDP
^^^^^^^^^^^^^^^^^^^

Un atacante puede utilizar el Protocolo de Datagrama de Usuario (User Datagram Protocol :P) y uno de los muchos servicios que responden a los paquetes que reciben para crear una congestion en la red, generando un flujo de paquetes UDP entre uno o dos sistemas escogidos.

Por ejemplo, el servicio chargen del primer ordenador, que es una herramienta de pruebas que genera una serie de caracteres por cada uno de los paquetes que recibe, envia paquetes al servicio de eco UDP de otro sistema, que responde a cada uno de los caracteres que recibe. El chargen UDP se encuentra en el puerto 19. Al aprovechar estas herramientas de pruebas se consigue un flujo interminable de ecos entre y salga de los dos sistemas, floodeando la red.

A este proceso tambien se le suele llamar tormenta de paquetes UDP o bomba UDP. Ademas del puerto 7 (el puerto del eco), un atacante puede utilizar el puerto 17, el servicio de la cita del dia (quotd) o bien el servicio del dia del puerto 13, servicios que tambien responden con ecos a los paquetes que reciben. La desactivacion de los servicios UDP innecesarios en cada uno de los ordenadores nos protegera de este ataque. Filtrar los puertos con un firewall no ayudaria mucho, mas abajo explico alguna de las formas de saltarse los firewalls.

El ataque Snork es similar al bucle UDP. Emplea un marco UDP en el que el puerto de origen puede ser el 7 (echo) o el 9 (chargen) y el puerto de destino es el 135 (servicio de localizacion de Microsoft). Con ello se consigue el mismo resultado que con el bucle UDP, un flujo de transmisiones basura que reduce el rendimiento o hace que el/los sistema/s quede/n anulado/s.

Anterior

Continuación

Dejar una contestacion

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.