Está claro que podemos seguir mejorando la seguridad de nuestros clientes. Y este es un caso 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.

Figura 1. Virtual Server creado, con una IP, un puerto y un perfil asignado.

Figura 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:
Figura 3: 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 el secret key, resguardado en el Data Group List, sea el correcto.
Figura
4: 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:

Figura 5: 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.

Figura 6: 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:
Figura 7: Ingresando al APM utilizando Latch Cloud TOTP.
La información para esta entrada ha sido proporcionada por mi compañero Claudio Caracciolo.
Y la entrada en el Blog de ElevenPaths correspondiente.
http://blog.elevenpaths.com/2018/02/implementar-latch-cloud-ciberseguridad.html#more

