Implementar Latch Cloud TOTP en un APM de F5ElevenPaths 1 febrero, 2018 Cada vez que nos reunimos con nuestros Partners de Alianzas Estratégicas, es una excusa para compartir experiencias, tecnologías y aprender. Ver cómo, entre ambos, podemos seguir mejorando la seguridad de nuestros clientes. En días pasados, Andrew Oteiza me estuvo comentando sobre las bondades de F5 APM, y comenzamos a hablar sobre la posibilidad de utilizar nuestro Latch Cloud TOTP para poder loguearte al portal sin problemas. Debido a esta accesibilidad, decidimos escribir este post dedicado a aquellos que gestionen F5 APM basándonos en el artículo publicado sobre cómo usar 2FA en el APM. La implementación de Latch Cloud TOTP se relaciona directamente con la posibilidad de ejecutar un iRule en el F5 para poder generar los códigos QR, por lo cual, lo primero que se debe hacer es crear un Virtual Server con el iRule que ejecuta esa acción (generate_ga_code), asignarle una IP y un puerto de conexión, el perfil del usuario y en los recursos asignar el iRule. Imagen 1: Virtual Server creado, con una IP, un puerto y un perfil asignado Imagen 2: iRule Generador de Código QR asignado Una vez iniciado el Virtual Server, hay que ingresar al mismo a través de la IP y puertos asignados para poder ejecutar el iRule y así generar el código QR que leeremos con Latch. Al generarse el código QR, se generará un string único que utilizaremos en el BIG-IP como DataGroup, para lo cual creamos un nuevo DataGroup List (iRules-> Data Group List) de tipo string y asignarle un nombre (en el ejemplo: google_auth_keys). Ingresamos el string del código obtenido anteriormente para finalmente realizar el update y guardar los cambios. Todos estos pasos podemos verlos en el siguiente vídeo (Vídeo 1): Vídeo 1: Generación del Código QR en el Virtual Server (IP Demo 10.1.10.80) y asignación del string en el DataGroup del Big-IP. Hasta aquí tenemos la generación del código QR y la lectura con nuestro móvil. Sin embargo, debemos modificar la política implementada en el F5 para que nos permita manejar el token generado por Latch Cloud TOTP. Para llevar a cabo esta acción, debemos de generar otro iRule al que llamaremos ga_code_verify y lo asignaremos al Virtual Server que actualmente tiene la política de APM (sería uno distinto al utilizado anteriormente para generar el código QR, en el siguiente vídeo de ejemplo (Vídeo 2), tiene la IP 10.1.10.47). Este iRule tomará como variable el token introducido, y verificará que que el secret key, resguardado en el Data Group List, sea el correcto. Vídeo 2: Modificación de la política del APM. Después de haber creado la web de login, el siguiente paso es generar un Custom iRule Event Agent. Referenciaremos al iRule ya creado previamente (ga_code_verify) y le asignaremos distintas salidas según el resultado obtenido al ingresar el usuario el token: Imagen 3: salidas dependiendo del resultado obtenido al verificar el token. Name: Successful Expression: expr { [mcget {session.custom.ga_result}] == 0 } change Name: No Google Auth Key Found Expression: expr { [mcget {session.custom.ga_result}] == 2 } change Name: Invalid Google Auth Key Expression: expr { [mcget {session.custom.ga_result}] == 3 } change Name: User locked out Expression: expr { [mcget {session.custom.ga_result}] == 4 } change Al pasar por este control, estará la validación del usuario en el AD y la asignación de recursos. De la política existente agregaremos dos instancias, una para que el usuario ingrese el token, y otra donde haremos la verificación de que el token es correcto. Imagen 4: gráficos del proceso de verificación completo Finalmente, aplicaremos la política y verificaremos su funcionamiento desde la óptica del usuario, que será exactamente igual a como estamos acostumbrados a usar LATCH Cloud TOTP, tal como puede verse en el siguiente vídeo (Vídeo 3): Vídeo 3: Ingresando al APM utilizando Latch Cloud TOTP Claudio Caracciolo Team Leader of the CSA and the Bs. As. Research Office at ElevenPaths claudio.caracciolo@11paths.com @holesec ¡Ya tenemos los resultados de #CDO Challenge!Historias de #MujeresHacker: Ana Molina, Service Designer en Telefónica Aura
Daniel Pous Montardit Resiliencia, clave en sistemas Cloud-Native En el primer post de la serie Cloud-Native, ¿Qué significa que mi software sea Cloud Native?, presentamos la resiliencia como uno de los atributos fundamentales que nos ayudan a...
Telefónica Tech Boletín semanal de Ciberseguridad, 21 – 27 de enero Killnet apunta contra objetivos en España Esta semana el grupo hacktivista Killnet anunció una campaña de ataques contra Alemania, dando lugar a la realización de ataques de Denegación de Servicio...
Gonzalo Fernández Rodríguez ¿Qué significa que mi aplicación sea Cloud Native? El término Cloud Native es algo que va más allá de mover las aplicaciones alojadas en un data center a una infraestructura proporcionada por un proveedor Cloud, sea Cloud...
Telefónica Tech Boletín semanal de Ciberseguridad, 14 – 20 de enero Vulnerabilidades críticas en los router Netcomm y TP-Link Se han descubierto una serie de vulnerabilidades en los routers Netcomm y TP-Link. Por un lado, los fallos, identificados como CVE-2022-4873 y CVE-2022-4874, se tratan de un...
Jorge Rubio Álvarez Consecuencias de un ciberataque en entornos industriales Podemos encontrar entornos industriales en cualquier tipo de sector que nos podamos imaginar, ya sea en empresas de tratamiento de agua, transporte, farmacéuticas, fabricación de maquinaria, eléctricas, alimentación o...
Telefónica Tech Boletín semanal de Ciberseguridad, 7 – 13 de enero Microsoft corrige 98 vulnerabilidades en su Patch Tuesday Microsoft ha publicado su boletín de seguridad correspondiente con el mes de enero, donde corrige un total de 98 vulnerabilidades. Entre estas...