¿Un DDoS legal?

El fútbol es un deporte que tiene muchísimos seguidores y mueve mucho dinero en España, por eso se dice que a los españoles nos pueden subir el IVA o endurecer las condiciones laborales pero no nos pueden quitar el fútbol, si fuese así, el primer domingo sin fútbol tendríamos una guerra civil. Este fin de semana mientras que los forofos veíamos el Madrid – Barça se estaba librando una batalla, o mejor dicho una ciberguerra, entre el grupo Prisa, Mediapro y la LFP contra las webs de videostreaming que enlaza rojadirecta.com. Concretamente la empresa IPRODED ha sido la encargada de lanzar un ataque DDoS contra los servidores que retransmitían el clásico Madrid – Barça.

¿Cómo se lanza una ataque DDoS de manera legal? Pues eso mismo me pregunto yo. Si leemos la directiva marco 2005/222/JAI introducida en nuestro Código Penal a través de la Ley Orgánica 5/2010, se dice “Los principales tipos de infracciones penales cubiertos por esta decisión marco son los ataques contra los sistemas de información * tales como la piratería, los virus y los ataques por denegación del servicio.” Sin embargo todos sabemos que el fútbol mueve mucho dinero y tiene mucho poder, lo podemos ver en los fichajes astronómicos, las deudas millonarias de los clubs contra la hacienda pública y ahora por qué no … realizando ciberataques a todo aquel que les moleste.

Los españoles no somos los únicos que nos saltamos la ley, según documentos revelado por Edward Snowden una división del GCHQ llamada JTRIG lanzó una operación en 2011, con nombre Rolling Thunder, que consistía en realizar ataques de DDoS contra los chats de Anonymous, además de propagar malware para identificar a los hacktivistas. Mientras tanto, hemos podido ver que varias personas pertenecientes al grupo Anonymous o LulzSec han sido llevadas a la cárcel por participar en ataques de DDoS, por ejemplo los ataques a PayPal y MasterCard cuando estas compañías decidieron dejar de dar donaciones a WikiLeaks, ataques al FBI, CIA y GCHQ al cerrar la web de megaupload, aprobar la ley SOPA para combatir la piratería o castigar al soldado Chealse Manning por filtrar miles de documentos clasificados a WikiLeaks.

No hay información sobre qué tipo de ataques de DDoS están realizando estar organizaciones contra Anonymous y rojadirecta.com, es decir, si utilizan alguna botnet o utilizan un ataque de DDoS amplificado, lo cuál sobrepasaría la ilegalidad. O si por el contrario utilizan sus propios recursos, CPU y ancho de banda, para provocar la denegación de servicio. En cualquier caso, ellos tienen el poder y parece ser que pueden actuar como quieran.

Entrar en la legalidad o ilegalidad de estas operaciones está fuera de mi alcance debido a mis limitados conocimientos en leyes, pero supongo que al igual que pueden desalojar una plaza mediante cargas policiales en una manifestación también pueden realizar este tipo de ataques contra servicios webs y no pasará nada.

Lo que está claro que tanto en el mundo real con las cargas policiales como en el mundo virtual con los ataques de DDoS, los ciudadanos y usuarios finales ajenos a la operación estamos afectados por la inutilización de las calles durante el desalojo como la inutilización de los servicios webs y líneas de comunicaciones saturadas debido al ataque. Así que creo que la mejor elección para sacar un dinerillo extra es que a partir de ahora yo también me ofrezca a realizar ataques de DDoS al igual que el chico del siguiente vídeo:

Un saludos amigos.

Vulnerabilidad POODLE SSLv3

Esta semana toca escribir sobre la vulnerabilidad de SSLv3 llamada POODLE (Padding Oracle On Downloaded Legacy Encryption). Existe muchísima información en Internet de cómo se puede llegar a descifrar una sesión SSL utilizando la vulnerabilidad del protocolo que aprovecha la manera que el cifrado por bloques CBC es implementado dentro de SSLv3.

