El escenario Actual: todo es cuestión de dinero.
Las compañías actuales, ven en Internet un sistema ideal. Por un lado les ahorra costes estructurales, ya que evita que una compañía contrate líneas Frame Relay o punto a punto con sus sucursales. Pero esto no es más que la punta del iceberg. El correo les evita costosas comunicaciones, la web les evita la impresión de costosos catálogos de productos a la par que les abre nuevas vías de comunicación y servicio con los clientes (banca electrónica, etc).
Pero la cosa no acaba ahí, si pensamos en la telefonía IP, el correo en el móvil (blackberry y similares) y un largo etcétera.
Pero esto tampoco acaba aquí, Internet permite trabajar más rápido y dar mejor servicio a los clientes (menos gente atiende a más clientes), ahorro de costos en contratación/compra de oficinas, mejor sistema de comunicación, expansión internacional casi gratuita, y asi podríamos seguir muchísimo tiempo más.
Ignorar el problema no lo arregla.
Las mafias se están dando cuenta del mismo “negocio”... y piensan…..si antes extorsionábamos a los del barrio/ciudad/país y necesitábamos X matones, ahora con 1 nos vale para extorsionar a todo el mundo.
Esto genera la aparición de pequeñas mafias que ya han empezado a hacer sus estragos. Mafias uni o bipersonales extorsionan a grandes entidades financieras o son fácilmente “contratables” para extorsionar a otras compañias.
¿Quiénes son los objetivos inminentes? Es evidente... ¿dónde esta la pasta? En los bancos.
Los bancos lo saben pero no lo arreglan, no por que no sepan, sino porque, como es tradicional, lo arreglarán cuando sea demasiado tarde (¿para qué vas a invertir unas horas en arreglar o paliar un problema futuro si todavía no lo tienes?).
Los DoS que vienen son potentes, son fulminantes y tienen mala solución (al menos de momento). Vamos a ver algunos de los que vienen y su manera de solucionarlos.
El viejo DoS
El viejo DoS no es muy efectivo hoy en día, ya que la mayor parte de la electrónica de red incorpora controles anti DoS. Evidentemente algunos siguen y seguirán funcionando.
Vamos a ver con un ligero detalle técnico los antiguos DoS (los más conocidos) y los nuevos DoS que van a venir.
Syn Flood.
Cuando se establece una conexión TCP , en realidad se establece una conexión a tres vías. El computador origen envía un paquete TCP con el byte SYN activado, el computador destino le devuelve un SYN+ACK y la conexión se completa con un ACK.
Después del último paquete, la conexión TCP se ha establecido. Ahora bien, si tú le envías al computador destino sólo un SYN, el te devuelve un SYN+ACK, pero si no le contestas con un ACK, el computador se quedará esperando un tiempo (por defecto antes era bastante largo) hasta que le llegue.
Bastaba con hacerse un programa muy simple que enviase millones de TCP (estamos hablando de bytes, por lo que imaginaros la cantidad de paquetes que se pueden enviar por segundo) con el bit de SYN activado, falsificando la dirección IP origen y eligiendo una origen que, o bien no exista, o que esté sin responder (si no, el computador falsificado, cuando recibiese un paquete SYN+ACK que no había emitido él, mandaría un RST y la conexión se descartaría).
Este sistema terminaba llenando la tabla de conexiones, y el proceso que tenía el socket en escucha cascaba rápidamente.
El mercado reaccionó rápido, se aumentaron el número de conexiones que las tablas podían almacenar, se redujeron los tiempos de espera para los paquetes ACK y la electrónica de red metió patrones de detección de DoS en curso basándose en los ISN (Internet Sequence Number) de los ataques (claro que esto último se ha basado en el secretismo para que les funcione, eso se les ha ido al garete).
Hoy en día, todas las redes (o casi todas) son responsables de meter controles antispoofing. Es decir, si tú estás en una red de tu ISP, pongamos por ejemplo a Telefónica, los paquetes que salgan de la misma no podrá ser de una dirección IP origen que no sea asignada a ellos. Incluso con los ADSL este control es dinámico por IP.
Las variantes son casi infinitas, pero creo que he descrito el concepto.
Smurfing
¿Quién no ha hecho un ping a un computador para ver si esta vivo? ¿Y qué pasa si hacemos un ping a una dirección de broadcast? Que nos contestan todos los equipos que pertenecen a dicha red. Es decir, tenemos un efecto multiplicador. De esta forma, mandando unos bytes, obtenemos varios Kb de tráfico. Si hacemos spoofing de la dirección IP que deseamos “tumbar” y mandamos millones de paquetes ICMP a millones de direcciones de broadcasting, el resultado es evidente.
Como dije antes, los controles antispoofing y otros específicos del smurf, han restado eficacia a este DoS.
Chargen-Echo
Existen varios servicios por defecto en todos los sistemas operativos. Uno es el servicio de ECHO (no, este no usa el ICMP echo), estamos hablando del UDP al puerto 7. Este servicio devuelve todo lo que se le envia.
El DoS es evidente, haciendo spoofing del computador al que queremos tumbar, le mandamos un paquete UDP con puerto origen 7 y destino el 7 al otro ordenador. La comunicación entra en un loop infinito y las máquinas se caen.
Los controles antispoofing y varias modificaciones en todas las pilas del TCP de todos los sistemas operativos mundiales, acabaron con este DoS.
El chargen (puerto 19) es similar. Cuando uno se conecta al mismo, devuelve un chorro de caracteres para hacer tests de conectividad.
Etc.
En fin, la lista es interminable, pero creo que para muestra ya hemos tenido un botón. Ahora lo importante.
Viejos DoS, nuevas estructuras
Agotamiento de recursos
Tradicionalmente, no sé muy bien por qué, los administradores prefieren poner todos los recursos de la máquina a disposición de los servicios para los cuales están puestas. Es decir, si es un servicio WEB y el mismo ejecuta con el usuario “webuser”, no tiene limites de consumo de recursos.
Por otro lado, cuando nosotros abrimos una conexión, por ejemplo web, en realidad destinamos muy poca memoria a abrirla y mantenerla abierta. Si hacemos un programita que abra 5 sockets contra un web y vemos qué memoria consume, veremos que es menos de 1 Kb por socket.
Sin embargo, cada proceso que el servidor web hace fork (o thread), ocupa varios Kb (lógico, ha de mantener una copia del software que va a atender la petición en memoria). Tenemos nuevamente un proceso multiplicador. Por cada Kb que yo gasto, el servidor gasta X. Imaginemos que puedo abrir (que no hay problema) 4000 sockets simultáneos contra el servidor web…..
El DoS está servido. Es muy fácil, lo único un pelin más complicado es la logística. Se trata de abrir tantas conexiones como sea posible, desde diferentes ubicaciones (si no, el administrador bloqueará la IP), y mantenerlas abiertas tanto tiempo como sea posible.
El efecto es devastador en las infraestructuras actuales. Las máquinas, que no tienen control de recursos por usuarios (o lo que es lo mismo, por servicios), no pueden aguantar la carga y devoran recursos hasta que la máquina queda inutilizada. Habitualmente requieren intervención manual.
He citado el servicio Web, pero este DoS funciona contra servicios de email, ftp, web y todos los que estén basados en conexiones TCP.
En otro artículo más técnico entraré en detalles de cómo hacerlo desde diferentes ubicaciones sin que sea rastreable y pondré código fuente ejemplo para que se vea el concepto (que los “malos” ya están utilizando)
¿La solución? Mala, la única aproximación viable es limitar los recursos de la máquina, de tal forma que el servicio quede bloqueado pero la máquina no. En cuanto el DoS cesa, el servicio se restaura automáticamente (si está bien configurado). Otra manera de paliar el problema es limitar el número de conexiones al límite razonable que pueda aguantar la máquina sin caerse.
Flood a los DNS
Se está empezando a poner de moda la distribución de código fuente que implementa un virus/troyano con ataque incluído al servicio DNS.
Cualquier empresa de Internet basa su servicio en el DNS (Domain Name service), entiendo que sobra explicar qué significa el acrónimo DNS y sus implicaciones. Como quiera que sea, si una entidad financiera no tiene DNS, no tiene servicio, y por tanto esta fuera del mercado.
Las mafias se han dado cuenta de esto y han diseñado ataques que básicamente anulan este servicio. ¿Cómo? Muy fácil. Lanzan miles de consultas por segundo a los DNS de la entidad financiera, con nombres aleatorios e inexistentes. Con ello logran colapsar y derribar el servicio DNS.
Hasta ahora, los ataques de este tipo que he visto generan paquetes con el mismo identificador de Query (número de petición aleatorio DNS, para cachear las contestaciones y que no puedan ser mezcladas/falsificadas/confundidas con otras queries), pero es cuestión de tiempo que el identificador se genere aleatorio también.
Las soluciones a este tipo de ataques son muy limitadas, al menos de momento. Si no se usa el DNS y se opta por resolver el nombre de las máquinas de la entidad financiera en local (haría falta la distribución de un software específico que modificase el \windows\system32\drivers\etc\hosts a los usuarios inexpertos), la entidad financiera perderá la flexibilidad que le otorga el DNS.
Sin embargo, esta solución se perfila como la única viable. Claro que, para ser realmente eficaz, ha de ser implantada antes de sufrir el ataque, ya que si no, después será terriblemente costoso.
El correo no aguantará
No hay nada peor para un correo que recibir miles de correos al minuto para destinatarios que no existen de orígenes que tampoco existen. No solamente se recibe un correo (habitualmente de pocos bytes) sino que encima la máquina trata de devolverlo a un origen inexistente, lo que genera una cascada de correos salientes.
El sistema de correo, cuando recibe un correo para un destinatario inexistente, ha de verificar toda su lista y luego enviarle un mensaje de error. Si esto se repite, digamos 1000 veces al minuto, el colapso de la máquina es inevitable.
Si estos correos vienen de diferentes IPs, con emails orígenes aleatorios y destinatarios aleatorios, el colapso es inevitable y la solución a este tipo de ataque es muy mala. Evidentemente la táctica utilizada es similar a la del DNS, un montón de “zombies” con su propio sistema de SMTP que envían correos cada minuto. Conseguir que un virus/troyano “persuada” a 50.000 pc’s en internet, es una tarea algo menos que “trivial”. He visto incluso variantes que consultan cada 30 minutos los registros MX de los destinos atacados, lo cual invalida soluciones como cambiar los servidores de correo y actualizar/propagar los nuevos registros MX.
La única solución viable que veo de momento, pasa por identificar explícitamente a las X entidades bancarias con las que haya contacto, los X ISP mayores del país, así como las X empresas con las que se mantienen contacto, y limitar la posibilidad de abrir sockets a la máquina de correo solamente desde los registros MX de estas empresas, lo cual ayudará a paliar un ataque de este tipo, pero indudablemente generará muchas incomodidades.
Conclusión
El panorama que viene se torna oscuro, y solamente el más preparado sobrevivirá. La toma de decisiones a tiempo será la que marque la diferencia entre la entidad que lentamente iniciará su lento declinar en este mundo online que viene, y la que prevalecerá como lider indiscutible en el mundo online.
No olvidemos que la indisponibilidad de los sistemas será la clave para la garantia del servicio.... ¿y qué es Internet para las empresas sino un medio de ahorrar costes en el servicio?
