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 }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.
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.
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.
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-insFive Information Security New Year's Resolutions
Shot this late last year for Information Security Buzz. What are five information security new year's resolutions for improving cyber security in 2016 and why? ps Related: New Year's Resolutions for the Security Minded Blueprint: 2016 is the Year SDN Finds its Home, and its Name is NFV 10 Cloud Security Predictions for 2016 2016 security predictions: Partnerships, encryption and behavior tracking Technorati Tags: 2016,resolutions,security,infosec,silva,f5 Connect with Peter: Connect with F5:
A New Twist on DNS NXDOMAIN DDoS
DDoS attacks are increasing in scale and complexity, threatening to overwhelm the internal resources of businesses around the world. The F5 Silverline Security Operations Center (SOC) recently saw a new distributed denial-of-service (DDoS) attack vector targeting a customer’s DNS servers with malicious traffic averaging between 8 and 12 Mbps and bursts of malicious traffic peaking at over 100 Mbps. This attack began in mid-August and continued through November 2015. It was not a typical reflection attack where DNS servers are used to attack a web site, but an attack against the actual DNS servers. Through additional investigation, the SOC analysts identified the vector and crafted a targeted mitigation for this new “_dmarc” attack. In their investigation, Edgar Ojeda and his colleagues found that F5 Silverline customer's DNS servers were receiving hundreds of thousands of randomized queries for “_dmarc” DNS records even if from a volumetric standpoint this amount of traffic seems to be trivial. Then, they noticed that _dmarc DNS queries were for non-existent subdomains and that customer’s DNS infrastructure was becoming unstable. As the attack continued and after further investigation, F5 SOC created a finely tuned signature that successfully scrubbed all malicious traffic and the customer’s service became operational again. To read the full report describing the attack, click here. If you are under attack, just click this link and we can get you back online! Click here to learn more about howF5 Silverline mitigate DDoS attack.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.