El protocolo de cifrado SSLv3 fue diseñado hace 18 años para proporcionar comunicaciones seguras en Internet. Aunque la mayoría de aplicaciones soportan el protocolo TLS, siendo este mucho más robusto, aún muchos servicios y navegadores soportan SSLv3.

¿Qué dispositivos son vulnerables?

Todas las aplicaciones, navegadores y servidores que soporten SSLv3.

¿Cuál es exactamente la vulnerabilidad?

La vulnerabilidad está basada principalmente en dos fallos de SSLv3:

• SSLv3 genera bytes de relleno de manera aleatoria.
• El Message Authentication Code (MAC) calculado para comprobar la integridad de cada mensaje después del cifrado no incluye estos bytes de relleno.

Por lo tanto, estos bytes de relleno pueden ser modificados mediante un ataque Man In The Middle sin ser detectado por el cliente ni el servidor.

¿Es una vulnerabilidad importante?

Aunque se necesita realizar un MITM para explotar la vulnerabilidad, sí que se considera importante por la cantidad de aplicaciones y servicios que están expuestos, ya que la mayoría de navegadores (Chrome, Firefox, IE) soportan SSLv3, además de que la mayoría de sitios web HTTPS también soportan SSLv3.

¿Debería estar preocupado?

Teniendo en cuenta que para explotar la vulnerabilidad el atacante debe encontrarse en la misma red que la víctima, la ejecución satisfactoria del ataque tiene unas necesidades muy específicas que sitúan la vulnerabilidad por detrás de otras, como por ejemplo Heartbleed.

¿Cómo puedo prevenir el ataque?

Hay dos maneras para prevenir el ataque. Es suficiente con deshabilitar el soporte de SSLv3, o los modos de CBC con SSLv3, en los servidores web y en los navegadores y aplicaciones de clientes, sin embargo esto puede presentar problemas de compatibilidad. La otra alternativa es soportar TLS_FALLBACK_SCSV. Este último mecanismo resuelve el problema de los re-intentos de conexión fallidos que puede provocar un atacante para forzar a los navegadores a utilizar SSLv3. Y por tanto también previene el downgrade de TLS 1.2 a TLS 1.1, además de que puede ayudarnos a prevenir futuros ataques.

Esta última vulnerabilidad, además de hacernos trabajar a todos los ingenieros de seguridad para mitigarla lo antes posible, parece ser que puede ser la punta del iceberg tras Heartbleed para que fabricantes de software dejen de soportar el protocolo SSLv3 y trabajen exclusivamente con TLS.

Un saludos amigos!

Checksum

El checksum y el CRC son mecanismos para detectar errores en la transmisión de datos que nos ayudan a determinar la integridad de los datos transmitidos por la red. Para ello el emisor realiza una función hash de los datos a transmitir, y el valor hash lo transmite junto con los datos, de esta manera el receptor realiza la misma operación una vez recibido los datos, y compara el valor hash recibido con el valor hash calculado, si los hash son iguales, los datos no han sufrido ninguna alteración en el camino, en cambio si los hash son distintos no se puede asegurar la integridad de los datos recibidos y por tanto son descartados.

Este tipo de comprobaciones las podemos ver en varias capas del modelo TCP/IP e incluso algunas veces podemos llegar a pensar que se realiza demasiadas comprobaciones de manera redundante, entonces ¿por qué existe un checksum en cada una de las capas?

Capa 4 – Nivel de Transporte – TCP/UDP

Tanto en la cabecera de TCP como en la de UDP disponemos de un checksum de dos bytes para la detección de errores. Para calcular este checksum se utiliza el segmento completo, es decir, la cabecera TCP o UDP y los datos de la capa de aplicación. Si se detecta un error en la transmisión de los datos, el protocolo TCP puede solicitar la retransmisión del segmento.

Capa 3 – Nivel de Red – IP

