Internet banking system using Linux

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:

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:

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:

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.

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:

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:

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:

There are three conceptual network segments between these hardware components:

This arrangement is illustrated in Figure 1.

Figure 1. Linux in the Loop

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

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.

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.

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.

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.

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.

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:

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.

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.

Postscript

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.