F5 Access Policy Manager and Firefox Browser version 43 and 47+
Firefox Browser version 43 has new plug-in signing requirements. F5 will be providing Engineering Hotfixes for BIG-IP versions 12.0.0, 11.6.0, and 11.5.3, which will include a F5 Access Policy Manager plug-in signed by Firefox for Microsoft Windows and Linux platforms. With F5 officially supporting Firefox version 34, this is a “best efforts” approach to alleviate any disruptions brought about by Firefox version 43 and the upcoming Firefox version 44, related to plug-in signing requirements (Feature Enhancement ID:564253). If issues are uncovered with versions of Firefox greater than version 34 after installing the appropriate Engineering Hotfix, it is recommended that users be guided to use Microsoft Internet Explorer on Windows, and Safari on Mac, as detailed in thisDevCentral post. Another option is to use BIG-IP Edge Client for these two platforms. For Linux, there is a CLI client available for network access. These Engineering Hotfix releases are short-term fixes. A more permanent solution will be available in an upcoming release of BIG-IP; specifics will also be available in the aforementioned DevCentral post. We will make the Engineering hotfixes available for customers who create a support case with F5 Support. This Engineering Hotfix should be good for up to Firefox 46 and F5 will need to have Mozilla sign the plug-in again for Firefox 47+. This is just how Firefox plug-in signing works currently. January 7, 2016 Update: While we (F5) is making progress in getting the Engineering hotfixes out, we are currently working through some issues seen with the Mozzilla add-on submission tool. Once that is resolved, then we expect to be able to provide an ETA for the Engineering Hotifxes. F5 is working on this with urgency. January 8, 2016 Update: We (F5) have the issue with the Mozilla add-on tools resolved, so we can provide a target ETA of January 15, 2016 (Friday) to provide Engineering Hotfixes for the 3 versions of BIG-IP we had mentioned on this post. January 14, 2016 Update: We have run into a few issues that need to be addressed so we will need a few more days to have the Engineering Hotfixes available. Again,F5 is working on this with urgency. January 21, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.6.0, based on BIG-IP 11.6.0 Hotfix 6 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 12.0.0 and 11.5.3 soon. January 25, 2016 Update: We have an Engineering Hotfix for BIG-IP 12.0.0 based on BIG-IP 12.0.0 Hotfix 1 now. Again to get it, customers should create a support case with F5 Support. We are still planning to provide an Engineering Hotfix forBIG-IP 11.5.3 soon. January 26, 2016 Update: We have an Engineering Hotfix for BIG-IP 11.5.3 based on BIG-IP 11.5.3 Hotfix 2. Customers should create a support case with F5 Support. F5 will target to release Engineering Hotfixes before Firefox 47 is available. May 9, 2016 Update: F5 is currently working on Engineering Hotfixes for the various BIG-IP for Firefox 47+ that would work for all Firefox versions (even Firefox 46 and earlier). Mozilla is allowing for plug-in signing for all (*) versions of Firefox again. We do not have the releases ready for customers yet but expect to have it shortly. Once they are available, we will announce it here and also provide it initially to F5 Support and thus customers can get it via a Support ticket. Shortly after it is available via F5 Support, we will provide it on https://downloads.f5.com. May 16, 2016 Update: F5 has Engineering Hotfixes for 11.5.4 HF1 and 11.6.0 HF6 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for12.0.0 HF2 and 11.6.1. May 21, 2016 Update: F5 has Engineering Hotfix for 12.0.0 HF2 available. These should work with all versions* of Firefox (including Firefox 47 Beta builds). For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. We will provide it on https://downloads.f5.com shortly and we are also working on Engineering Hotfixes for11.6.1 and 12.1.0. May 31, 2016 Update:F5 has Engineering Hotfix for 11.6.1 available. For now, customers should create a support ticket with F5 Support to get the Engineering Hotfixes. *These Engineering Hotfixes should work on all versions of Firefox, including 47+, until Firefox removes its NPAPI support. To address that we have another DevCentral post: here:https://devcentral.f5.com/s/articles/addressing-security-loopholes-of-third-party-browser-plug-ins
Dyre Malware Analysis
Dyre, also known as Dyreza, is a banking Trojan that was first seen around June 2014. With the combination of its ability to steal login credentials by browser hooking and bypassing SSL, its man-in-the-middle (MITM) proxy server, and its Remote Access Trojan (RAT) capabilities, Dyre has become one of the most dangerous banking Trojans. The Dyre Trojan is designed to steal login credentials by grabbing the whole HTTPS POST packet, which contains the login credentials sent to a server during the authentication process, and forwarding it to its own server. The malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup windows, and JavaScript/HTML injections. After all the information has been acquired by the attacker, he can remotely access the victim’s computer using a built-in VNC (Virtual Network Computing) module and perform transactions, data exfiltration, and more. How it works malware downloads a configuration file containing a list of targeted bank URLs. Each URL is configured to be redirected to Dyre’s MITM proxy server, on a different port for each bank. This allows the attacker to make a MITM attack by forwarding any user request to the bank and returning bogus data, including fake login pages, popup Malware behavior on a Win7-32bit system Surprisingly, the malware behaves differently on Win7-32bit, most likely due to security implementation differences. The method of registering itself as a system service is implemented on WinXP and 64bit systems (tested on Win7-64bit). On Win7-32bit, Dyre operates more similarly to the known Zeus malware by injecting code in the Explorer.exe process and operating from there. Man-In-The-Middle (MITM) Attack When a user enters his bank’s URL in the browser line, the Trojan is triggered and forwards the URL to the corresponding proxy server as stated in its configuration file. · The MITM proxy server forwards requests to the banks and disguises itself as the real user. · The returning response from the bank is intercepted by the proxy server. · Instead of the real response, the user receives a fake login page which is stored on the proxy server, and contains scripts and resources from the real bank’s page. The scripts and resources are stored in folders named after the unique port configured for each bank. · The information entered by the user is sent to the proxy server and then forwarded to the real bank server, allowing the attacker to log in instead of the user and perform operations on his behalf. The fake login page The fake page contains a script called main_new - , which is responsible for handling the objects presented to the user on the fake page and performing the MITM attack. The fake page contains an array of configuration parameters in the header. Some of the more interesting ones are: · ID. The unique identification of the bank, which is the same as the port number in the configuration file. · Incorrect login error. On each login attempt to the bank, the proxy server will forward the request to the real bank’s server and perform the authentication. If the authentication fails, it will also present an error to the user on the fake page. · Block message. If the MITM attack succeeds, the attacker is able to perform a transaction and block the user from accessing his account. This parameter stores the presented message. The F5 Solution Real-time identification of affected users - F5 WebSafe and MobileSafe are able to detect the user is affected by a Trojan and that the information provided by it to the customer is also sent to an unauthorized drop zone. Identification of malicious script injection – once downloaded to the client’s browser, WebSafe and MobileSafe make sure there has been no change to the site’s HTML. If such a change is detected, the customer is notified immediately. Protection against Trojan-generated money transfers - the combination of recognizing affected users, encrypting information, and recognizing malicious scripts is key to disabling Trojans from performing unauthorized actions within the account. WebSafe and MobileSafe detect the automatic attempts and intercept them. Malware research - F5 has a dedicated Trojan and malware R&D team that searches for new threats and new versions of existing ones. The team analyzes the programming techniques and methodologies used to develop the malware in order to keep the F5 line of products up to date and effective against any threat. To get the full technical detailed Malware analysis report click here. To download the executive summary, click here.
How 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.
Implementing PCoIP Proxy as a Security Server or Access Point Alternative
VMware’s Horizon Security Server and Access Point provides secure access to sessions over an unsecured WAN and/or Internet connection. Typically, the Security Server/Access Point is placed within an organization’s DMZ and proxies connections to internal Horizon desktop and application resources. F5 BIG-IP Access Policy Manager (APM) provides an alternative method for secure access to Horizon desktop and application resources by simplifying your VMware Horizon with View architecture, improving security, and increasing scalability. Harden Security and Increase Scalability F5 BIG-IP Access Policy Manager is the industry’s first Application Delivery Networking solution that brings full PCoIP proxy capabilities—certified by Teradici—to the market. This permits IT administrators to replace the View Security Server with a more secure and highly scalable solution in support of their end-user computing deployments. BIG-IP APM is an ICSA Labs–certified flexible, high-performance access and security solution that provides unified global access to your applications and network. BIG-IP APM converges and consolidates remote access, LAN access, and wireless connections within a single management interface and provides easy-to-manage access policies. These capabilities help you free up valuable IT resources and scale cost-effectively. Simplifying Your Horizon Architecture Because BIG-IP APM removes the pairing dependency between Security Servers and Connection Servers, the overall architecture can not only be simplified, but a higher level of scalability can be achieved. In addition to BIG-IP APM, F5 BIG-IP Local Traffic Manager (LTM) can provide intelligent traffic management and load balancing to the Connection Servers. The reduction in the overall number of components that need to be managed results in increased productivity for IT administrators, which is especially critical for multi-site or multi-pod VMware Horizon deployments. Traffic Flow The diagram outlines the traffic flow of an external Horizon Client connection when using the BIG-IP Access Policy Manager (APM) Module as a Security Server/Access Point alternative: Device connects in from the untrusted network. Connection to APM made over HTTPS using the client or the F5 APM WebTop Portal. User logs in. APM processes the authentication (single/multi-factor) to AD and/or other authentication source (LDAPS/RADIUS, etc.) Once user is validated, APM sends a request to the load balanced pool of Connection Servers to get a list of authorized applications and desktops using HTTPS or HTTP. The user is then presented with the list of available and authorized desktops and applications. User selects the application or desktop to launch. Request then sent from client and proxied to View Connection Server via HTTPS – client receives desktop and/or application source machine info (including the public/client facing IP address if using NAT). Client establishes a connection to the virtual desktop or RDS application server to the APM via PCoIP, or HTML 5 (using HTML Access) using HTTPS . The APM proxies this connection back to the virtual desktop or RDS application server. We've developed a step-by-step guide for implementing PCoIP Proxy, which you can download here. You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.
Need an ISO8583 Application Switch for card transactions?
What is ISO8583: ISO 8583 Financial transaction card originated messages — Interchange message specifications is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. The first two digits in the ISO8583 message aren't important. However, the next four are what tell us about the type of message we are processing. For more information: http://en.wikipedia.org/wiki/ISO_8583 Using the rule below as a template you should be able to dynamically switch any ISO8583 message to the desired server. See if this helps: when CLIENT_ACCEPTED{ TCP::collect } This section collects the first 6 bytes and then uses 'switch' to find a match. It allows to you decide where to send a request based on its message type. You could also use this to simply log without performing a pool selection. when CLIENT_DATA { log local0. "in CLIENT_DATA" set clientData [TCP::payload 6] log local0. "Client Data raw: $clientData" switch -glob $clientData{ "??0800"{ pool pool_EchoTestMessage log local0. "This is a Network Management Message." } "??0810"{pool pool_ForClientAuthorizations} } TCP::release } when SERVER_CONNECTED { TCP::collect } This section allows you to perform an action base on the message type of the response from the server. You could log the message type or even manipulate it before sending it out. when SERVER_DATA{ set serverData [TCP::payload 6] log local0. "Response Data raw: $serverData" switch -glob $serverData{ "??0810"{ log local0. "This is a Network Management Message." } "??0820"{log local0. "This is type XXX" } } TCP::release }Getting Around the Logon/Legal Banner Issues when using APM PCoIP Proxy and Horizon
If you're using APM's PCoIP Proxy and require a logon banner, you've probably figured out that the PCoIP Proxy integration stops working when you turn on the integrated logon banner from within the Horizon Administrator. Adding to the pain, internal users can't get any logon banner since you had to turn it off in order for your external access to work! Well, the wait is over! With the use of a nifty iRule that you can attach to your internal Horizon Connection Servers virtual server, you can now present a banner BOTH internal users as well as external users who access Horizon resources using APM PCoIP Proxy. Here's how it works: Disable the logon banner through Horizon Administrator - the BIG-IP will handle presenting the banners for internal users (through the iRule) and external users (through the View iApp) instead of Horizon. Modify the text in the iRule with the text you want to show in the logon banner. Apply the iRule to your LTM Virtual Server that services internal Horizon users (either manually to the LTM virtual server or through the View iApp). You're done! A couple of things to think about when you implement this: If you need to present a legal disclaimer your external users using the PCoIP Proxy, you can still do that through the Horizon View iApp. Do not apply this to any virtual server running the APM PCoIP Proxy - it's only for providing the logon banner to internal Horizon users. The banner for PCoIP Proxy can be easily enabled through the iApp It's important to ensure the PCoIP Proxy's Connection Server settings are pointing to the individual connection server(s) and NOT the LTM virtual server that has the Logon Banner iRule applied. The iRule source is below. # Attach iRule to iApp created virtual server named "<iapp_name>_internal_https" # Replace the section “This is a XXX computer system that is FOR OFFICIAL USE ONLY. This # system is subject to monitoring. Therefore, no expectation of privacy is to be assumed. # Individuals found performing unauthorized activities are subject to disciplinary action # including criminal prosecution.” with your desired text. when RULE_INIT { # Debug Level 0=off, 1=on, 2=verbose set static::internal_disclaimer_debug 0 } when CLIENT_ACCEPTED { set log_prefix_cs "[IP::remote_addr]:[TCP::remote_port clientside] <-> [IP::local_addr]:[TCP::local_port clientside]" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: CLIENT_ACCEPTED" } } when HTTP_REQUEST { set bypass 0 if {[HTTP::uri] starts_with "/portal/info.jsp"} { if { $static::internal_disclaimer_debug > 0 } { log local0. "<$log_prefix_cs>: Portal Info request, bypassing further processing"} set bypass 1 } else { if {[HTTP::header exists "Content-Length"]} { set content_length [HTTP::header "Content-Length"] } else { # If the header is missing, use a sufficiently large number set content_length 5000 } if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Set content-length to $content_length"} HTTP::collect $content_length if { [HTTP::path] == "/broker/xml" && [HTTP::header Expect] == "100-continue" } { SSL::respond "HTTP/1.0 100 Continue\r\n\r\n" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Application requested: client requires 100 continue response, sending 100-continue"} } } } when HTTP_REQUEST_DATA { if { [HTTP::payload] contains "set-locale" and ( not ($bypass)) } { HTTP::respond 200 content {<?xml version="1.0"?><broker version="9.0"><configuration><result>ok</result><broker-guid>aaaaaaaa-bbbb-cccc-ddddddddddddddddd</broker-guid><authentication><screen><name>disclaimer</name><params><param><name>text</name><values><value>This is a XXX computer system that is FOR OFFICIAL USE ONLY. This system is subject to monitoring. Therefore, no expectation of privacy is to be assumed. Individuals found performing unauthorized activities are subject to disciplinary action including criminal prosecution.</value></values></param></params></screen></authentication></configuration><set-locale><result>ok</result></set-locale></broker>} noserver "Connection" "close" "Content-Type" "text/xml;charset=UTF-8" if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Sending Disclaimer Message"} } if { [HTTP::payload] contains "disclaimer" } { if { $static::internal_disclaimer_debug > 1 } { log local0. "<$log_prefix_cs>: Disclaimer Message Accepted - waiting for credentials."} } } This solution has been tested using Horizon 6.0 (and later) as well as the Horizon 3.0 (and later) Client. Earlier versions of the client and/or Horizon Connection Server could produce unexpected results. Big shout-out to Greg Crosby for his work on the iRule!Load Balancing VMware's Workspace Portal/Identity Manager with F5 BIG-IP Local Traffic Manager (LTM)
What is VMware Identity Manager (formerly known as VMware Workspace Portal)? VMware Identity Manager is a service that extends your on-premises directory infrastructure to provide a seamless Single Sign-On (SSO) experience to Web, Mobile, SaaS, and legacy applications. Simply put, it's a service aggregator and identity provider for your IT resources. One single login to Identity Manager gains you access to Citrix XenApp, Horizon, Web, SaaS, and ThinApp resources. You can find more about Identity Manager at https://www.vmware.com/products/identity-manager/. BIG-IP can provide intelligent traffic management, high availability and monitoring through the use of BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS (Global Traffic Management). BIG-IP's Access Policy Manager (APM) can also provide secure access to the apps and resources accessible through the Identity Manager portal as well as the actual Identity Manager portal itself. In this article, we'll focus on building a highly available Identity Manager implementation using BIG-IP LTM. You can download the updated step-by-step load-balancing guide for VMware Workspace Portal/Identity Manager here. What's also cool is you can do a walk through of this very setup in the VMware Hands-On-Lab at VMworld 2015 (Look for HOL-MBL-1659) or by clicking the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078. Special thanks to Bryan Salek, Matt Mabis, and Mosa Emamjomeh for helping put this together! Stay tuned for a future post on how to securely access Workspace Portal/Identity Manager using BIG-IP Access Policy Manager (APM), which includes proxying Citrix XenApp, Horizon, and Web Application resources. WorkspaceOne/Identity Manager 2.6 Update: When changing the FQDN of VMware Identity Manager there is an additional (and new) stepthat needs to be done.After changing the FQDN, log back into the Workspace One Admin UI using a local account and clickCatalog --> Settings. Next, selectNew End User Portal UIand clickEnable New Portal UI. Once completed, log out and you should now be able to login using a domain account.
F5 Anti-Fraud Solutions: Frictionless Protection for the Masses
Anti-Fraud Solutions: Why F5? In 2013, F5 Networks grew its security portfolio to include advanced Anti-Fraud services with the acquisition of the Israeli-based security company Versafe. At the RSA Conference in San Francisco this week, we have a section of our F5 booth dedicated to the Anti-Fraud solution where we are talking about the technology, answering questions and demonstrating the capabilities all week. If you cannot make it to the conference or even if you attended but missed us at our booth, that’s not a problem. I’ll fill you in on some of the details. First, just walking around the RSA Conference, it’s clear that there is no shortage of anti-fraud solutions on the market. The number is mind blowing and continuously growing. As new threats emerge, new technologies are introduced to combat them. But if you look at the approaches each company takes, they are often quite different. So that begs the question: why F5? Well, from a feature and function standpoint, we cover a wide range of web-based fraud detection and protection capabilities. The WebSafe solution, which protects web-based applications, safeguards against various forms of malicious activity including phishing attacks, Man-In-The-Middle, Man-In-The-Browser and Trojan activity such as web injections, form hijacking, page modifications and transaction modification. But what makes the solution unique is that it enables 100% coverage of the user base in a completely clientless manner, without impacting the user experience. We inject our obfuscated code via an iRule, into the web application code as part of the response data. In other words, the solution is completely frictionless, which is key differentiator number one. And because the solution leverages common browser-based technologies, we protect users who are navigating from all types of devices: laptops, PCs, tablets, smart TVs, mobile devices, etc. As long as the user is navigating with a standard web browser, they will be protected. This is key differentiator number two. From a deployment standpoint, today the WebSafe solution is implemented via an iRule on an F5 device (either physical or virtual), so there is no need to introduce changes to the web applications our customers are looking to protect from online fraud. This saves time when deploying the solution because there is no need to engage web development resources which are often outsourced or already engaged in critical projects. Our ability to deploy without these web application changes equates to savings and is key value proposition number three. As a matter of fact, many F5 customers can leverage their current F5 investment and deploy the Anti-Fraud services on their existing infrastructure, requiring no additional hardware investment: differentiator number four. Lastly, WebSafe provides protection against online fraud without a client install and with no change in the online users’ experience. Introducing CAPTCHAs, popups, etc is often too intrusive to the end user, so we are looking to protect the users without introducing friction in the process. Summary If you are at the RSA Conference, stop by booth 1801. We would be happy to demonstrate our Anti-Fraud solution and help to enhance your fraud protection capabilities. If you are not at RSA, look for further details here. We will be posting more details about F5’s Anti-Fraud solutions throughout the coming weeks.Managing Horizon Traffic across Multiple Data Centers with BIG-IP DNS
In a typical single data center environment, VMware Horizon virtual desktop clients typically use a fully qualified domain name (FQDN) when accessing desktop and application resources. More and more customers are distributing their Horizon application and desktop infrastructure to distribute across multiple physical/logical data centers. Some of the business and technical reasons may include disaster recovery, system resiliency, and elastic desktop/application capacity. How are these multi-data center implementations of Horizon accessed? One common scenario is to provide a specific domain name to users either based on a user’s geographical location (for example, https://europe.example.com) or a user’s business unit (for example, https://finance.example.com). If the user has an ability to access resources from multiple data centers, the user’s overall experience might be sub-optimal if the end user is not being connected to the most appropriate, optimal data center. By deploying BIG-IP DNS (formerly Global Traffic Manager) with Horizon View, a single namespace (for example, https://desktop.example.com) can be provided to all end users - one URL to remember. BIG-IP DNS and BIG-IP Local Traffic Manager (LTM) also work together to ensure that requests are intelligently routed to a preferred data center, regardless of the user’s current location. In this example, users leverage a single namespace (view-apoc.bd.f5.com). They will initially connect to BIG-IP DNS (GTM). BIG-IP DNS will make a routing decision (based on availability, topology, connection, etc.) and then send the user to a specific data center. The user will then login with the Horizon View client and access their desktop/applications. If a data center is inaccessible, new users are automatically routed to the available data center; existing users will be disconnected and then reconnect to the live data center. Taking advantage of these key BIG-IP modules (BIG-IP DNS and LTM) empowers IT staff to integrate multiple VMware Horizon pods or physical sites for source desktops, all without disrupting users. By enabling users to reconnect to their existing persistent desktop source when required and providing a dynamic and agile infrastructure that can adapt to planned and unplanned events, the BIG-IP system becomes key to successful VMware Horizon deployments. We've developed a step-by-step guide for implementing BIG-IP DNS across two (or more) data centers using BIG-IP DNS and BIG-IP Local Traffic Manager, which you can download here . You can also do a walk through of this very setup in the VMware Hands-On-Lab (Look for HOL-MBL-1659) by clicking on the following link - http://labs.hol.vmware.com/HOL/catalogs/lab/2078.ISO8583 payload interpreter/switch
The previous verion of ISO8583 switch only processed the MTI (Message Type Identifier). This version goes far beyond and dives into the bitmap and payload. What does it do: 1) It reads and interprets the ISO8583 bitmap 2) It calculate the offset based on the fields present in the message With these two points we now have access to the message payload allowing one to pick out client identifier or location information (bits 41 & 42) or anything else you want access to. This information can be used for simple logging, routing or anything else you might be after. The following rule grabs field 63. Being a variable length field, it must retrieve the field length from within the payload before being able to locate the desired field data. when RULE_INIT { Build list of Bitmap Attribute Lengths 'var' represents a variable length field set static::bmAttrLengths [list 64 LL 6 12 12 12 10 8 8 8 6 6 4 4 4 4 4 4 3 3 3 3 3 3 2 2 1 8 8 8 8 LL LL LL LL LLL 12 6 2 3 8 15 40 LL LL LLL LLL LLL 3 3 3 64 16 LLL LLL LLL 12 12 12 LLL LLL LLL LLL 64] } when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { set clientData [TCP::payload] log local0. "Client Data raw: $clientData" Collect the bitmap from the payload - it follows the MTI. binary scan [binary format H* [string range $clientData 6 21]] B* data Start the offset at 22 for MTA & BitMap padding set offset 22 set i 0 while { $i < [string length $data]} { if {[string index $data $i] == 1} { set attr [lindex $static::bmAttrLengths $i] if { $attr == "LL" } { This is a variable length field. The next 2 values in the string tell us how long the field is. set beginData [expr { $offset + 2 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 1 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 1 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } elseif { $attr == "LLL" } { This is a variable length field. The next 3 values in the string tell us how long the field is. set beginData [expr { $offset + 3 }] set endData [expr { $beginData + [scan [string range $clientData $offset [expr { $offset + 2 }]] %d ]}] log local0. "Value for the field length is: [string range $clientData $offset [expr { $offset + 2 }]]" log local0. "Value for the Field is: [string range $clientData $beginData $endData]" } else { We got a 1 in the bitmap - increment the offset. incr offset [lindex $static::bmAttrLengths $i] } } incr i } TCP::release } Tester feedback welcom and encourage - I only have access to an ISO8583 emulator written in python.