En el protocolo IPv4 nos encontramos dos bytes para la detección de errores en la capa de red. Para calcular este checksum tan solo se utiliza la cabecera del paquete IP, por tanto a diferencia de las comprobaciones de la capa 4, en la capa de red no se tienen en cuenta los datos para la detección de errores. Sin embargo, en el protocolo IPv6 se prescinde del checksum y la protección de integridad se realiza en la capa superior de transporte y en la capa inferior de enlace.

Capa 2 – Nivel de enlace – Ethernet

El estándar más utilizado en redes LAN dispone de cuatro bytes al final de la trama para la detección de errores. El FCS tiene en cuenta toda la trama para realizar el cálculo del checksum, es decir, realizará el cálculo con la cabecera de la trama y los datos de las capas superiores. Si se detecta un error en la transmisión de los datos se descartará la trama sin comunicárselo al emisor.

Como hemos podido ver, cada una de las capas dispone de un checksum para la detección de errores. Sin embargo, aunque pueda parecer redundante cada una de ellas tiene sus funciones:

• IP no siempre funciona sobre Ethernet, imagina IP sobre RS-232. Por tanto es necesario realizar la detección de errores en capas superiores a la capa de nivel de enlace.
• TCP/UDP realiza la comprobación de la cabecera TCP/UDP y de los datos de la capa de aplicación pero no de las cabeceras de las capas inferiores.
• IP no realiza el checksum de los datos, tan solo de la cabecera IP. Por tanto, es necesario que esta comprobación la realice otras capas.
• Ethernet realiza la comprobación de la trama completa.
• Cada vez que una nueva cabecera es introducida hay más que comprobar y las capas superiores no ven los bits de las cabeceras de las capas inferiores.
• Ethernet realiza el checksum cada vez que la trama da un salto, es decir, se recalcula el checksum cada vez que la cabecera Ethernet cambia. Sin embargo, el checksum TCP/UDP se realiza de extremo a extremo, por tanto tan solo se recalcula en el emisor y el receptor del segmento.
• Si se detecta un error en TCP se solicitará la retransmisión del segmento, sin embargo si se detecta un error en Ethernet se descarta la trama sin comunicárselo al emisor.

Para finalizar, podemos ver que para asegurar la integridad de los datos y tener redes eficientes es necesario realizar una serie de comprobaciones en cada una de las capas del modelo TCP/IP, sin embargo estos cálculos requieren recursos de cómputo que pueden disminuir la eficiencia de la red y que normalmente son calculados por software mediante el driver de la tarjeta de red. No obstante en escenarios de alta capacidad y exigencias siempre se recomienda utilizar tarjetas de red con procesadores de red Asics dedicados para este tipo de operaciones, y estas características son las que marcan la diferencia en cuanto a precio y rendimiento en el mercado de tarjetas de red.

Un saludo amigos.

DNS Load Balancing

El servicio DNS es ampliamente conocido por todos los que nos dedicamos a las TIC. Este servicio simplemente trata de resolver los nombres de dominio y traducirlos a direccionamiento IP, facilitando el acceso a los recursos a través de su nombre en lugar de tener que recordar la IP. Por tanto, estamos hablando de un servicio muy importante que si no está accesible muchos usuarios pueden llegar a pensar que no tienen acceso a Internet.

Sin embargo, un servicio tan “simple”, y a la vez tan importante, como el DNS no sólo realiza funciones de traducción de nombre a IP, sino que también tiene otras cualidades como resolución inversa de DNS, muy útil para la detección de servidores de Spam, y balanceo de carga. Esta última característica nos permite distribuir la carga de nuestros servidores e incluso realizar Geobalanceo basándonos en la dirección IP origen de las solicitudes.

Para distribuir la capacidad de los servidores será necesario definir en el fichero de la zona DNS tantos registros tipo A como servidores a balancear. Por ejemplo, podemos ver a continuación que el servicio FTP tiene tres nodos mientras que el servicio WWW tiene dos nodos.

