MANUALDEHACKER-COM-DDOS-ATAQUE-4

MANUAL ATAQUE DDOS 4


ATAQUE MANUAL DDOS DISTRIBUITED DENIAL OF SERVICE

8.Filtros

8.1.Medidas de proteccion ante los ICMP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Dado que ahora las conexiones suelen ser de alta velocidad en la mayoria de la gente, intentar inundar la victima desde pocos ordenadores con paquetes ICMP esuna tonteria. Para que tenga efecto, necesitarias muchas maquinas a tu disposicion. En teoria los ISP deeberian limitar el numero de paquetes ICMP que atraviesan sus firewalls y routers pero como he dicho, en teoria.

Los firewalls actuales (incluyendo el filtrado de paquetes del nucleo de linux) puden limitar o desactivar totalmente el ICMP en las redes que protegen.

8.2.Medidas de proteccion contra la inundacion SYN
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A parte de mantener el kernel de tu sistema operativo actualizado, deberias consutar varias entradas en el directorio /proc. Puedes modificar ciertos parametros para disminuir el tiempo de espera por un paquete SYN/ACK y para establecer el numero maximo de paquetes SYN de salida que se pueden almacenar en la cola:

Jana# cat /proc/sys/net/ipv4/vs/timeout_synack
100
Jana# cat /proc/sys/net/ipv4/vs/timeout_synrecv
10
Jana# /proc/sys/net/ipv4/tcp_max_syn_backlog
130

Si alguna de tus maquinas esta siendo atacada por una inundacion SYN, incrementa el valor de tcp_max_syn_maxlog y disminuye los tiempos de espera timeout_*.


9.Prevencion y respuesta

Existen varios pasos que los administradores pueden dar para ayudar a prevenir el acceso a traves de los puntos debiles de los protocolos, aplicaciones y sistemas operativos, por ejemplo:

-Asegurarse de que todos los sistemas disponen de los ultimos parches de seguridad. La aplicacion de los parches puede dar proteccion frente a la mayor parte de los DoS, que se suelen basar en problemas del Sistema operativo o de los protocolos.

-Los sistemas Linux se pueden proteger de los ataques SYN compilando el kernel con cookies SYN. Algunas versiones de UNIX (como solaris 2.6 y superiores) incluyen proteccion ante los ataques SYN. En Windows 2000 se puede editar el registro para protegerse ante los ataque SYN.

-Se puede configurar el router para que responda a las difusiones dirigidas, en vez de pasarlas a la subred, protegiendose asi del SmurF.

-El router tambien se puede configurar para que filtre todos los paquetes entrantes que dispongan de una IP que aparente pertenecer a la red local.

-Configurar el sistema para ignorar los redireccionados del router.

-Desactivar Java, JavaScript, ActiveX y el resto de los contenidos activos del explorador puede anular muchos de los principales puntos debiles del explorador.

-Usar firewall y NIDS

-Cambiar todo lo que sea standard; el passwd del router, usar un explorador de internet que no sea el de Microsoft, etc.    

10.Sobre los NIDS (Network Intrusion Detection System)

Si estamos seguros de que queremos lanzar un DDos sobre cierta compañia o persona/s, deberemos optimizar el ataque para que cumpla su funcion.

Uno de los pasos a cuidar es, si vas a utilizar una herramienta de DDoS publica, cambiar TODOS los valores por defecto (puertos, passwords, banners, etc) ya que habran reglas para los NIDS.

Hay dos tipos de trafico generado por un DDoS, el trafico de control (entre los agentes y los masters) y el trafico del floodeo (entre la/s victima/s y los agentes).

Una de las posibles detecciones por parte del NIDS es sobre los paquetes enviados. Las sesiones UDP normalmente se mandan paquetes pequeños, con un cuerpo de no mas de 10 bytes. Y sobre los paquetes ICMP decir que suelen estar entre 64 y 128 bytes. Asi que los paquetes que sean demasiado grandes son sospechosos de ser el trafico de control de algun DDoS, y si encima estan cifrados es mas mosqueante aun.

Siempre se puede obtener como minimo una informacion de cualquier agente (por muy sofisticado que sea), y es la IP de la victima. Es el unico dato que no puede estar cifrado, asi que si nuestra red esta actuando de agente, podemos configurar una regla en el firewall para que no deje salir ningun paquete hacia esa IP.

Los paquetes TCP y UDP no son partes de una conexion. El modulo de ocultacion de las herramientas DDoS usan protocolos aleatorios, incluyendo los orientados a conexiones, para mandar informacion sobre canales no orientados a conexiones.

