on 25-Sep-2015 14:30
F5 like most large enterprises organizations require Two-Factor Authentication (TFA) for employee remote connectivity. To meet this requirement IT integrated BIG-IP Access Policy Manager with a third-party vendor that provides One-Time Passwords (OTP). After users successfully authenticate they are prompted to provide their OTP that is then verified against a Radius server. Most of the time this works great but occasionally the employees preferred Operating System or VPN Client doesn’t support multiple authentication methods.
Traditionally to work around these limitations employees would be required to concatenate their Password + OTP. While BIG-IP Access Policy Manager is capable of supporting concatenated passwords there is a more graceful option, TFA through a Captive Portal
To workaround the limitation mentioned above IT decided to configure BIG-IP Access Policy Manager to allow all clients to establish a VPN for remote connectivity regardless of the clients ability to preform TFA. An iRule is used to determine whether or not the employee successfully completed TFA.
Clients that natively support TFA are prompted to provide their username, password and OTP on initial connection. After they successfully authenticate and complete TFA they are granted access to the appropriate resources.
Clients that do not support TFA are prompted to provide a valid username and password, after the employee successfully authenticates all HTTP & HTTPS requests are intercepted and a custom login page is returned in response. This custom login page prompts the user to provide a valid OTP. Until the employee provides the correct OTP all traffic is rejected by an iRule applied. Once the employee provides the correct OTP the iRule updates an BIG-IP Access Policy Manager session variable to indicate that the employee should have the same network access as clients that natively support TFA.
This solution will leverage layered virtual servers and this could negatively impact network access tunnel layer 4 ACL
https://support.f5.com/kb/en-us/solutions/public/14000/200/sol14219.html?sr=48427459
We need to differentiate the clients that either do or do not support TFA, IT did this by configuring the BIG-IP Access Policy Manager access policy to detect the Client Type or Operation System as seen below.
Since clients that don’t support TFA will not be able to validate their OTP against the “Remote Access” policy we will need to create an alternative way to validate their tokens. To do this create a second Access Profile and configure the Access Policy to validate the OTP token using the preferred method in ITs case that was radius.
If you have questions on iFiles please see => Referencing External Files
<HTML><HEAD><TITLE>TWO-Factor Captive Portal</TITLE> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <META content=no-cache http-equiv=pragma> <link rel="stylesheet" type="text/css" HREF="/public/include/css/apm.css"> </HEAD> <BODY> <META id=viewport name=viewport content="width=device-width, initial-scale=1.0"> <META name=robots context="noindex,nofollow"> <TABLE id=page_header> <TBODY> <TR> <TD id=header_leftcell><IMG src="/public/images/my/flogo.png"></TD> <TD id=header_rightcell></TD></TR> <TR> <TD></TD> </TR></TBODY></TABLE> <TABLE id=main_table class=logon_page> <TBODY> <TR> <TD style="WIDTH: 1%" id=main_table_info_cell> <FORM id=auth_form method=post name=e1 action="/my.policy" autocomplete="off"> <TABLE id=credentials_table> <TBODY> <TR> <TD id=credentials_table_header colSpan=2>TWO-Factor Token Validation</TD></TR> <TR> <TD id=credentials_table_postheader colSpan=2></TD></TR> <TR> <TD class=credentials_table_unified_cell colSpan=2><LABEL for=text>Username</LABEL><INPUT id=input_1 class=credentials_input_text name=username disabled></TD></TR> <TR> <TD class=credentials_table_unified_cell colSpan=2><LABEL for=text>One-Time Passcode</LABEL><INPUT id=input_2 type="tel" class=credentials_input_text name=password autocomplete="off" autocapitalize="off"></TD></TR> <TR id=submit_row> <TD class=credentials_table_unified_cell><INPUT class=credentials_input_submit value=Validate type=submit></TD></TR> <TR> <TD id=credentials_table_footer colSpan=2></TD></TR></TBODY></TABLE><INPUT value=standard type=hidden name=vhost> </FORM> </TD></TR></TBODY></TABLE> <DIV id=page_footer> <DIV>This product is licensed from F5 Networks. © 1999-2014 F5 Networks. All rights reserved. </DIV></DIV> <DIV id=MessageDIV class=inspectionHostDIVSmall></DIV></BODY></HTML>
The iRule listed below will be applied to a virtual that will be targeted with the virtual-to-virtual (V2V) function.
when CLIENT_ACCEPTED { if {[TCP::local_port] eq 80} { SSL::disable clientside SSL::disable serverside } } when HTTP_REQUEST { set _un [ACCESS::session data get session.logon.last.username] if {[HTTP::method] ne "POST"} { set _fqdn [ACCESS::session data get session.server.network.name] set _captivePortal[ifile get "/Common/Captive_Portal.html"] set _captivePortal[string map [list "/my.policy" [HTTP::uri]] $_captivePortal] set _captivePortal[string map [list "HREF=\"" "HREF=\"https://$_fqdn"] $_captivePortal] set _captivePortal[string map [list "src=\"" "src=\"https://$_fqdn"] $_captivePortal] set _captivePortal[string map [list "input_1" "input_1 value=\"$_un\""] $_captivePortal] HTTP::respond 200 content $_captivePortal "Content-Type" "text/html; charset=UTF-8" } elseif {[HTTP::method] eq "POST" } { HTTP::collect [HTTP::header content-length] } } when HTTP_REQUEST_DATA { set _payload"?[HTTP::payload]" set _otp[URI::query $_payload "password"] if {$_otp eq ""}{HTTP::redirect [HTTP::uri];return} set _flow_sid[ACCESS::session create -timeout 600 -lifetime 3600] set _profile"/Common/Captive_Portal" ACCESS::policy evaluate -sid $_flow_sid -profile $_profile session.logon.last.username $_un session.logon.last.password $_otp set _result[ACCESS::policy result -sid $_flow_sid] ACCESS::session remove -sid $_flow_sid if {$_result eq "allow"} { ACCESS::session data set session.radius.last.result 1 TCP::close HTTP::redirect [HTTP::uri] } else {HTTP::redirect [HTTP::uri]} HTTP::release }
This iRule will be applied to the Layered Virtual Server that will be created later on. This iRule checks to verify that user traffic has PASSED TFA before allowing it to access network resources. It will also detect webtop traffic and allow that through.
when CLIENT_ACCEPTED { set _radius[ACCESS::session data get session.radius.last.result] set _clientip[ACCESS::session data get session.assigned.clientip] if {$_radius eq 1 || $_clientip eq ""} { return } elseif {$_radius ne 1 && $_clientip ne "" && [IP::protocol] ne 17 } { virtual /Common/v2v_CaptivePortal_v4 } elseif {([IP::protocol] eq 17 && [UDP::local_port] eq 53) || ([IP::protocol] eq 6 && [TCP::local_port] eq 53) } { return } else { reject } }
This virtual server listens on the “connectivity” vlan. The “connectivity” vlan is associated with the connectivity profile applied to the virtual server used to provide employee remote access.
It is commonly referred to as a Layered Virtual Server. For more information on Layered Virtual Servers (LVS) see => Common Deployment Examples for Single Sign-On
This LVS will match all traffic except TCP port 80, a more specific LVS (_tmm_apm_fwd_vip_http) embedded within BIG-IP Access Policy Manager is used to enforce L4 ACL. See below on steps to create a more specific LVS to capture port 80 traffic
ltm virtual lvs_CaptivePortal_v4_ANY { destination 0.0.0.0:any ip-protocol any mask any profiles { fastL4 { } } rules { Captive_Portal_Reject } source 0.0.0.0/0 translate-address disabled translate-port disabled vlans { connectivity } vlans-enabled }
The virtual created above will match on all traffic except TCP port 80, to capture that traffic we need to create a more specific virtual.
ltm virtual lvs_CaptivePortal_v4_80 { destination 0.0.0.0:http ip-protocol tcp mask any profiles { fastL4 { } } rules { Captive_Portal_Reject } source 0.0.0.0/0 translate-address disabled translate-port disabled vlans { connectivity } vlans-enabled }
This virtual is used to display the Captive Portal created earlier and should NOT be assigned to any vlan.
This example utilizes the SSL Forward Proxy functionality to display the prevent a certificate error from being displayed but is not required. For more information on SSL Forward Proxy see => Implmenting SSL Forward Proxy
ltm virtual v2v_CaptivePortal_v4 { destination 0.0.0.0:any ip-protocol tcp mask any profiles { clientssl_proxy { context clientside } http { } serverssl_proxy { context serverside } tcp { } } rules { Captive_Portal } source 0.0.0.0/0 translate-address disabled translate-port disabled vlans-enabled }
Does this work with Linux? Because the linux client is CLI based
And how about a real F5 package (or just the source) for linux like the one on windows with 2 factor auth. nowaday's there is more than windows alone. Lot's of professional security engineers use different operating systems than windows. this should not be that hard. The F5 product itself is linux based 🙂