Una vez que el usuario realice la petición DNS sobre el servicio balanceado, el servidor DNS devolverá tantos registros como haya definido en la zona. Y mediante el atributo rrset-order implementará un método u otro de balanceo de carga, pudiendo utilizar:

• Fixed: Los registros son devueltos en el orden que están definidos en la zona.
• Random: Los registros son devueltos de manera aleatoria.
• Ciclic: Los registros son devueltos utilizando el algoritmo Round Robin.

Esta funcionalidad es fácil de ver y comprobar si realizamos peticiones DNS mediante nslookup a por ejemplo www.google.es. A continuación podemos ver cómo www.google.es nos devuelve cuatro direcciones IP para acceder a su buscador web, y si realizamos la misma operación varias veces podremos ver cómo el orden de las respuestas puede variar:

Una vez recibida la respuesta DNS, el sistema operativo del usuario elegirá una IP de entre las disponibles para acceder al servicio web. Algunos sistemas operativos elegirán la primera IP, mientras que otros como Windows dependerá de si tienen la pila IPv6 instalada, además de la máscara del cliente. En cualquier caso, si el recurso solicitado es una página web, la mayoría de los navegadores actuales son capaces de detectar de si el recurso es alcanzable, si no lo está utilizará la siguiente IP de la lista entregada por el servidor DNS.

Mientras que para realizar Geobalanceo deberemos utilizar la función Split Horizon, donde la respuesta dependerá de la dirección IP origen de la solicitud DNS, es decir, podemos tener un servidor web en Los Ángeles y otro en Nueva York de tal manera que los usuarios de Los Ángeles siempre accederán al servidor de Los Ángeles y los usuarios de Nueva York al servidor de Nueva York. Y si el servidor de Los Ángeles se encuentra inaccesible, el servidor de DNS comenzará a resolver con la dirección IP de Nueva York:

Ahora muchos estaréis pensando ¿para qué comprar un balanceador de carga si podemos realizar las mismas funciones con el DNS? Un balanceador de carga, además de distribuir la carga de los servidores es capaz de proporcionar alta disponibilidad ya que los usuarios siempre accederán a la misma dirección IP y no se enterarán si uno de los nodos cae. Mientras que en una solución de balanceo de carga por DNS, el navegador tiene que darse cuenta que el servicio está inaccesible para posteriormente utilizar otra IP, además cuantas más IPs tenga disponible el usuario más posibilidades hay de que una de ellas falle. Por otro lado, con una solución de balanceo de carga basado en el DNS es necesario bajar el TTL a 0 para que el resto de servidores DNS no cacheen las peticiones y por tanto el número de peticiones y la carga hacia tu servidor de DNS será mucho mayor, además otro problema del cacheo lo podemos encontrar en los navegadores de los clientes ya que por ejemplo Internet Explorer mantiene la resolución de nombres durante 30 minutos.

En definitiva, con un balanceador de carga tenemos mayor control sobre la carga que queremos aplicar a cada uno de los nodos, además de poder realizar funciones de health check para comprobar si uno de los nodos no se encuentra disponible y así dejar de enviarle peticiones. Esta última característica de health check no está disponible con el balanceo de carga basado en DNS y si uno de los nodos no está accesible será necesario de manera manual eliminar la entrada del servidor DNS, a no ser que utilices DNS Failover & System Monitoring que utiliza las técnicas de Global Server Load Balancing para balancear y monitorizar los servicios.

Por último, muchos pueden estar pensando, ¿cómo compañías como Google utilizan balanceo de carga basado en DNS? Realmente ellos utilizan este sistema para repartir la carga pero no para proporcionar alta disponibilidad, es decir, los usuarios finales realizan peticiones sobre un cluster balanceado como podemos ver en la siguiente imagen, proporcionando alta disponibilidad y balanceo de carga:

 

Un saludo amigos.