-[ 0x05 ]-------------------------------------------------------------------- -[ Hackoot DDoS ]------------------------------------------------------------ -[ by Kirby ]--------------------------------------------------------SET-30-- --== HACKOOT ~DDoS~ ==-- v1.0 por Kirby --------------------- Indice --------------------- 1.Introduccion 2.Explicacion detallada de los DDoS 2.1.Hackeando una red o pc 2.2.Sin hackear nada -SmurF -Fraggle 3.DoS sencillos 4.Tipos de Denegaciones -SYN flood -TCP FIN flood -Connection flood -Land Atack -Supernuke/Winnuke -Teardrop/Newtear -paquetes fragmentados -finger bomb -email bomb -MAC flooding -DNS flood -Bucle UDP/Snork UDP 5.Puntos debiles del SNMP 6.Jugando con los firewalls 7.Paquetes 8.filtros 8.1.ante ICMP 8.2.contra inundacion SYN 9.Prevencion y respuesta 10.Sobre los NIDS (Network Intrusion Detection System) 11.Bastion Hosts 12.Bastion routers 13.Conclusion ---------------- 1. Introduccion ---------------- Los ataques DDoS (Distributed Denial of Service), son un desarrollo ya no tan reciente, pero si muy efectivo para lograr la denegacion de un servicio, y por eso constituyen una gran amenaza para la seguridad. Voy a intentar dar una vision del problema, funcionamiento, como se lleva a cabo, como defendernos... de los DDoS, a fin de minimizar los daños producidos. El primer encuentro que sabemos con los DDoS (que no quiere decir que fuera la primera vez) fue en la semana del 7 al 11 de febrero del año 2000. Supongo que tod@s os acordais de los ataques a Yahoo, Buy.com, eBay, Amazon, Datek, E*Trade y CNN. Estas empresas se quedaron sin conexion unas horitas. El problema es el de siempre. Ocultismo. Cierto es que ahora comienza a estar mas documentada la cosa, pero es un poco pobre la info. En ningun documento (hasta ahora :P) se daban los suficientes detalles para decir 'ahhhh! claro, ahora lo entiendo'. Asi que si queda alguna duda despues de leer este tuto, me mandais un mail (al final teneis mi clave pubica o publica, com querais ñ_ñ). Entonces tenemos el problema que si no sabemos bien bien que pasa, dudo mucho que sepamos solventarlo y/o prevenirlo. El objetivo de un DDoS puede ser cualquiera, como: -Floodear para que evitar que se conecte a la red. *Mantienes el PC ocupado mientras spoofeas su IP o MAC... *Evitas que se conecte a internet porque estas participando en unas subastas :P *Estas jugando al Counter, subele el ping xD -Floodear para anular un servicio especifico. *No te interesa que una persona, ordenador o servidor mande algun tipo de info (mail, logs...) *Solo quieres putear (¬¬') *Intentas que el NIDS, Firewall o lo que sea, pete y que te deje tranquilo. No hay manera de saber si un ataque de este tipo se trata de el principio de algo mas grande, o si quien lo lanza no quiere nada mas. Es importante tener en la cabeza, que un DoS y un DDoS no son tecnicas de hackeo. En mas de un sitio he leido la tonteria que te pueden hackear con un DoS, no tiene sentido. El proceso esta compuesto de 4 pasos principales: 1) Fase de escaneo con un conjunto objetivo de sistemas muy elevado, 100.000 o mas. Se prueban estos frente a una vulnerabilidad conocida. 2) Se obtiene acceso a parte de esos sistemas a traves de la vulnerabilidad. 3) Se instala la herramienta de DDoS en cada sistema comprometido. 4) Se utilizan estos sistemas para escanear y comprometer nuevos sistemas. Se podrian realizar estos 4 pasos a mano, pero lo mas eficiente, rapido, y anonimo, es un gusanito multiplataforma que haga el trabajo por ti. ------------------------------------ 2. Explicacion detallada de los DDoS ------------------------------------ Un DDoS involucra a muchos ordenadores (mientras mas mejor). Y se puede llevar a cabo de varias formas: 1. Hackeando una red a. Instalando soft especifico para un DDoS b. no instalar nada 2. Sin hackear nada a. Smurf --> TCP b. Fraggle --> UDP Este esquema nos esta diciendo que si hackeamos una red (u ordenador), podemos meter un software especifico para lanzar ataques o hacerlo manualmente (deberiamos acceder a cada ordenador y decirles uno a uno que debe hacer). Lo mejor desde el punto de vista del atacante es usar un software, que consta de master/agente (el clasico cliente/servidor). De esta forma, lanza el ataque masificado controlandolo todo desde un ordenador. Si no fuera porque dentro de un tiempo las empresas de telefonia quitaran las targetas de prepago para ser todo bajo contrato, habria salido la forma de lanzar un DDoS utilizando el movil en un futuro (que es todo lo animo que quieras, o casi). Las consecuencias suelen ser el ahogo del ancho de banda, o del router o de los recursos de la pila de red... siempre se pretende denegar algun recurso. 2.1.Hackeando una red o pc ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Como es logico el primer paso sera hackear ordenadores, con ayuda de exploits, ing social, malas configuraciones y demas tecnicas. Despues se procederia a subir privilegios y a instalar un rootkit a fin de ocultar los procesos pertinentes, puertos, etc y se borrarian o modificarian los logs. Y dependiendo del sistema operativo en el que nos encontramos utilizaremos un programa u otro como agente. Repitiendo varias veces estos pasos, conseguiremos tener la suficiente artilleria como para reproducir esos gigabytes por segundo del ataque a Yahoo, segun datos del SANS (se utilizaron miles de ordenadores). Okis, ahora toca el ataque. El atacante puede hacer varias cosas; entrar PC a PC con el backdoor que tenga puesto y ejecutar el ataque (un bucle ping, el DoS Pepsi-win, cualquier cosa sirve). Despues saldria del ordenador comprometido (mientras se esta lanzando el ataque) e iria haciendo lo mismo en cada ordenador que tenga hackeado. Esto, a parte de ser un trabajo pesado, el ataque se hace mas lento. La otra opcion mas inteligente seria dar los parametros necesarios al master, y todos los ordenadores harian lo que se le ha pedido. Es decir, que con tan solo un par de instrucciones, podemos controlar muuuuuuchas maquinas. Este ataque, se ha de hacer muy bien, ya que si te dejas algun log en alguna maquina, comienza a preocuparte. Tambien has de estar concienciado que todos esos servidores que has hackeado, los vas a perder. Porque cuando denuncien (si lo hacen) investigaran los servidores involucrados, y tal vez esperen a que te vuelvas a conectar a alguno de ellos para snifarte y pillarte. *----------* | | | Atacante | | | *----------* | |<--- Bouncer ;) | *----------* | | | Master | | | *----------* | (comandos a los agentes) | *------------*------*------*------------* | | | | paquetes! | | | | v v v v *----------* *----------* *----------* *----------* | | | | | | | | | agente | | agente | | agente | | agente | | | | | | | | | *----------* *----------* *----------* *----------* \ \ / / \ \ / / \ \ / / \(Cualquier tipo de flood)/ \ \ / / \ \ / / \ \ / / V V V *-----------------------* | | | Victima | | | *-----------------------* Los terminos paquete y datagrama suelen parecer intercambiables, pero no. Conceptualmente, un paquete es la unidad fisica de mas bajo nivel, mientras que datagrama se refiere a la unidad de datos a nivel IP. Sin embargo, en la mayoria de las redes no se puede distinguir porque coinciden, asi que la gente suele usar los dos terminos indistitivamente. 2.2.Sin hackear nada ^^^^^^^^^^^^^^^^^^^^ -*-SmurF-*- Ping --> Internet Control Message Protocol (ICMP). La administracion de redes abarca un amplio numero de temas. En general, se suelen tratar con muchos datos estadisticos e informacion sobre el estado de distintas partes de la red, y se realizan las acciones necesarias para ocuparse de fallos y otros cambios. La tecnica mas primitiva para la monitorizacion de una red es hacer 'pinging' a los host criticos; el 'pinging' se basa en un datagrama de 'echo' (eco), que es un tipo de datagrama que produce una replica inmediata cuando llega al destino. La mayoria de implementaciones TCP/IP incluyen un programa (normalmente llamado 'ping') que envia un echo a un host en concreto. Si recibimos replica, sabremos que host se encuentra activo, y que la red que los conecta funciona; en caso contrario sabremos que hay algun error. Pues bien, sumemos miles y miles de este datagrama. El resultado es predecible. Existen tecnicas basadas en ICMP, pero NO en los paquetes de tipo echo. Podrian considerarse tecnicas tanto de ICMP sweep como de ICMP broadcast, pero con otros tipos de paquetes ICMP, no echo. Estos paquetes se van a a analizar a continuacion: - ICMP Timestamp: Mediante el envio de un paquete ICMP de tipo timestamp, si un sistema esta activo, se recibira un paquete de timestamp indicando que implementa este tipo de transferencia de informacion que permite conocer la referencia de tiempo en el sistema destino. Tal y como denota el RFC 1122, la decision de responder a estos paquetes depende de la implementacion. Algunos sistemas Windows si responden mientras que otros no, sin embargo la mayoria de los Unix si que lo implementan. - ICMP Information: El proposito de los paquetes ICMP de informacion y su respuesta asociada, information reply, es permitir que ciertos equipos que no poseian disco del que extraer su propia configuracion, pudieran autoconfigurarse en el momento de su arranque, principalmente para obtener su direccion IP. En el paquete, tanto la direccion origen como destino tienen el valor cero. Tanto el RFC 1122 como el 1812 indican que los sistemas no deberian generar ni responder a este tipo de paquetes, pero la realidad de las implementaciones existentes es otra. Algunos sistemas operativos responderan cuando la direccion IP destino del paquete tiene el valor de una direccion IP especifica. En la respuesta, en lugar de tener la direccion IP de la red en el campo de direccion origen, se tiene la direccion IP del host. Algunos UNIX comerciales y equipos Cisco implementan la respuesta ante este tipo de paquetes. - ICMP Address Mask: El proposito de los paquetes de tipo address mask y address mask reply, era que los equipos o estaciones de trabajo sin disco pudiesen obtener la mascara de red asociada a la subred en la que estaban conectados en el momento de arrancar. Se supone que un sistema no deberia responder con un paquete de este tipo salvo que fuera un agente autorizado para notificar la mascara, tipicamente el router de la subred. Una red se puede proteger frente a este ataque si los firewalls o screening routers se encargan de verificar y descartar este tipo de errores, no permitiendo este tipo de trafico. Asimismo, si el dispositivo de filtrado no implementa esta caracteristica, es posible filtrar los paquetes ICMP Parameter Problem en su camino de vuelta. Existe una herramienta, ISIC: IP Stack Integrity Check, de Mike Frantzen (http://www.packetfactory.net/Projects/ISIC) disponible para este tipo de pruebas, que permite poner a prueba la pila TCP/IP, encontrar debilidades en un firewall, y comprobar la implementacion de firewalls e IDS. Permite especificar si los paquetes se fragmentan, sus opciones IP, las opciones TCP y el bit URG. Existe un tipo de DDoS denominado SmurF que amplifica considerablemente los efectos de un ataque ICMP. En el SmurF el atacante dirige paquetes ICMP echo request a una direccion IP de broadcast. Existen tres partes en un ataque SmurF: El atacante, el broadcast y la victima. La direccion logica de broadcast, es decir, aquella que representa a todas las maquinas de una red, se utiliza en algunos protocolos para localizar el sistema que proporciona un servicio concreto de forma sencilla, es decir, preguntando a la red, y no consultando uno por uno a todos los sistemas existentes. Si esta direccion se encuentra disponible tambien para usuarios externos a la red, es posible que un atacante pueda enviar un paquete de datos a la misma, provocando que todos los sistemas pertenecientes a dicha red respondan simultaneamente, aumentando la potencia de la respuesta en un factor de N, siendo N el numero de maquinas disponibles en la red. Es decir, se realiza un ataque a una red desde otra red intermedia que permite multiplicar los recursos existentes (elementos validos para desarrollar ataques DDoS). Este metodo no implica tener que controlar las redes empleadas como multiplicadoras del efecto de ataque. Si se auna esta tecnica junto a la de IP spoofing, al enviar un paquete ICMP con la direccion IP origen de la maquina a atacar y direccion IP destino la direccion de broadcast de una red con un elevado numero de maquinas, digamos cientos, todas las respuestas de la red de broadcast se dirigiran realmente a la direccion IP del sistema 'spoofeado'. Aunque no es tan sencillo :P El primer router que recive el paquete puede ver que la direccion IP origen esta spoofeada. Puesto que el router conoce que rango de IPs pueden salir por el. Este es el gran problema. Solo has de mirar si tu ISP permite IP spoofing. Si no te deja, encuentra un servidor desde el que se permita, y lanza el ataque desde ahi. Generalmente, la IP del broadcast tiene unos octetos definiendo la clase de red, y los demas tienen el mismo bit. Por ejemplo para una red 10.0.0.0 es 10.255.255.255. Si tuvieramos una subred de clase A con 256 subredes, el broadcast para 10.50 seria 10.50.255.255. La direccion del estilo 10.50.0.0 puede producir una respuesta broadcast. +--------+ +-----------------+ | | +---------------+===I====> | | | | | |===C=====>| | -a--| ISP +------+ Broadcast +===M=====>| www.victima.com | | | | 20 PCs |===P=====>+-----------------+ | | +---------------+ +--------+ El ordenador 'a' manda un echo haciendose pasar por www.victima.com, y como su ISP permite el spoofeo, el ataque SmurF se realiza con exito. -*-Fraggle-*- Es lo mismo que el SmurF pero utilizando datagramas UDP. --------------- 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 #include #include 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 su deteccion 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. ------------------------- 5.Puntos debiles del SNMP ------------------------- SNMP se utiliza para controlar los dispositivos de la red y administrarlas. Se trata de un grupo de protocolos que envian mensajes llamados Unidades de datos de protocolo (PDU, Protocol Data Units) a traves de la red, hasta diversos dispositivos o maquinas que disponen de un software agente SNMP instalado. Estos agentes mantienen Management Information Bases (MIBs, no son los Men In Black :P) que contienen informacion sobre cada uno de los dispositivos. Cuando los agentes reciben los PDU, responden con la informacion contenida en las MIB. En algunas instalaciones de SNMP se han descubierto puntos debiles que proporcionan a los atacantes una via para desactivar dispositivos de la red. ------------------------------- 6.Ataques de enrutado de origen ------------------------------- TCP/IP admite el enrutado de origen (source routing), que es un medio de permitir que el emisor nos dirija los paquetes a traves de un punto concreto de la red. Hay dos tipos de enrutado de origen: -Enrutado de origen estricto El emisor de los datos puede especificar la ruta exacta (no se suele usar mucho) -Registro de ruta de origen flexible (LSRR, Loose Source Record Route) El emisor puede especificar ciertos routers por los que debe pasar el paquete. El enrutado de origen es una opcion del encabezamiento IP que permite que el emisor anule las decisiones de enrutado que se suelen tomar en el router que encuentra el paquete entre el origen y el destino final. Los administradores de redes lo utilizan para realizar un mapa de la red o para resolver problemas en las comunicaciones o el enrutado. Si el sistema permite el enrutado de origen, este puede ser usado por cualquier intruso para alcanzar direcciones internas privadas de la LAN, que normalmente no estarian a su alcance desde Internet, enruntando el trafico a traves de otra maquina a la que si se puede acceder desde Internet o desde una paquina interna. El enrutado de origen puede desactivarse, en la mayor parte de los routers para evitar este tipo de ataques. Para vulnerar RIP, como se especifica a continuacion, es necesario inicialmente identificar un router que hable este protocolo a traves de la identificacion del puerto UDP 520. En el caso de pertenecer al mismo segmento de red, deben escucharse las actualizaciones RIP que circulan por la red o solicitarselas directamente a alguno de los routers. De esta forma se obtendra la tabla de rutas que se anuncia en ese momento. Si no se esta en el mismo segmento, se dispone de herramientas como rprobe para realizar una peticion RIP remota: el resultado se obtendra mediante un sniffer en el sistema desde el que se ataca. Una vez definida la informacion que se pretende inyectar en la tabla de rutas anunciada, por ejemplo, redireccionar todo el trafico a un sistema desde el que se pueda analizar el mismo, mediante utilidades como srip, se inyectara la ruta deseada. A partir de ese momento todo el flujo de trafico pasara por el nuevo camino definido. Para que el funcionamiento habitual no se vea modificado, es necesario que el nuevo sistema al que van destinado los paquetes los redireccione consecuentemente: ip forwarding. El primer ejemplo de configuracion de este tipo se aplica a la capacidad de los kernels para hacer routing entre varios interfaces. esta se configura como sigue: - En HP-UX basta con introducir en el fichero /etc/rc.config.d/nddconf: TRANSPORT_NAME[1]=ip NDD_NAME[1]=ip_forwarding NDD_VALUE[1]=1 - En Solaris basta con ejecutar mediante ndd en un script de arranque: ndd –set /dev/ip ip_forwarding 0 - En Linux, se debe añadir tambien en un script de arranque: echo 1 > /proc/sys/net/ipv4/ip_forward En el caso de Linux es posible especificar los parametros en el fichero /etc/sysctl.conf (p.ej., Red Hat) que es cargado por la utilidad /sbin/sysctl. La documentacion al respecto se encuentra en el directorio /Documentation del kernel, en el fichero proc.txt. - En Windows las modificaciones se realizan a traves del editor del registro (regedt32.exe); para ello debe localizarse la clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Bajo la misma es necesario añadir el valor: Value Name: IPForwarding Data Type: REG_DWORD Value: 1 -------------------------------------------------------- 6.Jugando con los Firewalls y herramientas automatizadas -------------------------------------------------------- Que pasa si la victima dispone de una politica de seguridad bien definida, y su firewall banea las IPs desde las que atacamos. Pues podemos reirnos de el de varias formas ñ_ñ: -Atacarle haciendonos pasar por la IP del DNS (para que lo banee) -Atacarle haciendonos pasar por su gateway -Atacarle mandando los paquetes hacia el puerto 53 (nos saltaremos el firewall) -Construir paquetes de nivel 7 -Mandar los paquetes a algun puerto abierto publicamente (no protegido) Esto es lo mismo que dice un amigo mio: 'depende de que errores quieras, intalate un Windows u otro'. Todo depende de que resultado te guste mas. *----------* *----------* *----------* *----------* | | | | | | | | | agente | | agente | | agente | | agente | | | | | | | | | *----------* *----------* *----------* *----------* \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / V V V *-----------------------* D <----- | |-----> D E <----- | Firewall |-----> E N <----- | |-----> N Y *-----------------------* Y | ??? | *--------* | | | PC | | | *--------* Tenemos aqui un ordenador que hace la funcion de firewall, conectado al ordenador de trabajo habitual. Como podemos ver, el firewall rechaza los paquetes. Es un firewall propietario muy caro y muy bueno, pero esta tan ocupado rechanzando paquetes de la congestionada red, que el PC no navegara. Otra cosa graciosa es que algunos sistemas desactivan cuentas al cabo de cierto numero de intentos de login incorrectos (lo dejo en el aire, jurjur) ---------- 7.PAQUETES ---------- A estas alturas mas de uno se debe de estar preguntando como es un paquete, que forma tiene, si tiene patas o no... a eso vamos ahora. Hay herramientas que sirven para mirar que paquetes entran y salen de tu ordenador, para Linux el mas tipico es 'tcpdump'. Estos programas se llaman packet sniffers. La cabecera de cada paquete es filosofico, nos dice a donde va, de donde viene, el tipo de paquete... El resto del paquete contiene los datos a transmitir, es el cuerpo del paquete. Asi que como acabamos de decir, todos los paquetes IP comienzan con una cabecera (de al menos 20 bytes de longitud). Diagrama del RFC 790: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Tipo de Servic.| Tamaño Total | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificacion |Flags| Desplaz. del Fragmento | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tiempo de Vida | Protocolo | Checksum de la cabecera | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direccion de Origen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direccion de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version: 4 bits. Este campo describe el formato de la cabecera utilizada. En la tabla se describe la version 4. Tamaño Cabecera (IHL): 4 bits. Longitud de la cabecera, en palabras de 32 bits. Su valor minimo es de 5 para una cabecera correcta, y el maximo de 15. Tipo de Servicio: 8 bits. Indica una serie de parametros sobre la calidad de servicio deseada durante el transito por una red. Algunas redes ofrecen prioridades de servicios, considerando determinado tipo de paquetes 'mas importantes' que otros (en particular, algunas redes pueden admitir solo los paquetes con una prioridad alta en momentos de sobrecarga). Estos 8 bits se agrupan de la siguiente manera: bits 0-2: Prioridad: Valores altos para prioridades superiores. bit 3: 0 = Retraso Normal, 1 = Bajo Retraso. bit 4: 0 = Transito Normal, 1 = Transito Rapido. bit 5: 0 = Fiabilidad Normal, 1 = Alta Fiabilidad. bits 6-7: Reservados para futuros usos. Longitud Total: 16 bits. Es el tamaño total, en octetos, del datagrama, incluyendo el tamaño de la cabecera y el de los datos. El tamaño maximo de los datagramas usados normalmente es de 576 octetos (64 de cabeceras y 512 de datos). Una maquina no deberia enviar datagramas mayores a no ser que tenga la certeza de que van a ser aceptados por la maquina destino. En caso de fragmentacion este campo contendra el tamaño del fragmento, no el del datagrama original. Identificador: 16 bits. Identificador unico del datagrama. Se utilizara, en caso de que el datagrama deba ser fragmentado, para poder distinguir los fragmentos de un datagrama de los de otro. El originador del datagrama debe asegurar un valor unico para la pareja origen-destino y el tipo de protocolo durante el tiempo que el datagrama pueda estar activo en la red. Indicadores: 3 bits. Actualmente utilizado solo para especificar valores relativos a la fragmentacion de paquetes: bit 0: Reservado; debe ser 0 bit 1: 0 = Divisible, 1 = No Divisible bit 2: 0 = ultimo Fragmento, 1 = Fragmento Intermedio (le siguen mas fragmentos) La indicacion de que un paquete es indivisible debe ser tenida en cuenta bajo cualquier circunstancia. Si el paquete necesitara ser fragmentado, no se enviara. Posicion de Fragmento: 13 bits. En paquetes fragmentados indica la posicion, en unidades de 64 bits, que ocupa el paquete actual dentro del datagrama original. El primer paquete de una serie de fragmentos contendra en este campo el valor 0. Tiempo de Vida (TTL): 8 bits. Indica el maximo numero de segundos que un paquete puede estar circulando. Cada vez que algun nodo procesa este paquete disminuye su valor en, como minimo, 1 segundo. Cuando llegue a ser 0, el paquete no sera reenviado. Protocolo: 8 bits. Indica el protocolo de siguiente nivel utilizado en la parte de datos del datagrama. Checksum Cabecera: 16 bits. Checksum de la cabecera. Se recalcula cada vez que algun nodo cambia alguno de sus campos (por ejemplo, el Tiempo de Vida). El metodo de calculo (intencionadamente simple) consiste en sumar el complemento a 1 de cada palabra de 16 bits de la cabecera y hacer el complemento a 1 del valor resultante. Direccion IP de Origen: 32 bits. Direccion IP de Destino: 32 bits Opciones: Variable. Aunque no es obligatoria la utilizacion de este campo, cualquier nodo debe ser capaz de interpretarlo. Puede contener un numero indeterminado de opciones, que tendran dos posibles formatos: Simple: Un solo octeto indicando el 'Tipo de Opcion': El Tipo de Opcion esta dividido en 3 campos: Indicador de Copia: 1 bit. En caso de fragmentacion, la Opcion se copiara o no a cada nuevo fragmento segun el valor de este campo: 0=no se copia 1=se copia Clase de Opcion: 2 bits. Las posibles clases son: 0=control 1=reservada 2=depuracion y mediciones 3=reservada Numero de Opcion: 5 bits. Identificador de la Opcion. Compuesto: Un octeto para 'Tipo de Opcion', otro para 'Tamaño de Opcion', y uno o mas octetos conformando los 'Datos de Opcion'. El Tamaño de Opcion incluye el octeto de Tipo de Opcion, el de Tamaño de Opcion y la suma de los octetos de datos. La siguiente tabla muestra las opciones actualmente definidas: +-----+--------+---------+--------------------------------------------------- Clase |Numero |Tamaño | Descripcion ------+--------+---------+------------------------------------------------ 0 |0 | - |Final de lista de opciones. Formato simple. 0 |1 | - |Ninguna operacion (NOP). Formato simple. 0 |2 |11 |Seguridad. 0 |3 |variable |Enrutado desde el Origen, abierto (Loose Source |Routing). 0 |9 |variable |Enrutado desde el Origen, estricto (Strict Source |Routing). 0 |7 |variable |Registro de Ruta (Record Route). 0 |8 |4 |Identificador de flujo (Stream ID). 2 |4 |variable |Marca de tiempo (Internet Timestamping). ------+--------+---------+-------------------------------------------------- Final de Lista de Opciones: Se usa al final de la lista de opciones, si esta no coincide con el final de la cabecera IP. Ninguna Operacion (NOP): Se puede usar para forzar la alineacion de las opciones en palabras de 32 bits. Seguridad: Especifica niveles de seguridad que van desde 'No Clasificado' hasta 'Maximo Secreto', definidos por la Agencia de Seguridad de la Defensa (de EE.UU.). Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR): Esta opcion provee el mecanismo para que el originador de un datagrama pueda indicar el itinerario que ha de seguir a traves de la red y para registrar el camino seguido. Los Datos de Opcion consisten en un puntero (un octeto) y una lista de direcciones IP (4 octetos cada una) que se han de alcanzar ('procesar'): El puntero indica la posicion de la siguiente direccion de la ruta, dentro de la Opcion; asi, su valor minimo es de 4. Cuando un nodo de Internet procesa la direccion de la lista apuntada por el puntero (es decir, se alcanza esa direccion) incrementa el puntero en 4, y redirige el paquete a la siguiente direcion. Si el puntero llega a ser mayor que el Tamaño de Opcion significa que la informacion de ruta se ha procesado y registrado completamente y se redirigira el paquete a su direccion de destino. Si se alcanza la direccion de destino antes de haber procesado la lista de direcciones completa (el puntero es menor que el Tamaño de Opcion) la siguiente direccion de la lista reemplaza a la direccion de destino del paquete y es a su vez reeemplazada por la direccion del nodo que esta procesando el datagrama ('Ruta Registrada'), incrementando, ademas, el puntero en 4. Utilizando este metodo de sustituir la direccion especificada en origen por la Ruta Registrada se asegura que el tamaño de la Opcion (y de la cabecera IP) no varia durante su recorrido por la red. Se considera que la ruta especificada por el originador es 'abierta' porque cualquier nodo que procesa el paquete es libre de dirigirlo a la siguiente direccion siguiendo cualquier otra ruta intermedia. Solo puede usarse una vez en un datagrama, y, en caso de fragmentacion, la opcion se copiara a los paquetes resultantes. Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR): Exactamente igual que LSSR, excepto en el tratamiento que los nodos haran de este datagrama. Al ser la ruta especificada 'estricta', un nodo debe reenviar el paquete directamente a la siguiente direccion, es decir, no podra redireccionarlo por otra red. Registro de Ruta: Mediante el uso de esta Opcion se puede registrar el itinerario de un datagrama.Los Datos de Opcion consisten en un puntero (un octeto) y un espacio relleno de ceros que contendra la Ruta Registrada para el paquete. Cuando un nodo recibe un paquete en el que esta presente esta opcion, escribira su direccion IP en la posicion indicada por el puntero, siempre que esta sea menor que el Tamaño de Opcion, e incrementara el puntero en 4. Es preciso que el espacio reservado para la Ruta Registrada tenga una longitud multiplo de 4; si al intentar grabar su direccion un nodo detecta que existe espacio libre pero es menor de 4 octetos, el paquete no se reenvia (se pierde) y se notifica el error, mediante ICMP, al originador del datagrama. Esta Opcion no se copia en caso de fragmentacion, y solo puede aparecer una vez en un paquete. Relleno: Variable. Utilizado para asegurar que el tamaño, en bits, de la cabecera es un multiplo de 32. El valor usado es el 0. Ahora, si el campo de protocolo dice que es un paquete TCP, entonces a esta cabecera IP le sigue inmediatamente una cabecera TCP: la cabecera TCP tambien tiene al menos 20 bytes de longitud: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puerto de Origen | Puerto de Destino | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Numero de Secuencia | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Numero de Confirmacion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Deplz. | |U|A|P|R|S|F| | |de los | Reservado |R|C|S|S|Y|I| Ventana | | Datos | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Puntero de Urgencia | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Los campos mas importantes son el puerto de origen y el de destino, que dicen a que servicio esta destinado el paquete (o de cual viene, en el caso de que sea un paquete de respuesta). Los numeros de secuencia y confirmacion (acknowledgement) se utilizan para mantener el orden de los paquetes, y decirle al otro extremos cuantos paquetes se han recibido. Los indicadores (flags) ACK, SYN, RST y FIN (escritos de mayor a menor) son simples bits que se utilizan en la negociacion de apertura (SYN) y cierra (RST o FIN) de las conexiones. Siguiendo a esta cabecera viene el verdadero mensaje que la aplicacion envio (el cuerpo del paquete). Un paquete normal puede tener hasta 1500 bytes: esto significa que el mayor espacio que pueden ocupar los datos es de 1460 bytes (20 bytes para la cabecera IP y 20 para la cabecera TCP): alrededor del 97%. --------- 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 es una 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, creacion que no toda la gente tiene. Esa gente falsa que monta asociaciones para ganar dinero y va jodiendo y engañando a los socios. Que no os enrede nunca mas cierto personaje... Kirby mail to:smurfito@hush.ai * EOF *