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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix