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.
‘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.
