One Time Passwords via an SMS Gateway with BIG-IP Access Policy Manager
One time passwords, or OTP, are used (as the name indicates) for a single session or transaction. The plus side is a more secure deployment, the downside is two-fold—first, most solutions involve a token system, which is costly in management, dollars, and complexity, and second, people are lousy at remembering things, so a delivery system for that OTP is necessary. The exercise in this tech tip is to employ BIG-IP APM to generate the OTP and pass it to the user via an SMS Gateway, eliminating the need for a token creating server/security appliance while reducing cost and complexity. Getting Started This guide was developed by F5er Per Boe utilizing the newly released BIG-IP version 10.2.1. The “-secure” option for the mcget command is new in this version and is required in one of the steps for this solution. Also, this solution uses the Clickatell SMS Gateway to deliver the OTPs. Their API is documented at http://www.clickatell.com/downloads/http/Clickatell_HTTP.pdf. Other gateway providers with a web-based API could easily be substituted. Also, there are steps at the tail end of this guide to utilize the BIG-IP’s built-in mail capabilities to email the OTP during testing in lieu of SMS. The process in delivering the OTP is shown in Figure 1. First a request is made to the BIG-IP APM. The policy is configured to authenticate the user’s phone number in Active Directory, and if successful, generate a OTP and pass along to the SMS via the HTTP API. The user will then use the OTP to enter into the form updated by APM before allowing the user through to the server resources. BIG-IP APM Configuration Before configuring the policy, an access profile needs to be created, as do a couple authentication servers. First, let’s look at the authentication servers Authentication Servers To create servers used by BIG-IP APM, navigate to Access Policy->AAA Servers and then click create. This profile is simple, supply your domain server, domain name, and admin username and password as shown in Figure 2. The other authentication server is for the SMS Gateway, and since it is an HTTP API we’re using, we need the HTTP type server as shown in Figure 3. Note that the hidden form values highlighted in red will come from your Clickatell account information. Also note that the form method is GET, the form action references the Clickatell API interface, and that the match type is set to look for a specific string. The Clickatell SMS Gateway expects the following format: https://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&password=xxxx&to=xxxx&text=xxxx Finally, successful logon detection value highlighted in red at the bottom of Figure 3 should be modified to response code returned from SMS Gateway. Now that the authentication servers are configured, let’s take a look at the access profile and create the policy. Access Profile & Policy Before we can create the policy, we need an access profile, shown below in Figure 4 with all default settings. Now that that is done, we click on Edit under the Access Policy column highlighted in red in Figure 5. The default policy is bare bones, or as some call it, empty. We’ll work our way through the objects, taking screen captures as we go and making notes as necessary. To add an object, just click the “+” sign after the Start flag. The first object we’ll add is a Logon Page as shown in Figure 6. No modifications are necessary here, so you can just click save. Next, we’ll configure the Active Directory authentication, so we’ll add an AD Auth object. Only setting here in Figure 7 is selecting the server we created earlier. Following the AD Auth object, we need to add an AD Query object on the AD Auth successful branch as shown in Figures 8 and 9. The server is selected in the properties tab, and then we create an expression in the branch rules tab. To create the expression, click change, and then select the Advanced tab. The expression used in this AD Query branch rule: expr { [mcget {session.ad.last.attr.mobile}] != "" } Next we add an iRule Event object to the AD Query OK branch that will generate the one time password and provide logging. Figure 10 Shows the iRule Event object configuration. The iRule referenced by this event is below. The logging is there for troubleshooting purposes, and should probably be disabled in production. 1: when ACCESS_POLICY_AGENT_EVENT { 2: expr srand([clock clicks]) 3: set otp [string range [format "%08d" [expr int(rand() * 1e9)]] 1 6 ] 4: set mail [ACCESS::session data get "session.ad.last.attr.mail"] 5: set mobile [ACCESS::session data get "session.ad.last.attr.mobile"] 6: set logstring mail,$mail,otp,$otp,mobile,$mobile 7: ACCESS::session data set session.user.otp.pw $otp 8: ACCESS::session data set session.user.otp.mobile $mobile 9: ACCESS::session data set session.user.otp.username [ACCESS::session data get "session.logon.last.username"] 10: log local0.alert "Event [ACCESS::policy agent_id] Log $logstring" 11: } 12: 13: when ACCESS_POLICY_COMPLETED { 14: log local0.alert "Result: [ACCESS::policy result]" 15: } On the fallback path of the iRule Event object, add a Variable Assign object as show in Figure 10b. Note that the first assignment should be set to secure as indicated in image with the [S]. The expressions in Figure 10b are: session.logon.last.password = expr { [mcget {session.user.otp.pw}]} session.logon.last.username = expr { [mcget {session.user.otp.mobile}]} On the fallback path of the AD Query object, add a Message Box object as shown in Figure 11 to alert the user if no mobile number is configured in Active Directory. On the fallback path of the Event OTP object, we need to add the HTTP Auth object. This is where the SMS Gateway we configured in the authentication server is referenced. It is shown in Figure 12. On the fallback path of the HTTP Auth object, we need to add a Message Box as shown in Figure 13 to communicate the error to the client. On the Successful branch of the HTTP Auth object, we need to add a Variable Assign object to store the username. A simple expression and a unique name for this variable object is all that is changed. This is shown in Figure 14. On the fallback branch of the Username Variable Assign object, we’ll configure the OTP Logon page, which requires a Logon Page object (shown in Figure 15). I haven’t mentioned it yet, but the name field of all these objects isn’t a required change, but adding information specific to the object helps with readability. On this form, only one entry field is required, the one time password, so the second password field (enabled by default) is set to none and the initial username field is changed to password. The Input field below is changed to reflect the type of logon to better queue the user. Finally, we’ll finish off with an Empty Action object where we’ll insert an expression to verify the OTP. The name is configured in properties and the expression in the branch rules, as shown in Figures 16 and 17. Again, you’ll want to click advanced on the branch rules to enter the expression. The expression used in the branch rules above is: expr { [mcget {session.user.otp.pw}] == [mcget -secure {session.logon.last.otp}] } Note again that the –secure option is only available in version 10.2.1 forward. Now that we’re done adding objects to the policy, one final step is to click on the Deny following the OK branch of the OTP Verify Empty Action object and change it from Deny to Allow. Figure 18 shows how it should look in the visual policy editor window. Now that the policy is completed, we can attach the access profile to the virtual server and test it out, as can be seen in Figures 19 and 20 below. Email Option If during testing you’d rather send emails than utilize the SMS Gateway, then configure your BIG-IP for mail support (Solution 3664), keep the Logging object, lose the HTTP Auth object, and configure the system with this script to listen for the messages sent to /var/log/ltm from the configured Logging object: #!/bin/bash while true do tail -n0 -f /var/log/ltm | while read line do var2=`echo $line | grep otp | awk -F'[,]' '{ print $2 }'` var3=`echo $line | grep otp | awk -F'[,]' '{ print $3 }'` var4=`echo $line | grep otp | awk -F'[,]' '{ print $4 }'` if [ "$var3" = "otp" -a -n "$var4" ]; then echo Sending pin $var4 to $var2 echo One Time Password is $var4 | mail -s $var4 $var2 fi done done The log messages look like this: Jan 26 13:37:24 local/bigip1 notice apd[4118]: 01490113:5: b94f603a: session.user.otp.log is mail,user1@home.local,otp,609819,mobile,12345678 The output from the script as configured looks like this: [root@bigip1:Active] config # ./otp_mail.sh Sending pin 239272 to user1@home.local Conclusion The BIG-IP APM is an incredibly powerful tool to add to the LTM toolbox. Whether using the mail system or an SMS gateway, you can take a bite out of your infrastructure complexity by using this solution to eliminate the need for a token management service. Many thanks again to F5er Per Boe for this excellent solution!
Why do you need a Diameter Routing Agent (DRA) in a VoLTE deployment?
This article was written by Peter Nas, Senior Solution Architect for the Traffix SDC Operators have begun to get more and more serious around deploying VoLTE (Voice over LTE) in their networks. Since the announcements of VoLTE services from some Korean and US operators, others, particularly in Asia, North America and EMEA, have launched or are about to launch VoLTE (see GSA announcement of 17th Sep 2014: 71 operators in 36 countries investing in VoLTE deployments, studies or trials, 10 operators commercially launched HD voice using VoLTE). More often than not, operators use a Diameter Routing Agent (DRA) to support correct routing and control of the Diameter signaling related to VoLTE. Basic session binding In 3GPP, a DRA is defined for session binding in IP-CAN sessions (equivalent to PDP context in 3G) towards a PCRF server. This was designed for multiple Diameter sessions in VoLTE in order to control the LTE and the IMS parts of the VoLTE service. To maintain an efficient and scalable network rollout, it is important that the LTE parts of an IMS VoLTE call, together with the IMS parts, are controlled by one and the same PCRF (server). Similarly, consistent policy rules need to be applied to the session that are related to the same VoLTE call. Let's explore in some more detail what needs to be managed by the same PCRF server and why. When using a VoLTE-enabled device, the mobile subscriber first needs to register to the network and establish the default data bearer to exchange data with the network or applications. This is followed by the authentication and authorization procedures, and mobility management communication between an MME and the HSS where the subscriber profile is stored. (Incidentally, the signaling for these procedures typically uses the Diameter S6a interface that is also often routed with help of a DRA). Now this device can establish the always-on LTE default user data bearer. In order to do so the device communicates with the PGW and establishes a user data session. For that user data session, in this case still the default bearer, the PGW needs to contact the PCRF via the Diameter Gx interface and receive the policy and charging rules for this customer's data session. Once the policies have been exchanged and applied by the PGW and sometimes there are other involved PCEFs (Policy and Charging Enforcement Function), the mobile user can either use Internet services via the established default bearer or in our scenario, opts to continue to establish a VoLTE call. To do so the VoLTE application on the handset will communicate (via SIP, over the established default LTE bearer) with the IMS network and its embedded VoLTE application server. First a SIP signaling bearer needs to be established after policy for that bearer is applied. To apply the policy, the IMS's P-CSCF needs to communicate via the Diameter Rx interface with a PCRF server. Actually, it needs to communicate with the same PCRF server that was already involved in managing the related LTE default bearer. This is exactly where the added-value of a DRA's session binding functionality becomes necessary, because the DRA has to search its memory for the same PCRF server that was used in the Gx session for that specific customer (e.g. specific IMSI and session ID). It has to match the unique and related information in the Rx signaling in order to make the same routing decision and end up at the same PCRF server. The relevant IMS information is the Framed-IP address because IMSIs are not usually required in IMS. A smart DRA has stored in its memory the association between an IMSI and Session-ID plus the Framed-IP address used by the device. If now that same Framed-IP address shows up in an IMS Diameter Rx message, a match can be made and the same routing decision can be applied. Now once the Diameter Gx for the LTE part and the Diameter Rx for the IMS part are bound to the same PCRF server we are almost there. Next comes the exchange and application of the policy and charging rules for the SIP Signaling bearer. And now we can move to the third key component of the VoLTE call and that is the SIP signaled voice. For voice signaling, the same PCRF server needs to be addressed, and the related IMS signaling is again exchanged via the Diameter Rx interface. Finally, once the policies and charging have been exchanged and applied, the VoLTE call can be made successfully. If there is a need for changing the policy or charging rules (for instance, if a customer reaches a certain threshold), than the same PCRF server can communicate via Gx to the LTE's PCEFs and via Rx to the involved IMS elements like the P-CSCF. In this way, the various sessions that are related to the same VoLTE service are managed consistently. Also when the VoLTE call is terminated the various sessions need to be released, except for the LTE default bearer, and the correlation between the LTE and IMS part of this VoLTE call can be cancelled. Other DRA added-value in VoLTE There’s additional value to the fundamental session binding functionality of a DRA. A DRA can enable optimal call management ensuring higher quality-of-service VoLTE calls. For instance, think of all the different vendors’ equipment that is needed to exchange Diameter Gx and Rx signaling. One example is when the LTE PGW has a different Gx implementation than the PCRF. In turn that PCRF can have a different Diameter Rx implementation than the IMS's P-CSCF node. Typically inside an operator's network, there will be various vendors for LTE, PCRF and IMS core network elements. And this is the norm in roaming use cases where the visited LTE network is out of control (meaning a different vendor) than the home IMS network, where the P-CSCF (and other elements) will be involved. In addition, once VoLTE takes off more substantially, the quantity of signaling also will take off and increase dramatically. Therefore, a DRA will play the most significant role in providing load balancing and overload control, both in normal circumstance but clearly also under special circumstances like when network elements went down and recover or other heavy signaling loads are occurring. A DRA could also prioritize VoLTE related signaling, over all the various Diameter interfaces. When serving this function, operators can provide a higher quality VoLTE service over other services, particularly when other services load the network. In this case, a network without this DRA functionality of prioritization, would experience degraded VoLTE service. There are more added-value functionalities – all made possible by a DRA, like VoLTE specific KPI generation. As time goes on and we experience increased use of VoLTE, we will learn more and more about how a DRA can improve the quality and efficiency of VoLTE and its related services. Peter Nas serves as Senior Solution Architect for the Traffix SDC team at F5 Networks and draws from more than 20 years of telecom experience to advise operators how to leverage Diameter signaling solutions to enable the optimal LTE experience. Peter joined F5 with the company’s acquisition of Traffix where he was responsible for global business development. Prior to joining Traffix, he worked at Tekelec focusing on market development for Diameter and SIP routing. In his days before Tekelec, he served as Core Network Engineering Manager at a prominent mobile operator in the Netherlands.The Top 10, Top Predictions for 2012
Around this time of year, almost everyone and their brother put out their annual predictions for the coming year. So instead of coming up with my own, I figured I’d simply regurgitate what many others are expecting to happen. Security Predictions 2012 & 2013 - The Emerging Security Threat – SANS talks Custom Malware, IPv6, ARM hacking and Social Media. Top 7 Cybersecurity Predictions for 2012 - From Stuxnet to Sony, a number of cyberattacks emerged in 2011 that experts have predicted for quite some time. Webroot’s top seven forecasts for the year ahead. Zero-day targets and smartphones are on this list. Top 8 Security Predictions for 2012 – Fortinet’s Security Predictions for 2012. Sponsored attacks and SCADA Under the Scope. Security Predictions for 2012 - With all of the crazy 2011 security breaches, exploits and notorious hacks, what can we expect for 2012? Websense looks at blended attacks, social media identity and SSL. Top 5 Security Predictions For 2012 – The escalating change in the threat landscape is something that drives the need for comprehensive security ever-forward. Firewalls and regulations in this one. Gartner Predicts 2012 – Special report addressing the continuing trend toward the reduction of control IT has over the forces that affect it. Cloud, mobile, data management and context-aware computing. 2012 Cyber Security Predictions – Predicts cybercriminals will use cyber-antics during the U.S. presidential election and will turn cell phones into ATMs. Top Nine Cyber Security Trends for 2012 – Imperva’s predictions for the top cyber security trends for 2012. DDoS, HTML 5 and social media. Internet Predictions for 2012 – QR codes and Flash TOP 15 Internet Marketing Predictions for 2012 – Mobile SEO, Social Media ROI and location based marketing. Certainly not an exhaustive list of all the various 2012 predictions including the doomsday and non-doomsday claims but a good swath of what the experts believe is coming. Wonder if anyone predicted that Targeted attacks increased four-fold in 2011. ps Technorati Tags: F5, cyber security, predictions, 2012, Pete Silva, security, mobile, vulnerabilities, crime, social media, hacks, the tube, internet, identity theft
RADIUS Load Balancing with iRules
What is RADIUS? “Remote Authentication Dial In User Service” or RADIUS is a very mature and widely implemented protocol for exchanging ”Triple A” or “Authentication, Authorization and Accounting” information. RADIUS is a relatively simple, transactional protocol. Clients, such as remote access server, FirePass, BIG-IP, etc. originate RADIUS requests (for example, to authenticate a user based on a user/password combination) and then wait for a response from the RADIUS server. Information is exchanged between a RADIUS client and server in the form of attributes. User-name, user-password, IP Address, port, and session state are all examples of attributes. Attributes can be in the format of text, string, IP address, integer or timestamp. Some attributes are variable in length, some are fixed. Why is protocol-specific support valuable? In typical UDP Load Balancing (not protocol-specific), there is one common challenge: if a client always sends requests with the same source port, packets will never be balanced across multiple servers. This behavior is the default for a UDP profile. To allow load balancing to work in this situation, using "Datagram LB" is the common recommendation or the use of an immediate session timeout. By using Datagram LB, every packet will be balanced. However, if a new request comes in before the reply for the previous request comes back from the server, BIG-IP LTM may change source port of that new request before forwards it to the server. This may result in an application not acting properly. In this later case, “Immediate timeout” must then be used. An additional virtual server may be needed for outbound traffic in order to route traffic back to the client. In short, to enable load balancing for RADIUS transaction-based traffic coming from the same source IP/source port, Datagram LB or immediate timeout should be employed. This configuration works in most cases. However, if the transaction requires more than 2 packets (1 request, 1 response), then, further BIG-IP LTM work is needed. An example where this is important occurs in RADIUS challenge/response handshakes, which require 4 packets: * Client ---- access-request ---> Server * Client <-- access-challenge --- Server * Client --- access-request ----> Server * Client <--- access-accept ----- Server For this traffic to succeed, all packets associated with the same transaction must be returned to the same server. In this case, custom layer 7 persistence is needed. iRules can provide the needed persistency. With iRules that understand the RADIUS protocol, BIG-IP LTM can direct traffic based on any attribute sent by client or persist sessions based on any attribute sent by client or server. Session management can then be moved to the BIG-IP, reducing server-side complexity. BIG-IP can provide almost unlimited intelligence in an iRule that can even re-calculate md5, modify usernames, detect realms, etc. BIG-IP LTM can also provide security at the application level of the RADIUS protocol, rejecting malformed traffic, denial of service attacks, or similar threats using customized iRules. Solution Datagram LB UDP profile or immediate timeout may be used if requests from client always use the same source IP/port. If immediate timeout is used, there should be an additional VIP for outbound traffic originated from server to client and also an appropriate SNAT (same IP as VIP). Identifier or some attributes can be used for Universal Inspection Engine (UIE) persistence. If immediate timeout/2-side-VIP technique are used, these should be used in conjunction with session command with "any" option. iRules 1) Here is a sample iRule which does nothing except decode and log some attribute information. This is a good example of the depth of fluency you can achieve via an iRule dealing with RADIUS. when RULE_INIT { array set ::attr_code2name { 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 29 Termination-Action 30 Called-Station-Id 31 Calling-Station-Id 32 NAS-Identifier 33 Proxy-State 34 Login-LAT-Service 35 Login-LAT-Node 36 Login-LAT-Group 37 Framed-AppleTalk-Link 38 Framed-AppleTalk-Network 39 Framed-AppleTalk-Zone 60 CHAP-Challenge 61 NAS-Port-Type 62 Port-Limit 63 Login-LAT-Port } } when CLIENT_ACCEPTED { binary scan [UDP::payload] cH2SH32cc code ident len auth \ attr_code1 attr_len1 log local0. "code = $code" log local0. "ident = $ident" log local0. "len = $len" log local0. "auth = $auth" set index 22 while { $index < $len } { set hsize [expr ( $attr_len1 - 2 ) * 2] switch $attr_code1 { 11 - 1 { binary scan [UDP::payload] @${index}a[expr $attr_len1 - 2]cc \ attr_value attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } 9 - 8 - 4 { binary scan [UDP::payload] @${index}a4cc rawip \ attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) =\ [IP::addr $rawip mask 255.255.255.255]" } 13 - 12 - 10 - 7 - 6 - 5 { binary scan [UDP::payload] @${index}Icc attr_value \ attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } default { binary scan [UDP::payload] @${index}H${hsize}cc \ attr_value attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } } set index [ expr $index + $attr_len1 ] set attr_len1 $attr_len2 set attr_code1 $attr_code2 } } when SERVER_DATA { binary scan [UDP::payload] cH2SH32cc code ident len auth \ attr_code1 attr_len1 log local0. "code = $code" log local0. "ident = $ident" log local0. "len = $len" log local0. "auth = $auth" set index 22 while { $index < $len } { set hsize [expr ( $attr_len1 - 2 ) * 2] switch $attr_code1 { 11 - 1 { binary scan [UDP::payload] @${index}a[expr $attr_len1 - 2]cc \ attr_value attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } 9 - 8 - 4 { binary scan [UDP::payload] @${index}a4cc rawip \ attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) =\ [IP::addr $rawip mask 255.255.255.255]" } 13 - 12 - 10 - 7 - 6 - 5 { binary scan [UDP::payload] @${index}Icc attr_value \ attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } default { binary scan [UDP::payload] @${index}H${hsize}cc \ attr_value attr_code2 attr_len2 log local0. " $::attr_code2name($attr_code1) = $attr_value" } } set index [ expr $index + $attr_len1 ] set attr_len1 $attr_len2 set attr_code1 $attr_code2 } } This iRule could be applied to many areas of interest where a particular value needs to be extracted. For example, the iRule could detect the value of specific attributes or realm and direct traffic based on that information. 2) This second iRule allows UDP Datagram LB to work with 2 factor authentication. Persistence in this iRule is based on "State" attribute (value = 24). Another great example of the kinds of things you can do with an iRule, and how deep you can truly dig into a protocol. when CLIENT_ACCEPTED { binary scan [UDP::payload] ccSH32cc code ident len auth \ attr_code1 attr_len1 set index 22 while { $index < $len } { set hsize [expr ( $attr_len1 - 2 ) * 2] binary scan [UDP::payload] @${index}H${hsize}cc attr_value \ attr_code2 attr_len2 # If it is State(24) attribute... if { $attr_code1 == 24 } { persist uie $attr_value 30 return } set index [ expr $index + $attr_len1 ] set attr_len1 $attr_len2 set attr_code1 $attr_code2 } } when SERVER_DATA { binary scan [UDP::payload] ccSH32cc code ident len auth \ attr_code1 attr_len1 # If it is Access-Challenge(11)... if { $code == 11 } { set index 22 while { $index < $len } { set hsize [expr ( $attr_len1 - 2 ) * 2] binary scan [UDP::payload] @${index}H${hsize}cc attr_value \ attr_code2 attr_len2 if { $attr_code1 == 24 } { persist add uie $attr_value 30 return } set index [ expr $index + $attr_len1 ] set attr_len1 $attr_len2 set attr_code1 $attr_code2 } } } Conclusion With iRules, BIG-IP can understand RADIUS packets and make intelligent decisions based on RADIUS protocol information. Additionally, it is also possible to manipulate RADIUS packets to meet nearly any application need. Contributed by: Nat Thirasuttakorn Get the Flash Player to see this player.BIG-IP Edge Client 2.0.2 for Android
Earlier this week F5 released our BIG-IP Edge Client for Android with support for the new Amazon Kindle Fire HD. You can grab it off Amazon instantly for your Android device. By supporting BIG-IP Edge Client on Kindle Fire products, F5 is helping businesses secure personal devices connecting to the corporate network, and helping end users be more productive so it’s perfect for BYOD deployments. The BIG-IP® Edge Client™ for all Android 4.x (Ice Cream Sandwich) or later devices secures and accelerates mobile device access to enterprise networks and applications using SSL VPN and optimization technologies. Access is provided as part of an enterprise deployment of F5 BIG-IP® Access Policy Manager™, Edge Gateway™, or FirePass™ SSL-VPN solutions. BIG-IP® Edge Client™ for all Android 4.x (Ice Cream Sandwich) Devices Features: Provides accelerated mobile access when used with F5 BIG-IP® Edge Gateway Automatically roams between networks to stay connected on the go Full Layer 3 network access to all your enterprise applications and files Supports multi-factor authentication with client certificate You can use a custom URL scheme to create Edge Client configurations, start and stop Edge Client BEFORE YOU DOWNLOAD OR USE THIS APPLICATION YOU MUST AGREE TO THE EULA HERE: http://www.f5.com/apps/android-help-portal/eula.html BEFORE YOU CONTACT F5 SUPPORT, PLEASE SEE: http://support.f5.com/kb/en-us/solutions/public/2000/600/sol2633.html If you have an iOS device, you can get the F5 BIG-IP Edge Client for Apple iOS which supports the iPhone, iPad and iPod Touch. We are also working on a Windows 8 client which will be ready for the Win8 general availability. ps Resources F5 BIG-IP Edge Client Samsung F5 BIG-IP Edge Client Rooted F5 BIG-IP Edge Client F5 BIG-IP Edge Portal for Apple iOS F5 BIG-IP Edge Client for Apple iOS F5 BIG-IP Edge apps for Android Securing iPhone and iPad Access to Corporate Web Applications – F5 Technical Brief Audio Tech Brief - Secure iPhone Access to Corporate Web Applications iDo Declare: iPhone with BIG-IP Technorati Tags: F5, infrastructure 2.0, integration, cloud connect, Pete Silva, security, business, education,technology, application delivery, ipad, cloud, context-aware,infrastructure 2.0, iPhone, web, internet, security,hardware, audio, whitepaper, apple, iTunes
F5 Synthesis: Software Defined Application Services
#SDN #Devops #Cloud #SDAS Completing the #SDDC stack Everything as a Service has become nearly a synonym for cloud computing. That's unsurprising, as the benefits of cloud - from economy of scale to increased service velocity - are derived mainly from the abstraction of network, compute and storage resources into services that can be rapidly provisioned, elastically scaled and intelligently orchestrated. We've come to use "Everything as a Service" and "Software Defined Data Center" nearly interchangeably, because the goal of both is really to drive toward IT as a Service. A world in which end-users (application owners and administrators) can provision, scale and orchestrate the resources necessary to deliver applications from app dev through devops to the network. This journey, in part, gave rise to SDN as a means to include the network in this new service-oriented data center. But SDN focused on only a subset of the network stack, leaving critical layer 4-7 services behind. Needless to say, such services are critical. Elastic scale is impossible without a combination of visibility and load balancing, after all, and a plethora of performance, security and even identity management focused services have become integral to modern data center architectures attempting to address pressures arising from trends like the Internet of Things, mobility, a steady stream of attacks, and an increasingly impatient consumer base. The problem of what to do about layer 4-7 services has been bandied about and given a lot of lip service, but no one really had a good solution - not one that integrated both with application (cloud and virtualization orchestration) and network orchestration solutions. Given F5's long-standing leadership in the realm of layer 4-7 services, we bent our heads together and found a solution. One that integrates and interoperates with SDN and compute orchestration solutions. One that applies SDN principles to application service networks. One that abstracts the application network resources necessary to deliver application services in a way that fills that gap between the network and compute orchestration layers. That solution is F5 Synthesis, and what it enables is Software Defined Application Services (SDAS). SDAS is the result of delivering highly flexible and programmatic application services from a unified, high-performance application service fabric. Orchestrated intelligently by BIG-IQ, SDAS can be provisioned and architected to solve significant pain points resulting from the whirling maelstrom of trends driving IT today. SDAS relies on abstraction; on the ability to take advantage of resources pooled from any combination of physical, virtual and cloud deployed F5 platforms. End-users are empowered to provision services instead of devices, and to leverage the visibility inherent in F5's full proxy-based platform approach. SDAS are highly flexible, owing to programmatic interfaces at not just the control (iControl, REST APIs) and data plane (iRules, node.js, Groovy) layers, but also at the configuration layer (iCall and iApps) to enable real-time, event-driven changes in behavior at the service level. SDAS is the next phase in the lengthy evolution of application delivery. As the approach to data centers becomes increasingly software-defined, so must the components that comprise the data center. That certainly must include the application service that have become so critical to ensuring the reliability, security and performance of the growing catalog of applications delivered to employees and consumers and, of course, "things" that make up the Internet today. Additional Resources: F5 Synthesis: The Time is RightHigh Performance Intrusion Prevention
Overview Utilizing the F5 BIG-IP ability to reliably load balance a high volume of concurrent connections to application services is further improved with integrations with IPS equipment providers. In this article I will articulate details pertaining to how the F5 BIG-IP along with the Cisco/Sourcefire Next Generation Intrusion Prevention System (NGIPS) managed device solutions can be utilized to provide a secure application delivery platform. This platform is secure and provides advanced client / server application monitored visibility. This solution is not limited to just utilizing Cisco/Sourcefire. It can also be extended to other IPS providers. This article will focus on the functional demonstration that we are presenting at the 2014 RSA Conference. The demo that was presented at the 2014 RSA conference is a functional demo. It does not stress the performance bounds of the joint solution. It is meant to demonstrate how the solution is built, monitored, and operated. Solution IPS deployments have limited bandwidth per sensor node. The traffic to be analyzed may require different sized IPS sensors depending on the traffic profiles. With BIG-IP these different traffic profiles can be sent to the properly sized IPS sensor. BIG-IP can also perform SSL offload. Be that as it may, the NGIPS will then inspect the traffic in the clear. Scale-out Flexibility Utilizing the BIG-IP Load Balancing capabilities, IPS inspection bandwidth can be increased by increasing the IPS Sensor node count within the load balanced pool. BIG-IP will load balance the traffic across all nodes within the pool. If sensors need to be serviced, they can be removed from the pool without affecting the end user. Multiple IPS Pools can be configured to address the varying bandwidth needs of your applications. Properly configured, the BIG-IP can selectively choose which traffic flows that will be sent to the IPS pool nodes for inspection. Configuration For the RSA conference we built a functional demonstration to load balance traffic to two Sourcefire NGIPS managed devices. The sensor receives the traffic using the BIG-IP Clone pool capabilities. As traffic patterns match IPS rules, and signatures. The Sourcefire Remediation API communicates to BIG-IP to enforce a denylist on the violating source IPs. To perform these tasks, BIG-IP uses two iRules. The first iRule is the Command iRule. And, the second is the Protection iRule. We will touch upon these aspects in the follow-on dialog. Demonstration Network Topology Overview Network Topologies The flexibility that BIG-IP provides for traffic steering and load balancing allows for multiple ways to deploy the sensors. The sensors can be deployed as transparent in-line devices, Load balanced through Gateway Pools, and Load Balanced as cloned traffic. Leveraging the excellent capabilities and strength of BIG-IP to perform SSL Offload can be implored with either of these deployment topologies. In-Line Transparent The in-line deployment places the NGIPS managed devices in between the BIG-IP and the application servers. We use an interim VLAN to pass the traffic through the NGIPS devices. Health monitoring transparent IPS sensors is challenging. By design these devices do not directly respond to pings or other direct unicasted packets. If a sensor goes offline the remaining sensors will carry on inspecting traffic. In-line Transparent Topology In-Line utilizing Gateway Pools An alternative way to deploy the sensors is to use Gateway Pools. Gateway Pools is a feature that allows traffic forwarding decisions to be performed through a pool of gateways (IP forwarding) devices. BIG-IP has nineteen different load balancing techniques that can be selected. The benefit this brings is that each gateway pool member can be health monitored. And, intelligent node selection based on concurrent connection and performance measurements. The network topology is similar to the in-line transparent setup with the addition of multiple NGIPS managed devices. Each of the NGIPS managed devices are configured with IP addresses. A virtual router is defined in order to address these sensors much in the same was as BIG-IP would forward traffic through a router. Using Clone Pools BIG-IP Clone Pool feature provides the ability to send a copy of traffic to a pool for inspection. The clone pool is directional in the sense the user can decide to just clone the client side traffic, server side traffic, or both. The NGIPS managed devices are on a side VLAN. The benefit this provides is the ability to apply the IPS inspection based on a per Virtual Server basis. This is the topology we chose to demonstrate at the RSA conference. Example Deployment Topology SSL Off-load assists with inspection BIG-IP has a huge capacity to perform SSL Offload. This is the ability for the BIG-IP to decrypt the SSL traffic from the clients in order for the NGIPS managed devices to see the un-encrypted traffic content. Many intrusion inspection devices are un-able to decrypt the SSL traffic, or the performance degradation of enabling SSL decryption severely impacts the overall application performance capabilities. All of the previously mentioned topologies can be deployed with SSL Offload as long as the BIG-IP is not re-encrypting the traffic to the server pools. If this is the case then a sandwich approach can be deployed. Detection and Enforcement IPS Blocking for in-line operation The NGIPS managed devices can be configured to block the offending traffic. This alone will not relieve the individual sensors from continuing to receive more violating traffic. However, the NGIPS signals the offending source IPs to the BIG-IP. The BIG-IP can perform the blocking enforcement on behalf of the intelligence that the NGIPS managed devices had detected. In turn the NGIPS is not burdened with the offensive traffic. Remediation API The Sourcefire NGIPS with Defense Center has a Remediation API that is used to signal the BIG-IP which sources to denylist. The remediation API is coupled with F5 iRule technology to handle the control communications and perform enforcement. The Defense Center communicates with a HTTP Request containing the offending source IP and a time out period. The time out period is the time before the offending source is allowed back in. iRule overview The iRules are utilized to perform both control and enforcement. The first iRule will receive source IP and timeout information from the Sourcefire Defense Center. This information is submitted into an internal data table. The second iRule will perform the enforcement to reject connection requests from the aforementioned source IPs. In turn time passes, and these clients can come back in to the playground. If they play nicely they are allowed to stay. Once, they violate the rule base. These source IPs will be reapplied and maintain an entry within our denylist table and continue to be rejected access. Command iRule The command iRule is applied to a Virtual Server that listens on the IPS VLAN. This virtual has no pool members associated to it. It’s there to catch the HTTP traffic from the Sourcefire Defense Center remediation API. The remediation API will send to the BIG-IP the offending Source IP and a configurable timeout period in seconds when a client trips an IPS rule. This iRule will also log to the ‘/var/log/ltm’ log file that the IP address has been added to the denylist table. when HTTP_REQUEST { if { [URI::query [HTTP::uri] "action"] equals "denylist" } { set blockingIP [URI::query [HTTP::uri] "sip"] set IPtimeout [URI::query [HTTP::uri] "timeout"] table add -subtable "denylist" $blockingIP 1 $IPtimeout HTTP::respond 200 content "$blockingIP added to denylist for $IPtimeout seconds" return } HTTP::respond 200 content "You need to include an ?action query" } Command iRule Enforcement iRule The enforcement iRule is applied to the Application Virtual Servers. The internal table of IP addresses that is maintained by the BIG-IP is queried when a new connection request is initiated. If the initiator is on the denylist the connection request is dropped. The iRule will also log to that the client attempted to access a protected Virtual Server. After sufficient time (timeout period provided by the Remediation API from above) has passed the source IP is removed from the table to allow new connections to be established. As mentioned before if the client trips a blocking rule it will again be rejected. when CLIENT_ACCEPTED { set srcip [IP::remote_addr] if { [table lookup -subtable "denylist" $srcip] != "" } { drop log local0. "Block IP on black list" return } } Enforcement and Protection iRule Management Interface This solution is managed and monitored with both the BIG-IP as well as the Sourcefire Defense Center. The Defense Center Content Explorer is a dashboard with a series of charts reporting traffic content details. BIG-IP Virtual Server and Pool statistics will report the traffic distribution of the NGIPS managed devices. Cisco / Sourcefire Defense Center These graphics are some screen shots of the Defense Center reporting. Context Explorer: Events over time Application Protocol distribution Client Application Information distribution F5 Dashboard: Sensor activity Traffic Overview Dashboard Web Application Traffic Risk BIG-IP Virtual Server and Pool Statistics BIG-IP Statistics show that the IPS Pools members are receiving the clone pool traffic. IPS Pool Statistics Virtual Server Statistics Conclusion Combining BIG-IP with Intrusion Prevention appliances is a very compelling solution. This demonstration was built utilizing the existing product feature sets of our currently released products. The demonstration is a functional representation to show how BIG-IP can load balance traffic to IPS sensors. The flexibility that both products provide, allows for improvements to the overall solution. The iRule code can be added to existing iRules. Utilizing the Sourcefire FireAMP features will extend this solution to also monitor for Malware. If a Server should become compromised Sourcefire will detect that from the Server Clone Pool traffic flows. Technorati Tags: IPS Cisco Sourcefire F5 iRule Security BIG-IP LiveJournal Tags: IPS Cisco Sourcefire F5 iRule Security BIG-IPS Cisco Sourcefire F5 iRule Security BIG-IPDNS The F5 Way: A Paradigm Shift
This is the second in a series of DNS articles that I'm writing. The first is: Let's Talk DNS on DevCentral. Internet users rely heavily on DNS, and when DNS breaks, applications break. It's extremely important to implement an architecture that provides for DNS availability at all times. It's important because the number of Internet users continues to grow. In fact, a recent study conducted by the International Telecommunications Union claims that mobile devices will outnumber the people living on this planet at some point this year (2014). I'm certainly contributing to those stats as I have a smartphone and a tablet! In addition, the sophistication and complexity of websites are increasing. Many sites today require hundreds of DNS requests just to load a single page. So, when you combine the number of Internet users with the complexity of modern sites, you can imagine that the number of DNS requests traversing your network is extremely large. Verisign's average daily DNS query load during the fourth quarter of 2012 was 77 billion with a peak of 123 billion. Wow...that's a lot of DNS requests...every day! The point is this...Internet use is growing, and the need for reliable DNS is more important than ever. par·a·digm noun \ˈper-ə-ˌdīm\: a group of ideas about how something should be done, made, or thought about Conventional DNS design goes something like this... Front end (secondary) DNS servers are load balanced behind a firewall, and these servers answer all the DNS queries from the outside world. The master (primary) DNS server is located in the datacenter and is hidden from the outside world behind an internal firewall. This architecture was adequate for a smaller Internet, but in today's complex network world, this design has significant limitations. Typical DNS servers can only handle up to 200,000 DNS queries per second per server. Using the conventional design, the only way to handle more requests is to add more servers. Let's say your organization is preparing for a major event (holiday shopping, for example) and you want to make sure all DNS requests are handled. You might be forced to purchase more DNS servers in order to handle the added load. These servers are expensive and take critical manpower to operate and maintain. You can start to see the scalability and cost issues that add up with this design. From a security perspective, there is often weak DDoS protection with a conventional design. Typically, DDoS protection relies on the network firewall, and this firewall can be a huge traffic bottleneck. Check out the following diagram that shows a representation of a conventional DNS deployment. It's time for a DNS architecture paradigm shift. Your organization requires it, and today's Internet demands it. F5 Introduces A New Way... The F5 Intelligent DNS Scale Reference Architecture is leaner, faster, and more secure than any conventional DNS architecture. Instead of adding more DNS servers to handle increased DNS request load, you can simply install the BIG-IP Global Traffic Manager (GTM) in your network’s DMZ and allow it to handle all external requests. The following diagram shows the simplicity and effectiveness of the F5 design. Notice that the infrastructure footprint of this design is significantly smaller. This smaller footprint reduces costs associated with additional servers, manpower, HVAC, facility space, etc. I mentioned the external request benefit of the BIG-IP GTM...here's how it works. The BIG-IP GTM uses F5's specifically designed DNS Express zone transfer feature and cluster multiprocessing (CMP) for exponential performance of query responses. DNS Express manages authoritative DNS queries by transferring zones to its own RAM, so it significantly improves query performance and response time. With DNS Express zone transfer and the high performance processing realized with CMP, the BIG-IP GTM can scale up to more than 10 million DNS query responses per second which means that even large surges of DNS requests (including malicious ones) will not likely disrupt your DNS infrastructure or affect the availability of your critical applications. The BIG-IP GTM is much more than an authoritative DNS server, though. Here are some of the key features and capabilities included in the BIG-IP GTM: ICSA certified network firewall -- you don't have to deploy DMZ firewalls any more...it IS your firewall! Monitors the health of app servers and intelligently routes traffic to the nearest data center using IP Geolocation Protects from DNS DDoS attacks using the integrated firewall services, scaling capabilities, and IP address intelligence Allows you to utilize benefits of cloud environment by flexibly deploying BIG-IP GTM Virtual Edition (VE) Supports DNSSEC with real-time signing and validates DNSSEC responses As you can see, the BIG-IP GTM is a workhorse that literally has no rival in today's market. It's time to change the way we think about DNS architecture deployments. So, utilize the F5 Intelligent DNS Scale Reference Architecture to improve web performance by reducing DNS latency, protect web properties and brand reputation by mitigating DNS DDoS attacks, reduce data center costs by consolidating DNS infrastructure, and route customers to the best performing components for optimal application and service delivery. Learn more about F5 Intelligent DNS Scale by visiting https://f5.com/solutions/architectures/intelligent-dns-scaleHow is SDN disrupting the way businesses develop technology?
You must have read so much about software-defined networking (SDN) by now that you probably think you know it inside and out. However, such a nascent industry is constantly evolving and there are always new aspects to discover and learn about. While much of the focus on SDN has focused on the technological benefits it brings, potential challenges are beginning to trouble some SDN watchers. While many businesses acknowledge that the benefits of SDN are too big to ignore, there are challenges to overcome, particularly with the cultural changes that it brings. In fact, according to attendees at the Open Networking Summit (ONS) recently the cultural changes required to embrace SDN outweigh the technological challenges. One example, outlined in this TechTarget piece, is that the (metaphorical) wall separating network operators and software developers needs to be torn down; network operators need coding skills and software developers will need to be able to program networking services into their applications. That’s because SDN represents a huge disruption to how organisations develop technology. With SDN, the speed of service provisioning is dramatically increased; provisioning networks becomes like setting up a VM... a few clicks of the button and you’re done. This centralised network provision means the networking element of development is no longer a bottleneck; it’s ready and available right when it’s needed. There’s another element to consider when it comes to SDN, tech development and its culture. Much of what drives software-defined networking is open source, and dealing with that is something many businesses may not have a lot of experience with. Using open source SDN technologies means a company will have to contribute something back to the community - that’s how open source works. But for some that may prove to be a bit of an issue: some SDN users such as banks or telecoms companies may feel protective of their technology and not want is source code to be released to the world. But that is the reality of the open source SDN market, so it is something companies will have to think carefully about. Are the benefits of SDN for tech development worth going down the open source route? That’s a question only the companies themselves can answer. Software-defined networking represents a huge disruption to the way businesses develop technology. It makes things faster, easier and more convenient during the process and from a management and scalability point of view going forward. There will be challenges - there always are when disruption is on the agenda - but if they can be overcome SDN could well usher in a new era of technological development.The Stealthy Ascendancy of JSON
While everyone was focused on cloud, JSON has slowly but surely been taking over the application development world It looks like the debate between XML and JSON may be coming to a close with JSON poised to take the title of preferred format for web applications. If you don’t consider these statistics to be impressive, consider that ProgrammableWeb indicated that its “own statistics on ProgrammableWeb show a significant increase in the number of JSON APIs over 2009/2010. During 2009 there were only 191 JSON APIs registered. So far in 2010 [August] there are already 223!” Today there are 1262 JSON APIs registered, which means a growth rate of 565% in the past eight months, nearly catching up to XML which currently lists 2162 APIs. At this rate, JSON will likely overtake XML as the preferred format by the end of 2011. This is significant to both infrastructure vendors and cloud computing providers alike, because it indicates a preference for a programmatic model that must be accounted for when developing services, particularly those in the PaaS (Platform as a Service) domain. PaaS has yet to grab developers mindshare and it may be that support for JSON will be one of the ways in which that mindshare is attracted. Consider the results of the “State of Web Development 2010” survey from Web Directions in which developers were asked about their cloud computing usage; only 22% responded in the affirmative to utilizing cloud computing. But of those 22% that do leverage cloud computing, the providers they use are telling: PaaS represents a mere 7.35% of developers use of cloud computing, with storage (Amazon S3) and IaaS (Infrastructure as a Service) garnering 26.89% of responses. Google App Engine is the dominant PaaS platform at the moment, most likely owing to the fact that it is primarily focused on JavaScript, UI, and other utility-style services as opposed to Azure’s middle-ware and definitely more enterprise-class focused services. SaaS, too, is failing to recognize the demand from developers and the growing ascendancy of JSON. Consider this exchange on the Salesforce.com forums regarding JSON. Come on salesforce lets get this done. We need to integrate, we need this [JSON]. If JSON continues its steady rise into ascendancy, PaaS and SaaS providers alike should be ready to support JSON-style integration as its growth pattern indicates it is not going away, but is instead picking up steam. Providers able to support JSON for PaaS and SaaS will have a competitive advantage over those that do not, especially as they vie for the hearts and minds of developers which are, after all, their core constituency. THE IMPACT What the steady rise of JSON should trigger for providers and vendors alike is a need to support JSON as the means by which services are integrated, invoked, and data exchanged. Application delivery, service-providers and Infrastructure 2.0 focused solutions need to provide APIs that are JSON compatible and which are capable of handling the format to provide core infrastructure services such as firewalling and data scrubbing duties. The increasing use of JSON-based APIs to integrate with external, third-party services continues to grow and the demand for enterprise-class service to support JSON as well will continue to rise. There are drawbacks, and this steady movement toward JSON has in some cases a profound impact on the infrastructure and architectural choices made by IT organizations, especially in terms of providing for consistency of services across what is likely a very mixed-format environment. Identity and access management and security services may not be prepared to handle JSON APIs nor provide the same services as it has for XML, which through long established usage and efforts comes with its own set of standards. Including social networking “streams” in applications and web-sites is now as common as including images, but changes to APIs may make basic security chores difficult. Consider that Twitter – very quietly – has moved to supporting JSON only for its Streaming API. Organizations that were, as well they should, scrubbing such streams to prevent both embarrassing as well as malicious code from being integrated unknowingly into their sites, may have suddenly found that infrastructure providing such services no longer worked: API providers and developers are making their choice quite clear when it comes to choosing between XML and JSON. A nearly unanimous choice seems to be JSON. Several API providers, including Twitter, have either stopped supporting the XML format or are even introducing newer versions of their API with only JSON support. In our ProgrammableWeb API directory, JSON seems to be the winner. A couple of items are of interest this week in the XML versus JSON debate. We had earlier reported that come early December, Twitter plans to stop support for XML in its Streaming API. --JSON Continues its Winning Streak Over XML, ProgrammableWeb (Dec 2010) Similarly, caching and acceleration services may be confused by a change from XML to JSON; from a format that was well-understood and for which solutions were enabled with parsing capabilities to one that is not. IT’S THE DATA, NOT the API The fight between JSON and XML is one we continue to see in a general sense. See, it isn’t necessarily the API that matters, in the end, but the data format (the semantics) used to exchange that data which matters. XML is considered unstructured, though in practice it’s far more structured than JSON in the sense that there are meta-data standards for XML that constrain security, identity, and even application formats. JSON, however, although having been included natively in ECMA v5 (JSON data interchange format gets ECMA standards blessing) has very few standards aside from those imposed by frameworks and toolkits such as JQuery. This will make it challenging for infrastructure vendors to support services targeting application data – data scrubbing, web application firewall, IDS, IPS, caching, advanced routing – to continue to effectively deliver such applications without recognizing JSON as an option. The API has become little more than a set of URIs and nearly all infrastructure directly related to application delivery is more than capable of handling them. It is the data, however, that presents a challenge and which makes the developers’ choice of formats so important in the big picture. It isn’t just the application and integration that is impacted, it’s the entire infrastructure and architecture that must adapt to support the data format. The World Doesn’t Care About APIs – but it does care about the data, about the model. Right now, it appears that model is more than likely going to be presented in a JSON-encoded format. JSON data interchange format gets ECMA standards blessing JSON Continues its Winning Streak Over XML JSON versus XML: Your Choice Matters More Than You Think I am in your HTTP headers, attacking your application The Web 2.0 API: From collaborating to compromised Would you risk $31,000 for milliseconds of application response time? Stop brute force listing of HTTP OPTIONS with network-side scripting The New Distribution of The 3-Tiered Architecture Changes Everything Are You Scrubbing the Twitter Stream on Your Web Site?
