Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 7 de Julio de 1.998 - Martes
Se llama "nuke" la caída de una conexión TCP/IP por parte de un agente externo, normalmente un usuario con ganas de fastidiar. En realidad "nuke" es un concepto demasiado genérico. A continuación se describirán las técnicas que conozco. Si dispones de información adicional, nuevas técnicas o quieres matizar algo, escríbeme. Puedes consultar también un documento alternativo, escrito por otra persona, llamado Tácticas de Guerra en el IRC.
Si tienes Windows 95/NT, tienes una página en castellano con los parches: Anti Winnuke Software en español. Tienes lo mismo, pero en inglés, en Nuke Patches for Win95/NT. La descripción técnica de algunos de los ataques se puede ver en Denial of Service or "Nuke" Attacks, que es una página oficial de la red IRCNet.
Aunque teniendo parcheado el servidor se paran el 95% de los ataques, algunos usuarios pueden encontrar interesantes algunos cortafuegos "personales" y sistemas de aviso.
Es decir, el agente "enemigo" envía paquetes al cliente diciéndole que el servidor tiene alguno de los problemas anteriores, o viceversa. En realidad las cosas son un poco más complicadas, ya que el atacante debe acertar con los puertos que se están utilizando en esa conexión en particular. Generalmente ello es bastante sencillo, ya que el servidor acostumbra a emplear el puerto 6667, el estándar IRC, y la víctima un puerto bajo, a partir del 1024 si usa Windows.
Si se ataca el servidor, el cliente no verá nada. Simplemente se desconecta con toda limpieza, ya que el servidor habrá cerrado la conexión TCP y en cuanto reciba un nuevo datagrama del cliente lo rechazará con un RST. El cliente verá "conection reset by peer" y el resto de los usuarios verán alguno de los errores indicados arriba.
Un sniffer en la red del servidor detectará una prolongada ráfaga de paquetes ICMP indicando errores entre un cliente y el servidor de IRC. Cada uno de los paquetes contiene puertos distintos, ya que se está realizando un barrido. Es posible reconocer tales ráfagas y adoptar contramedidas, tales como tomar nota de la IP y la hora para ponerse en contacto con el proveedor del cual dependa el agresor.
Si se ataca el cliente, el servidor no ve nada. Simplemente recibirá un "conection reset by peer" en cuanto envíe un datagrama, ya que el cliente habrá cerrado su conexión. El cliente puede detectar el ataque observando una inusitada actividad en su módem o bien instalando software de traceo tal como el incluído en el paquete Winsock de Trumpet.
La protección más obvia consiste en utilizar puertos poco previsibles. Es decir, emplear un puerto diferente del 6667 en la conexión al servidor y un puerto aleatorio en nuestra máquina local (esto último suele estar fuera del alcance de la mayoría de los usuarios). Un paquete ICMP es ignorado si no contiene los puertos correctos.
Un cliente no puede protegerse salvo que instale un cortafuegos o una versión modificada de su pila TCP/IP. Un servidor puede protegerse con un cortafuegos que filtre las tramas ICMP. Dado que dichos paquetes son útiles en el diagnóstico de problemas en la red y resulta contraproducente filtrarlos todos y para todas las máquinas, se puede optar por filtrar sólo los ICMP (y sólo los ICMP problemáticos) dirigidos al servidor IRC.
Para que el ataque sea efectivo el agresor debe disponer de un ancho de banda superior al de la víctima. De esta forma monopolizará su módem y no podrá responder a tiempo a los datagramas del servidor IRC. Para que el ataque sea efectivo hay que mantenerlo, naturalmente, durante el tiempo suficiente como para que venzan las temporizaciones.
En algunos casos se ha indicado que este tipo de ataque incluso consigue colgar el teléfono de la víctima. No he podido comprobarlo personalmente pero es posible que tenga algo que ver con timeouts en el protocolo PPP.
El usuario atacado observa una actividad inusual en su módem y nota que el servidor IRC tarda en responder o no responde en absoluto a sus comandos. Un software de traceo diagnostica el problema.
Este tipo de ataque no se puede prevenir, ya que aunque el cliente descarte los paquetes de ataque que le llegan, estos ocupan su ancho de banda de recepción. Es necesario que en la ruta de los paquetes exista router con capacidad de controlar la congestión de forma inteligente. Algo no demasiado difícil de programar pero, desde luego, poco difundido.
Existe una variedad de este ataque que resulta realmente impresionante, llamada "SMURFING". Consiste en enviar un ICMP echo request a la dirección de broadcast de toda una subred, poniendo de remitente el sistema que queremos atacar. Las consecuencias son desastrosas. Más información, en inglés, sobre el ataque y como protegerse.
En Windows95 aparece una pantalla azul informando de un error en uno de los módulos del sistema. El ordenador parece seguir funcionando sin problemas, pero todas las conexiones TCP/IP se bloquean.
En Windows NT aparece un pantalla azul y el sistema operativo procede al volcado de memoria. Una vez hecho eso (algo que puede llevar varios minutos, durante los cuales el ordenador no hace nada más), la máquina se reinicia automáticamente.
En Windows95 es posible detectar el atacante realizando un netstat, ya que ese comando nos lista las conexiones activas. Bajo NT no queda ningún LOG.
Hace varios meses publiqué alguna información sobre estos temas, un poco anticuada ya, pero que puede resultar útil para la gente con Windows 95.
En cualquier caso en NT el problema se soluciona instalando el Service Pack 3. De todas formas existe una variante de este nuke, afortunadamente poco difundida, que sigue provocando un dump del sistema y el reinicio posterior de la máquina.
Parece ser (no lo he probado) que en Windows 3.1x se puede corregir el problema de forma similar a Win95 (renombrando el DLL).
Otra posibilidad, que no he comprobado personalmente, es emplear otra implementación TCP/IP diferente de la de Microsoft (por ejemplo, Trumpet??). Una empresa puede protegerse filtrando el puerto 139 en su cortafuegos.
Recientemente, Microsoft ha publicado los parches oficiales. No parecen proteger el ordenador contra las variantes OOB.
Recientemente (Mayo 98) Microsoft ha sacado una actualización WinSock para Windows 95: WinSock 2.2. Si tienes la versión 2.0, actualízate, ya que tiene importantes bugs.
También encontrarás información sobre el tema en uno de mis artículos: Compartición de Discos mediante NetBIOS.
El ordenador se queda bloqueado. No funciona ni el puntero del ratón ni control+alt+sup.
Microsoft ha publicado una serie de parches para Windows 95 y Windows NT. Curiosamente no se responsabilizan de ellos y recomiendan que no se utilicen a menos que sea estrictamente necesario...
Recientemente (Mayo 98) Microsoft ha sacado una actualización WinSock para Windows 95: WinSock 2.2. Si tienes la versión 2.0, actualízate, ya que tiene importantes bugs.
El problema surge cuando los fragmentos que llegan tienen una estructura ilegal (algo que puede ocurrir cuando los fragmentos se construyen a propósito para hacer daño). En estos casos el resultado supone, normalmente, el cuelgue de la máquina.
La máquina se queda colgada instantaneamente, o se reinicia.
Si tienes LINUX, actualiza a 2.0.32 o bien a 2.1.63 o superiores.
Si tienes Windows NT, actualiza a SP3 e instala el hotfix "simply-TCP".
Sigue este enlace si tienes Windows 95. Para que este parche funcione correctamente debes tener instalada la versión 2 de las librerías Winsock. De todas formas parece que a algunas personas les funciona el parche, y a otras no. Cuestión de instalar y probar :-). Microsoft recomienda también instalar el parche para OOB descrito más arriba en este mismo documento.
Recientemente (Mayo 98) Microsoft ha sacado una actualización WinSock para Windows 95: WinSock 2.2. Si tienes la versión 2.0, actualízate, ya que tiene importantes bugs.
Si tienes un sistema raro... reza... Solaris, BSD, etc., no son vulnerables.
Algunas máquinas se ponen a 100% de CPU, ya sea por tiempo indefinido o durante unos minutos. Otros sistemas operativos simplemente se caen. En algunas versiones de TCP Transport de Apple Macintosh, sólo se muere esa aplicación, perdiendo la conectividad IP.
Si se ataca un router vulnerable, éste se cuelga. Ello deja sin conectividad internet a toda la red local. En caso de routers en el backbone las consecuencias pueden ser dramáticas.
Dado que el problema es debido a la recepción de un paquete externo con la misma IP que la máquina atacada, la solución más simple consiste en utilizar reglas anti IP Spoof (por ejemplo, ver las medidas anti "smurf" listadas en una sección anterior):
El poner filtros de entrada en routers con carga elevada puede desencadenar un problema grave de rendimiento. En ese caso es imprescindible actualizar el sistema. CISCO ya ha publicado los parches para sus sistemas.
Puedes encontrar más información sobre el problema en:
Cisco Field Notice: TCP Loopback Denial-of-Service Attack and Cisco
Devices
Network Ingress Filtering: Defeating Denial of Service Address Spoofing
Las máquinas clientes pueden protegerse si no dejan abierto ningún puerto TCP. Ello incluye cerrar NetBIOS sobre TCP, por ejemplo, algo recomendable de todas formas según se describe en mi artículo Compartición de Discos mediante NetBIOS. En el caso de clientes IRC es necesario desconectar el servidor IDENT (puerto 113). Bajo windows pueden comprobarse los puertos abiertos ejecutando "netstat -a".
Windows95 se muere y NT también cae salvo que se haya instalado el hotfix ICMP-FIX posterior al SP3. Según la configuración local, Windows NT se cuelga o la carga de CPU pasa a 100% durante unos minutos.
Windows NT Slows Down Due to Land Attack. Incluye parche.
Windows 95 Stops Responding Because of Land Attack. Incluye parche para WinSock < 2.0. Si tienes 2.0, todavía tendrás que cruzar los dedos unos días más (9/Dic/97).
Recientemente (Mayo 98) Microsoft ha sacado una actualización WinSock para Windows 95: WinSock 2.2. Si tienes la versión 2.0, actualízate, ya que tiene importantes bugs.
La mayoría de los Sistemas Operativos parcheados contra el TearDrop original son insensibles a estos nuevos ataques. Windows es, nuevamente, la excepción.
La máquina se bloquea.
Si tienes NT, lee un artículo de Microsoft al respecto: STOP 0x0000000A or 0x00000019 Due to Modified Teardrop Attack. Incluye Parches.
Si tienes Windows 95, de momento (30/Ene/98) tendrás que esperar.
Recientemente (Mayo 98) Microsoft ha sacado una actualización WinSock para Windows 95: WinSock 2.2. Si tienes la versión 2.0, actualízate, ya que tiene importantes bugs.
Dado que tanto estos ataques como el TearDrop original se basan en el envío de datagramas fragmentados, se pueden evitar los ataques utilizando un router intermedio (o una máquina Linux, BSD, etc) con la opción de reensamblaje de paquetes activa. De esta forma en ensamblado de los paquetes externos los hará esa máquina/router (suponiendo que esté bien parcheada), y no los sistemas internos, vulnerables.
Otra posibilidad, que parece refrendada por la experiencia, es simplemente no tener ningún puerto abierto en la máquina. Una máquina sin puertos abiertos no es vulnerable. En Windows 95, sin nada raro instalado, los únicos puertos abiertos suelen ser los NetBios y el IDENTd si usamos el IRC. Los puertos NetBios pueden eliminarse usando la información listada en la sección "Winnuke OOB". El puerto IDENT se puede quitar simplemente deshabilitando el servicio IDENT en nuestro cliente IRC.
La máquina se bloquea.
Si tienes Linux, actualiza tu kernel a una versión superior a la 2.0.33, o usa la 2.0.33 con el parche apropiado. Los puedes encontrar en ftp://ftp.uk.linux.org/pub/linux/alan/2.0.34pre/.
La máquinas Windows no parecen ser vulnerables si están parcheadas contra los ataques anteriores.
¿Cómo conseguir que alguien se desconecte a sí mismo por flood?. La respuesta es simple: Obligándole a que envíe a la red más datos de las que ésta está dispuesta a aceptar. Para ello existen varias técnicas, todas ellas muy simples. La más obvia, por ejemplo, es enviarle IRC PINGs. Dado que cada ping respuesta implica un ping pregunta, y nosotros no queremos caernos, lo más sencillo consiste en lanzar un clono en la red de forma que las dos (o más) conexiones envíen peticiones PING en el límite de la "paciencia" del servidor. La víctima se cae porque responde a las peticiones de todos los atacantes, superando con mucho el límite permitido por la red.
Observamos varias peticiones de información a nuestro cliente IRC y un momento después nos caemos por "Excess flood".
Dado que este tipo de ataque es muy viejo (y efectivo), muchos scripts incorporan protecciones anti flood que evitan responder cuando se detecta un número de peticiones de información por encima de un valor dado. De hecho muchos clientes IRC incluyen esos controles como una funcionalidad extra.
Ejemplo típico "Pulsa ALT+F4 para conseguir op".
Parece mentira lo bien que funciona };-)
Hacemos algo que nos dice algún tertuliano y nos caemos del servidor, se nos cierra el programa, dejamos nuestro disco duro abierto para todo el mundo, etc.
Simple: No hacer nada cuyas implicaciones no conozcamos enteramente. AUNQUE nos lo pida alguien de confianza. Esos son los peores };-).
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
