A diferencia de la mayoría de capítulos del podcast hoy tenemos un invitado con el que charlaremos sobre Zero Trust Architecture: Joan Massanet.
Joan es el CEO de la empresa World2Connect y colabora con la revista de seguridad informática ClickCiber.
Fuente imagen:
La arquitectura de confianza cero es un concepto sencillo de entender pero con una gran dificultad de aplicación en el mundo real. Un sistema de ciberseguridad basado en ZTA simplemente no confía en los equipos, las redes o los usuarios por ser quienes son, sino que analiza, en tiempo real, la idoneidad o no del acceso a un recurso o información concreta en un momento dado. Quizás el ejemplo más sencillo sea que un administrativo puede acceder a la información de la empresa en horario laboral, porque debe poder trabajar, pero ese mismo acceso en fin de semana o de madrugada, cosa no habitual, estaría prohibido.
El problema de ZTA no es su concepto sino su implantación en nuestro mundo real donde existen multitud de situaciones extraordinarias y variables que deben ser tenidas en cuenta para que el sistema se adapte a nuestras necesidades reales. Siguiendo el mismo ejemplo no sería descabellado que los días previos a la presentación de declaraciones de impuestos nuestro administrativo deba realizar algún trabajo urgente de última hora fuera de su horario, así que el sistema de seguridad debería tenerlo en cuenta.
Obviamente esto es sólo un ejemplo sencillo y hay muchas más cosas a tener en cuenta.
Sin más, os invito a echarle un oído al capítulo de hoy.
Low Orbit Ion Cannon (LOIC) es una herramienta utilizada para realizar ataques de denegación de servicio (DoS y DDoS). Originalmente fue desarrollado como una aplicación de prueba de estrés de red , pero desde entonces se ha convertido en código abierto y ahora se usa principalmente con intenciones maliciosas.
Es conocida por ser una herramienta muy fácil de usar y con una interfaz gráfica muy simple. Además ganó notoriedad por su uso por parte de miembros de grupos hacktivistas.
Funcionamiento de LOIC
LOIC fue desarrollado como una forma de comprobar la capacidad de los servidores web por lo que inunda al servidor de destino con paquetes TCP, UDP o HTTP con el objetivo de saturarlo e interrumpir el servicio.
En general, un atacante que usa la LOIC no puede generar suficiente tráfico basura para causar un impacto serio en un objetivo, por lo que se se suele utilizar como una herramienta para ataques coordinados buscando denegaciones de servicio distribuidas. Cabe indicar que para facilitar esta coordinación el programa permite ser controlado de forma centralizada desde canales IRC.
Protección frente a LOIC
Los ataques individuales usando LOIC son fáciles de detectar y bloquear por cualquier sistema IPS automatizado, aunque en caso de no tenerlo un administrador debería ser capaz de identificar las direcciones IP atacantes y bloquearlas manualmente.
Los problemas aparecen en cuanto el ataque se realiza de forma coordinada y simultánea desde múltiples fuentes. En estos casos de DDoS, los sistemas WAF ayudan a bloquear las peticiones HTTP maliciosas, mientras que el tráfico UDP y TCP debe ser gestionado por sistemas de protección anti-DDoS específicos.
Cabe indicar que los ataques que utilizan LOIC son relativamente fáciles de detectar y, como no puede funcionar a través de proxy web, dejan rastro de las direcciones IP origen de los atacantes.
‘R U Dead Yet?’ o simplemente R.U.D.Y. es una herramienta que busca la denegación de un servicio web a la página web a reservar recursos para una conexión absurdamente lenta. Mientras la mayoría de ataques de denegación de servicio se basan en el envío de una gran cantidad de conexiones rápidas para conseguir la saturación, RUDY utiliza un enfoque opuesto: ‘relativamente’ pocas conexiones de gran duración que lleguen a agotar los recursos del servidor al no permitirle liberarlos por mucho tiempo.
Esta herramienta tiene un funcionamiento muy sencillo que permite que cualquiera la utilice sin requerir conocimiento alguno: simplemente hay que indicarle la dirección de la web que queremos atacar y darle al botón y lanzamos el ataque. Debido a su funcionamiento cualquier web que tenga un formulario es susceptible de ser atacada mediante esta técnica.
El programa R.U.D.Y. revisa la web indicada en busca de un formulario. Sirve cualquier formulario: uno sencillo de contacto es suficiente.
Ahora la herramienta establece una primera conexión con un mensaje HTTP POST, pero indicándole al servidor destino que el tamaño del mensaje es muy grande (10,100MB, 20GB.). Esto hará que el servidor reserve espacio de memoria suficiente para recibir esta información tan voluminosa.
Una vez establecida la primera conexión, ahora la herramienta empieza a enviar datos a una velocidad exageradamente lenta. Piensa que puede enviar un único byte por paquete a intervalos de aproximadamente 10 segundos.
La herramienta seguirá enviando información lentamente y el servidor, al ir recibiendo actualizaciones, no cerrará la sesión pues creerá que se trata simplemente de un usuario con una mala conexión.
Si combinas múltiples sesiones de R.U.D.Y. es posible agotar los recursos del servidor atacado al llegar a saturar el espacio de memoria disponible o bien, más probablemente, el número de sesiones simultáneas que el servidor puede manejar. Así pues, si se combina un ataque R.U.D.Y desde varios orígenes, se puede obtener una denegación de servicio distribuida (o DDoS).
Protecciones
Al contrario que otros tipos de ataques de denegación de servicio, un ataque tipo R.U.D.Y es mucho más silencioso y sutil, por lo que es más difícil de detectar.
En las primeras versiones de la herramienta los paquetes se enviaban de forma continua cada 10 segundos, por lo que los sistemas IDS podían detectarlos con relativa facilidad, pero ahora mismo este envío de información se realiza de forma semialeatoria: a estos 10 segundos fijos se le añaden o restan un número aleatorio de segundos para evitar ser detectado por esta regla estática.
La forma más habitual para evitar este tipo de ataques es simplemente cerrar este tipo de conexiones tan lentas. Aunque esto hará que usuarios legítimos con conexiones muy lentas se verán impedidos de acceder a nuestro servicio web.
Otra defensa es el uso de proxys inversos que controlen y gestionen del tráfico de datos de tal forma que sean estos los que realicen las reservas de recursos para gestionar las conexiones lentas y no los propios servidores web.
Como el servicio DHCP es utilizado por los equipos que se conectan a una red y desconocen todo de ella, no podemos delegar en ellos mismos las funciones de seguridad. De igual forma, al no saber qué hay o no hay en la red no podemos reposar la seguridad en los servidores de la red, porque el equipo nuevo no sabe que debe consultarles a ellos. Así pues, la seguridad del protocolo DHCP descansa en los propios equipos de red.
Para asegurar que los nuevos usuarios sólo reciben la información del servidor DHCP oficial de la red los switches inspeccionan el tráfico de este protocolo y bloquean aquel que no cumpla las características especificadas por los administradores de red.
Esta página web utiliza cookies de terceros con fines estadísticos y publicitarios. Si sigues navegando entenderemos que aceptas su uso. - Más información en nuestra política de cookies. AceptarRechazarLeer más
Política de Cookies
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