Un firewall puede detectar estos paquetes. Ademas, los paquetes que indican una peticion de conexion a puertos superiores a 1024, que no se traten de algun puerto standard (ej IRC-6667) son sospechosos.

El cuerpo de los paquetes contienen SOLO caracteres alfanumericos (sin espacios, signos de puntuacion, caracteres de control…). Esto puede decirnos que el cuerpo esta codificado en BASE64, y por lo tanto, solo contiene caracteres propios de la codificacion en BASE64.

Puesto que el trafico de control del TFN2K es mediante UDP, para evitar la deteccion de los paquetes y hacer todo algo mas silencioso, lo que hace es no mandar los ACK de respuesta. Se limita a mandar 10 veces cada paquetes (y alguno llegara, no??).

El patron especifico del TFN2K y sus derivados lacteos ñ_ñ es usar un string de A’s (AAAAA…) en el cuerpo, desde que la rutina de cifrado rellena el tamaño del buffer. Si no esta codificado en BASE64, y el cuerpo contiene trafico binario encriptado, las A’s se convierten en \0’s binario.


11.Bastion Hosts

La primera regla de oro a la hora de securizar un sistema (hardening o armoring), tanto Unix como Windows, pasa por deshabilitar todos los servicios TCP/IP innecesarios. A su vez, son multiples los controles que pueden llevarse a cabo, tanto desde el punto de vista del sistema (no analizados en este documento centrado en TCP/IP) como de la red, en los que se profundiza en este documento.

Las recomendaciones de configuracion respecto a la pila TCP/IP que se presentan a continuacion no han sido incluidas en referencias especificas para la proteccion de una vulnerabilidad concreta comentada.

  • HP-UX:
    Existen dos documentos de referencia a la hora de securizar el sistema operativo HP-UX, para la version 11.00 y para la 10.X.

Concretamente, para ajustar la seguridad mediante los parametros de red de TCP/IP se deben añadir las siguientes lineas al fichero /etc/rc.config.d/nddconf.

# Para evitar que se propaguen paquetes de una interfaz a otra (uso de routing)
TRANSPORT_NAME[1]=ip
NDD_NAME[1]=ip_forwarding
NDD_VALUE[1]=0
#
# Para evitar el chequeo de gateway muerto (este no funciona bien con firewalls)
TRANSPORT_NAME[2]=ip
NDD_NAME[2]=ip_ire_gw_probe
NDD_VALUE[2]=0
#
# Para evitar el uso de la estrategia PMTU discovery (echo-request).
TRANSPORT_NAME[3]=ip
NDD_NAME[3]=ip_pmtu_strategy
NDD_VALUE[3]=1
#
# Para no enviar ICMP source quench
TRANSPORT_NAME[4]=ip
NDD_NAME[4]=ip_send_source_quench
NDD_VALUE[4]=0
#
# Para evitar que se responda a peticiones Timestamp
TRANSPORT_NAME[5]=ip
NDD_NAME[5]=ip_respond_to_timestamp
NDD_VALUE[5]=0
#
# Para no enviar mensajes en paquetes de reset de TCP
TRANSPORT_NAME[6]=tcp
NDD_NAME[6]=tcp_text_in_resets
NDD_VALUE[6]=0
  • Solaris:
    Los parametros de configuracion generales recomendados en este SO son aplicables a un fichero de arranque del sistema, por ejemplo /etc/rc2.d/S69inet.

Para que todos estos cambios tengan efecto se deben ejecutar los siguientes comandos:

# /etc/rc2.d/S69inet stop
# /etc/rc2.d/S69inet start

Para evitar que la maquina encamine paquetes desde una interfaz a otra se debe incluir la siguiente linea:

ndd –set /dev/ip ip_forwarding 0

Para evitar que por cualquier interfaz de una maquina se reciban paquetes con destino a direcciones IP correspondientes a otros interfaces de la maquina, se debe incluir la linea:

ndd –set /dev/ip ip_strict_dst_multihoming 1

Para evitar que se responda a peticiones Timestamp se debe incluir la siguiente linea:
ndd -set /dev/ip ip_respond_to_timestamp 0

  • Linux:
    Al igual que los dos sistemas Unix previos, existen guias similares para Linux.

