Home » Linux Magazine » Internet banking system using Linux
linux security

Internet banking system using Linux

Idan Shoham

Issue #56, December 1998

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

M-Tech is a computer security products and services company based in Calgary, Alberta, Canada. This article describes our experience developing an Internet banking system for a major financial institution in Western Canada. Since it discusses the computer security infrastructure of this organization, they have asked that we not name them explicitly here. The system is now in production, and allows thousands of users to make financial transactions on-line.

This article will describe:

  • What components are needed to build an Internet banking system
  • How Linux made developing the Internet banking system easier
  • The deployment of Linux servers as key components of the final system

What is Internet Banking?

Internet banking may be defined as any system that gives customers of a financial institution the ability to execute financial transactions across the Internet. Since the connection between the customer and the financial institution is electronic, we are limited to transactions that do not require the exchange of money or documents. What remains are the following:

  • Funds transfers
  • Account balance and history inquiries
  • Bill payments
  • Loan applications
  • Retrieving information about services, branch locations, etc.
  • Sending feedback to the financial institution

While a given Internet banking system might not support every one of these features, it is possible to implement any of them. Internet banking is basically a user-friendly, secure and distributed user interface to existing banking systems. With this in mind, we were hired to do the following:

  • Design and deploy a network and application infrastructure to support the new application.
  • Help implement a WWW-based user interface in Java.
  • Help integrate the new system with existing business logic in our customer’s mainframe.


As outlined earlier, the Internet banking system must be able to support any transaction type where an exchange of physical items (such as cash) is not required. Since the set of possible transactions will evolve, it should be easy to extend the system to support new transaction types.

User Interface

The application is intended for use by thousands of users, many of whom have limited experience with computers. Accordingly, the user interface should be suitable for people whose computer skills consist only of having access to a computer, knowing how to start a WWW browser and how to type in a URL.

Additional requirements for the Internet banking system we were hired to construct are:

  • Different groups in our customer’s organization must be able to easily implement different user interfaces to the application with different graphics, advertising and menus.
  • Our customer must be able to customize and extend the system’s functionality in the future.


By far, the most important feature of an Internet banking system is that it should do no harm. In particular, the system must ensure that:

  • The existing “backend” (a mainframe used to process transactions) should be invulnerable to attack. Most importantly, it must not be vulnerable to denial-of-service attacks.
  • A third party, connected to the network somewhere between the user on the Internet and the Internet banking system on our client’s network, should find it impossible to decipher or alter the communication between those points.
  • Users should be authenticated using as reliable a mechanism as economically feasible.

As a general rule, the system should be as safe, both for the user and the financial institution, as transactions made by the user in a bank branch.


When deployed, the system consists of four physical components:

  1. Client workstations, which include a WWW browser with Java and SSL capabilities
  2. One or more firewall systems to protect the Internet banking servers against external assault
  3. One or more application gateways: the Java user interface applet is downloaded from these and must communicate with the backend through them.
  4. A backend transaction processing system: for most financial institutions, including our customer, an IBM mainframe is used.


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.

Table 1. Banking System Tools

Function Tool
C compiler gcc
Lexical analyzer-generator flex
Parser-generator bison
Java class compiler JDK 1.0.2
Revision control system PRCS
WWW server Apache-SSL
WWW browser Netscape Communicator
Document typesetting system LaTeX
PC-client file services Samba

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.

A Mature Development Environment

We have used Linux as a development platform before and chose it because of the rich set of tools included with most distributions. This project held no surprises—Linux was a convenient, productive and reliable development platform. We never had problems with any of the development tools, and never experienced system downtime.

In the past, we have developed software for Windows NT as well as for other UNIX platforms. Linux compares very favorably with these as a development and deployment platform—it is simply more full-featured and better supported.

A Robust Production Platform

Linux is proving its worth as a production environment as well. It runs on inexpensive hardware and, along with Apache SSL, offers excellent WWW server performance. We would be hard-pressed to find comparable systems on which to run our WWW servers, development environment and firewall without spending much more money and settling for a less comprehensive tool set.

In this project, the rich set of network features found in Linux proved especially useful. In particular, the following:

  • Setting up the firewall was simple, and the resulting system is quite effective.
  • Our development server uses ssh for secure remote connections, the X Window System for convenient access to source files and tools, and Samba to allow developers to access files directly from their PCs.
  • BIND made it easy to implement a failover from the primary to a backup server.
  • Various shell tools make it easy to keep the software on the backup server current.

Linux is not only feature rich, but also well-supported. We have found that whenever new security exposures are discovered, Linux is invariably the first system for which patches or workarounds are available. For instance, the ping-of-death vulnerability was reportedly fixed in three hours, and a Linux patch for a common buffer-overrun vulnerability was released alongside the discovery of the bug itself. We doubt that any vendor could match the response time of the worldwide community of Linux programmers.

An Open Future

In this project, we built just one application—a user interface with which our customer’s clients can make financial transactions. However, there is nothing about our technology that is specific to the Internet or even to banking.

Within our customer’s organization, the same technology could also be used to enable thin clients to function as teller workstations, process loan applications and support communication with automated teller machines and telephone voice response systems. Beyond the financial sector, this technology could be used for any transaction processing system with a broad or geographically distributed user community. Examples include travel booking systems, libraries, government registries and more.


Two months after this article was written, the system has gone “live,” and has a large number of active users. We also found some bugs by stress testing the system in a production environment. Our experiences were surprising:

  • So far, we have found two separate operating system bugs in MVS. One made it impossible for the CICS region where our software runs to be shut down, due to a problem with the TCP/IP socket library. Another has to do with memory not being properly freed up by the standard C function library. So much for the robustness of mainframes!
  • Unsurprisingly, we found and fixed a number of small bugs in our own software.
  • To date, we have had no problems, and have found no bugs, in the Linux servers.

What is interesting here is that the least expensive component of the system and the one with no formal vendor support has been the source of the fewest (i.e., zero) problems. Much more expensive systems and much more expensive vendors (us) have yielded more troublesome systems than Open Source software.


Idan Shoham is one of the principals of M-Tech. To learn more about M-Tech, please visit the company’s site at http://www.m-tech.ab.ca. Mr. Shoham can be reached via e-mail at idan@m-tech.ab.ca.