En los últimos días, los medios de comunicación se han hecho eco de ataques masivos a lugares tan emblemáticos en el universo Internet como Yahoo!, Amazon, CNN, eBay, Buy, ZDNet, etc. Se habla de ataques de «hackers», de peligro para la seguridad de Internet, de estado de guerra… ¿Qué hay realmente detrás de las noticias sensacionalistas?. +Está justificado el alarmismo?.
En realidad, el tipo de ataques del que hablamos, denominado de «denegación de servicio» («DoS» en sus siglas inglesas), no supone un compromiso para la seguridad de las máquinas. No modifica páginas web ni obtiene listados de claves o de números de tarjetas de crédito. Se trata, sencillamente, de entorpecer el acceso de los usuarios a los servicios de la máquina, pero sin comprometer estos directamente.
En ese sentido, estos ataques acostumbran a ser poco sofisticados y se basan en fallos de diseño inherentes a Internet o a la aplicación. En cuanto el ataque finaliza, todos los servicios vuelven a estar disponibles de nuevo, como si nada hubiera pasado.
Aunque los ataques de denegaci¢n de servicio son una constante en Internet desde sus comienzos (sin ir m s lejos, el c’lebre gusano de Morris desencaden¢ un ataque DoS por un error de programaci¢n), generalmente se han desarrollado a peque_a escala. No obstante, en la segunda mitad de 1.999 se tuvo constancia de la existencia de varias herramientas para realizar ataques de denegaci¢n de servicio de forma coordinada, a gran escala.
+Implica esto que estamos ante una conspiraci¢n mundial de «hackers»?. En absoluto. Dejando al margen el hecho de que un «hacker» que se precie de serlo nunca respaldar¡a estas pr cticas, las herramientas comentadas en el p rrafo anterior posibilitan que una sola persona controle un ataque DoS desarrollado desde centenares de m quinas repartidas por todo el mundo.
¨C¢mo es esto posible?
Como bien saben los seguidores de «una-al-d¡a», se descubren fallos de seguridad todos los d¡as, en aplicaciones y en sistemas operativos. Algunos de esos fallos permiten que atacantes remotos ejecuten c¢digo arbitrario en las m quinas vulnerables, con privilegios elevados. En un contexto as¡, desplegar un ataque DoS es trivial.
Todo lo que tiene que realizar el atacante es localizar m quinas vulnerables e instalar un «demonio» en cada una de ellas. Ese programa «demonio» aceptar comandos provenientes del atacante como, por ejemplo, realizar un ataque DoS contra una m quina determinada.
Por lo tanto, cuando los medios hablan de ataques desde «50 sitios», no significa necesariamente que 50 personas u organizaciones se hayan puesto de acuerdo. Es perfectamente posible que esos 50 lugares est’n bajo el control de una onica persona.
Dicha persona ni siquiera necesita ser un usuario experto, un «hacker». Este tipo de herramientas pr cticamente funcionan solas. En muchos casos, sencillamente hay que especificar un objetivo, y ellas se encargar n de analizarlo buscando una serie de vulnerabilidades. Si el ataque de «infecci¢n» tiene ‘xito, la herramienta se copia y se instala de forma autom tica. Incluso puede tener la capacidad de sondear Internet de forma autom tica.
Una vez que se controla una m quina, ‘sta informa al atacante de su disponibilidad para aceptar sus ¢rdenes. Aunque el ataque «de infecci¢n» s¢lo tuviera ‘xito en el 0.01% de los casos, con decenas de m quinas conectadas a Internet, las posibilidades de reunir recursos dispersos bajo el control de una onica persona son inmensas.
¨C¢mo funciona un ataque de denegaci¢n de servicio?
Ataque DoS es un concepto gen’rico. Hay multitud de ataques de denegaci¢n de servicio, y se descubrir n m s. Algunos de los m s habituales son:
* Net Flood:
Este ataque simplemente aspira a degradar la conectividad Internet de una red mediante la saturaci¢n de sus enlaces de comunicaci¢n.
Si, por ejemplo, la organizaci¢n atacada tiene un enlace Internet de 2Mbps (Megabits por segundo) y el atacante suma 34Mbps, est claro que la l¡nea de menor capacidad pr cticamente estar monopolizada por «tramas» atacantes, dejando muy poco sitio para que se curse tr fico otil.
¨C¢mo consigue el atacante contar con grandes anchos de banda?
Una posibilidad es coordinar ataques simultaneos desde varias localizaciones, utilizando las herramientas descritas m s arriba. Por otra parte, existen multitud de redes de gran capacidad con m quinas mal administradas y completamente inseguras, como la mayor¡a de las universidades.
Al igual que ocurre con los ataques DoS, «net flood» es tambi’n un concepto gen’rico, que engloba diversos tipos de ataques. Uno de los m s interesantes es el «smurf».
El ataque «smurf» utiliza una caracter¡stica de Internet: broadcast. Toda red tiene lo que se denomina una direcci¢n de «broadcast». Los datagramas enviados a esa direcci¢n son recibidos por todas las m quinas en la red local. Ello permite, por ejemplo, que una m quina localice un servidor proporcionando un servicio haciendo una pregunta a la red, no preguntando m quina por m quina.
El problema de la direcci¢n «broadcast» es que suele estar disponible tambi’n para usuarios de fuera de la red local, en particular para todo Internet. Ello permite, por ejemplo, que un atacante env¡e un peque_o datagrama a toda una red remota, y que las m quinas de dicha red respondan todas a la vez, posiblemente con un datagrama de mayor tama_o. Si la red sondeada tiene 150 m quinas activas, la respuesta es 150 veces m s intensa. Es decir, se consigue un efecto «multiplicador».
¨Qu’ ocurre ahora si el atacante utiliza la direcci¢n IP de otro sistema? (lo que se denomina «IP Spoofing»). ¥¥Que las respuestas de la red a la que se hace «broadcast» ser n enviadas a la direcci¢n IP del tercer sistema!!. Es decir, el atacante est atacando una red empleando otra red intermedia para multiplicar sus recursos.
Si, por ejemplo, el atacante dispone de una RDSI, y utiliza como multiplicadores cinco redes con 10 m quinas en cada una de ellas, por poner un ejemplo, la red final recibir datagramas a una tasa de 3.2Mbps, al menos. El atacante ha multiplicado sus recursos por 50, como m¡nimo.
Lo peor de todo es que este ataque ni siquiera implica controlar las redes que se emplean como multiplicadoras.
* Syn Flood:
El protocolo TCP de Internet, sobre el que se basa la mayor¡a de los servicios (incluyendo el correo electr¢nico, el web y el IRC) implica una conexi¢n entre dos m quinas. El establecimiento de dicha conexi¢n se realiza mediante lo que se llama «conexi¢n en tres pasos», precisamente porque requiere la realizaci¢n de tres pasos iniciales antes de que la conexi¢n se pueda considerar establecida. Si el paso final no llega a establecerse, la conexi¢n permanece en un estado denominado «semiabierto».
El problema es que muchos sistemas operativos tienen un l¡mite muy bajo en el nomero de conexiones «semiabiertas» que pueden manejar en un momento determinado. Si se supera ese l¡mite, el servidor sencillamente dejar de responder a las nuevas peticiones de conexi¢n 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 conexi¢n reci’n liberada sea capturada por un nuevo «syn» malicioso es muy alta.
Para hacernos una idea de la potencia de este ataque baste decir que muchos sistemas operativos fijan un l¡mite del orden de 5-30 conexiones «semiabiertas», y que ‘stas caducan al cabo de un par de minutos. Para mantener el servidor fuera de servicio, un atacante s¢lo necesita enviar un paquete «syn» cada 4 segundos. Algo al alcance de, incluso, un m¢dem de 300 baudios.
Este ataque suele combiarse tambi’n con «ip spoofing» (enviar los paquetes con la direcci¢n de una tercera red) de forma que la red atacada «ve» un ataque proveniente de esa tercera red, no proveniente del atacante real.
En la actualidad, la mayor¡a de los sistemas operativos son inmunes a este ataque, siempre y cuando el administrador de las m quinas se haya preocupado de instalar la oltima versi¢n del sistema o haya aplicado a las versiones antiguas el parche correspondiente.
* Connection Flood:
Todo servicio de Internet orientado a conexi¢n (la mayor¡a) tiene un l¡mite m ximo en el nomero de conexiones simultaneas que puede tolerar. Una vez que se alcanza ese l¡mite, no se admitir n conexiones nuevas.
As¡, por ejemplo, un servidor Web puede tener capacidad para atender a mil usuarios simultaneos. Si un atacante establece mil conexiones y no realiza ninguna petici¢n sobre ellas, monopolizar la capacidad del servidor. Las conexiones van caducando por inactividad poco a poco, pero el atacante s¢lo necesita intentar conexiones nuevas constantemente, como ocurre con el caso del «syn flood».
Afortunadamente este ataque implica que la conexi¢n tiene lugar o, lo que es lo mismo, que se completa la negociaci¢n en tres pasos que coment bamos en la secci¢n anterior. Debido a ello la m quina atacada tiene constancia de la identidad real del atacante. Al menos, si sus administradores merecen su sueldo y saben qu’ comandos utilizar…
¨C¢mo defenderse de este tipo de ataques?
La respuesta sencilla es «no puedes». Muchos de estos ataques de denegaci¢n de servicio se basan en fallos de dise_o inherentes a Internet, por lo que no son «solucionables» en un plazo breve de tiempo.
Los ataques de «syn flood» ya no son un problema, si se instala un sistema operativo actualizado.
Los ataques de «connection flood» pueden ser detectados por un administrador de sistemas eficiente, y se pueden filtrar en el cortafuegos corporativo, siempre que los sitios atacantes sean pocos.
Por oltimo, tenemos el caballo de batalla real: «net flood».
En estos casos, la red v¡ctima no puede hacer nada. Aunque filtre el tr fico en sus sistemas, sus l¡neas estar n saturadas con tr fico malicioso, incapacit ndolas para cursar tr fico otil. Un ejemplo habitual es el de un tel’fono: si alguien nos quiere incordiar, s¢lo tiene que llamarnos por tel’fono, de forma continua. Y si descolgamos el tel’fono para que deje de molestar, nos encontramos con que tampoco podemos recibir llamadas de otras personas. Este problema es habitual, por ejemplo, cuando alguien intenta mandarnos un fax empleando nuestro nomero de voz, y el fax insiste durante horas y horas… sin que el usuario llamado pueda hacer nada al respecto.
En el caso de «net flooding» ocurre algo similar. Aunque filtremos el ataque en nuestro cortafuegos, nos encontramos con que nuestras l¡neas estar n tan saturadas de tr fico que las conexiones aut’nticas simplemente no pueden competir. En casos as¡ el primer paso a realizar es el ponerse en contacto con nuestro «carrier» (el operador de «backbone») para que intente determinar la fuente del ataque y, como medida provisional, filtre el ataque en su extremo de la l¡nea (normalmente de bastante mayor capacidad que nuestro extremo).
El siguiente paso consiste en localizar las fuentes del ataque e informar a sus administradores, ya que seguramente se estar n usando sus recursos sin su conocimiento y consentimiento. Si el atacante emplea «ip spoofing», esto puede ser casi imposible.
En muchos casos, la fuente del ataque es, a su vez, v¡ctima. El origen oltimo puede ser pr cticamente imposible de determinar.
Este paso puede ser bastante lento y requerir la ayuda del personal t’cnico del «carrier» o «backbone». Si el ataque dura poco tiempo, un par de horas, puede resultar imposible movilizar los recursos necesarios para localizar su fuente.
+No hay esperanza entonces?
S¡, pero se trata de medidas preventivas. Medidas que toda red y operador serio debe desplegar cuanto antes:
– Mantener las m quinas actualizadas y seguras:
Ello implica tener personal especializado en cuestiones de seguridad (o subcontratarlo).
Aunque una m quina no contenga informaci¢n valiosa, hay que tener en cuenta que puede resultar otil para un atacante, a la hora de ser empleada en un DoS coordinado o para ocultar su verdadera direcci¢n.
– No permitir el tr fico «broadcast» desde fuera de nuestra red:
De esta forma evitamos ser empleados como «multiplicadores» durante un ataque «smurf».
– Filtrar el tr fico «ip spoof»:
Esto es algo que todo «carrier» o «backbone» deber¡a hacer, y que permitir¡a localizar y solucionar el problema con una gran rapidez. En pocas palabras, estos filtros evitan que un atacante se pueda hacer pasar por otro usuario.
– No tener proxies abiertos a todo Internet:
Algunos administradores tienen sus proxies, wingates, open sesame, SOCKS, SQUIDs, etc. abiertos a todo el mundo, sin ser conscientes de ello. Esto permite que cualquier usuario de Internet pueda atacar cualquier sistema responsabilizando a esa red intermedia mal administrada.
– Auditorias de seguridad y sistemas de detecci¢n:
Las herramientas DoS que posibilitan ataques coordinados tienen una serie de huellas en la red local cuando, por ejemplo, se comunican con su «due_o». Existen herramientas de seguridad que permiten reconocer estas huellas, con lo que el administrador sabr que ha sido contaminado antes de que su sistema haya sido empleado en un ataque masivo.
Como colof¢n:
* Los ataques DoS pueden prevenirse, pero requieren de la cooperaci¢n de todo Internet (por ejemplo, para evitar «IP Spoofing»). La seguridad de la red depende de la seguridad de cada uno de sus componentes.
* En la mayor parte de los casos, un ataque DoS distribuido implica una red de m quinas cuya seguridad se ha vulnerado, no la existencia de una conspiraci¢n mundial.
* Un ataque DoS no ocasiona un «colapso del sistema inform tico» o «importantes da_os inform ticos», como ha salido publicado en diferentes medios. Si los sistemas est n bien administrados, todo vuelve a la normalidad una vez finalizado el ataque.
* Estamos ante un nuevo paradigma de ataque, en el que se ha sustituido el ataque sistem tico y elaborado a un sistema en concreto, por ataques mucho m s sencillos pero masivos. Con el nomero de m quinas que hay conectadas a Internet que existen en la actualidad, una vulnerabilidad explotable en el 0.01% de los casos supone millones de m quinas a merced de cualquiera.
* Un ataque DoS no es obra de «hackers».
Como nota curiosa, el 7 de Febrero se organizaba un encuentro «birds of a feather» (+alguien me ofrece una traducci¢n aceptable al castellano?) para discutir los peligros de las nuevas herramientas de ataque DoS distribu¡do. Una cronolog¡a, cuando menos, sospechosa.
Jesos Cea Avi¢n
jcea@hispasec.com