Asimismo, existen versiones completas derivadas de Linux enfocadas desde el punto de vista de la seguridad, como Trinux (http://www.trinux.org/) u Openwall Owl (http://www.openwall.com/Owl/).

Chequeo del gateway activo o no:
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: EnableDeadGWDetect
Data Type: REG_DWORD
Value: 0 (desactivarlo)

Las referencias respecto a los diferentes parametros configurables de las pilas TCP/IP de los distintos sistemas operativos son multiples. A modo de ejemplo se muestran las principales:

  • “UNIX IP Stack Tunning Guide v2.7”:
    http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html
  • “Enabling High Performance Data Transfers on Hosts”:
    http://www.psc.edu/networking/perf_tune.html
  • Linux kernel 2.4:
    http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO-14.html
  • Windows NT, 2000: http://support.microsoft.com/
    “TCP/IP and NBT Configuration Parameters for Windows (Q120642)”
  • Windows XP: http://support.microsoft.com/
    “TCP/IP and NBT Configuration Parameters for Windows XP (Q314053)”
  • “Solaris 2.X – Tuning Your TCP/IP Stack and more”:
    http://www.sean.de/Solaris/tune.html

12.Bastion routers

Al igual que ocurre con los sistemas, los dispositivos de red deben ser configurados desde un punto de vista restrictivo, de forma que imposibiliten explotar la mayoria de vulnerabilidades comentadas. Para ello se configuran como un bastion router.

Las caracteristicas vulnerables de un router considerandolo como un host son:

- Existencia de claves en claro en la configuracion.
- Servicios TCP y UDP simples activos: echo, discard, daytime...
- Protocolos de routing sin autenticacion y/o encriptacion.
- Protocolos AAA sin encriptacion.
- Aceptacion de paquetes source routing.
- Redirecciones IP.
- Proxy ARP.
- CDP, Cisco Discovery Protocol.
- Servidor HTTP activo.

A continuacion se comentan algunos de los comandos que permiten securizar (hardening o armoring) desde el punto de vista de TCP/IP un router Cisco. Otros se han comentado en la seccion asociada a la defensa de un ataque especifico.

Deshabilitar los siguientes servicios:

  • Finger:
    no service finger
  • Servicios simples: echo, discard, daytime.
    no service tcp-small-servers
    no service udp-small-servers
  • HTTP server:
    no ip http server
  • Proxy ARP: en algunos escenarios, el uso de un Proxy ARP puede condicionar a que el trafico circule por un camino que no es el impuesto por los protocolos de routing.
    no ip proxy-arp
  • Deshabilitar el Protocolo CDP:
    no cdp run

13.Conclusion

Bajo mi punto de vista no existe proteccion para evitar un DDoS. Porque si no te lo hacen a la red (u ordenador) te lo haran al ancho de banda. Asi que estamos casi casi en lo mismo: imposibilidad de trabajar con la red.

En estos casos, la red victima no puede hacer nada. Aunque filtre el trafico en sus sistemas, sus lineas estaran saturadas con trafico malicioso, incapacitandolas para cursar trafico util. Un ejemplo habitual es el de un telefono: si alguien quiere molestar, solo tiene que llamar, de forma continua.

Si se descuelga el telefono (para que deje de molestar), tampoco se puede recibir llamadas de otras personas. Este problema es habitual, por ejemplo, cuando alguien intenta mandar un fax empleando el numero de voz: el fax insiste durante horas y sin que el usuario llamado pueda hacer nada al respecto.

El atacante envia tantos paquetes de solicitud de conexion que las conexiones autenticas simplemente no pueden competir. En casos asi el primer paso a realizar es el ponerse en contacto con el Proveedor del servicio para que intente determinar la fuente del ataque y, como medida provisional, filtre el ataque en su extremo de la linea. El siguiente paso consiste en localizar las fuentes del ataque e informar a sus Administradores, ya que seguramente se estaran usando sus recursos sin su conocimiento y consentimiento. Si el atacante emplea Ip Spoofing, esto puede ser casi imposible, ya que en muchos casos la fuente del ataque es, a su vez, victima y el origen ultimo puede ser practicamente imposible de determinar.

Ahora que conocemos como va todo, podeis echar la imaginacion a volar. Por ejemplo, mientras hacemos un DDoS mediante agentes, mandar unos cuantos ICMP a unos broadcasts simulando ser la victima. Previamente habras tenido que mirar si el ISP de dicho server admite el spoofeo.

O si eres un programador loco, diseñar un agente controlado mediante paquetes ‘sueltos’ sin que haya una comunicacion apta de ser esnifada y logeada. Por ejemplo, un cierto tipo de paquete con los parametros para empezar el ataque, y otro paquete para pararlo.

En fin, que si alguien se dedica a jugar con los DDoS que se lo curre y no haga pijaditas tipicas. La grandeza esta en el arte de la creacion.

Kirby
mail to:smurfito@hush.ai

0x00

Anterior

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.