Linux in Banking

Mr. Shoham tells us how his company set up an Internet banking system using Linux for a bank in Western Canada.
Networks

There are three conceptual network segments between these hardware components:

  1. The Internet between the client and an external firewall

  2. Network-1 between the external firewall and the application WWW server

  3. Network-2 between the application WWW server and the mainframe

This arrangement is illustrated in Figure 1.

Figure 1. Linux in the Loop

A Robust Development Environment

In developing our customer's Internet banking system, we first deployed a Linux-based development environment consisting of a Compaq Prosignia server, 64MB of RAM and a pair of 4.3GB Ultra Wide SCSI disks. We installed a Debian Linux distribution on this system. On the platform we installed a wide range of tools, shown in Table 1.

We used this setup as our primary development environment. Using Apache-SSL, we were able to test various browsers to check the application's behaviour and to adjust its appearance.

Using some customized Makefiles and libraries, we were able to write Java client code, C-language CGI and daemon programs, C-language mainframe programs and COBOL program stubs all on this environment.

By implementing an RPC system, where a code generator translates a master transaction-description file into source code for each target platform, we were able to add new transaction types to the Internet banking application with just a few short commands.

Network Security

To secure the final system against denial-of-service, eavesdropping and impersonation attacks, we used Linux to implement an external firewall. Since our access control rules are simple and static, we were able to use the Linux kernel's built-in packet filtering features to limit remote access to just the minimum required services—DNS and HTTPS.

As a further precaution against unauthorized access, no system on the Internet can connect to our customer's mainframe without first passing through our application code. There is simply no path for network packets from the Internet to the mainframe. Our application system cannot connect to any computer other than the mainframe; this minimizes the exposure of other systems on our customer's network.

To ensure private communication, we use the SSL protocol, embedded in HTTPS, to protect the communication between the application WWW server and the client machine. We also do not entirely trust the physical connection between the application WWW server and the mainframe, so all communication between our application on the WWW server and our transaction management software on the mainframe is encrypted.

Finally, since users are likely to log in and walk away from their terminals, we implemented a token management system between the client Java applets and the mainframe, where tokens have an implicit timeout of a few minutes. Unattended sessions look exactly like attended ones on the client's machine, but are blocked from making new transactions.

Redundancy and Availability

An important concern in a live system of this magnitude is the possibility of down time, caused by power outages, hardware failures or high load. Our system is protected against power outages by uninterruptible power supplies (UPSs). In addition, we implemented two identical application servers, each of which serves as both a DNS and an application server. One system is configured as the primary DNS, and the other is the secondary DNS. If the primary should fail, DNS queries will cause clients to connect to the secondary system instead.

Finally, all connection-state information is stored in a database on the mainframe. Since the application servers are stateless, consecutive transactions can be routed through an arbitrarily large number of application servers, all operating in parallel. And since the application servers are PCs, we can scale the system up to handle an arbitrarily large amount of traffic simply by buying more PC servers, along with an intelligent router.

An Open-minded Customer

To take full benefit of Linux's technical advantages, however, our customer had to be open-minded. We have been fortunate to work with this customer, since they judged the merits of this architecture on the grounds of its reliability, features, extensibility, maintainability and cost. We are convinced that the implementation team's open-minded approach to technological alternatives allowed them to implement the best possible solution, rather than just the same technology as their competitors.

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions