The goal of good network security is to reduce your dependence on host (DBMS) security. Often, you can obtain a high degree of synergy by combining host and network security practices. Until recently, however, firewall security had been a pervasive problem for all Java database connectivity (JDBC) products. That�s because they employ protocols such as Internet InterORB Protocol (IIOP) and Tabular Data Stream (TDS) that early firewall vendors did not support directly. JDBC is a standard SQL-access interface similar to ODBC. However, JavaSoft�s JDBC is designed to allow the downloading of the database connection over the network at runtime, whereas Microsoft�s ODBC requires a separately installed and configured driver to be installed on the client in advance.
Java is a new language, with version 1.0 released in January 1996. Half a year later, JavaSoft gave us JDBC. In contrast, today�s leading firewall makers have been providing us with perimeter defenses, demilitarized zones, and the likes for the Internet and intranets for almost five years.
Because of their late arrival, the early publishers of JDBC products had to accommodate the preexisting firewalls by providing HTTP tunneling and such (more on this later) in order to pass their protocols through these security devices. Today, however, most firewall vendors directly support the new protocols and services needed to add the power of Java to databases. As a result, these disparate technologies can now work together, at least when used carefully.
In an InformationWeek article (November 25, 1996, page 128), James I. Cash Jr. (a James E. Robison professor of business administration at Harvard Business School) said, "The performance of disruptive technologies is initially inferior to that of established technologies. But over time, improved performance combined with new capabilities gives disruptive technologies dominance over the older technologies." The story of JDBC and firewalls appears to support this view, but I would add the caution that disruptive technologies force organizations to unlearn old skills and procedures.
The remainder of this article presents some of the most important factors you need to consider when selecting both JDBC driver implementations and firewalls together. I�ll elaborate on how you can now realize the advertised benefits of these two technologies without losing any of the return on your previous investment in fast and secure DBMSs, data communication links, and so on. But first, let�s start with the fundamentals.
A firewall puts up a barrier that controls the flow of traffic among hosts, networks, and domains. The safest firewall would block all traffic, but that defeats the purpose of making the connection. You need strict control over selected traffic according to a logical security policy. Typically, organizations put a firewall between a private, trusted network and the public Internet. Here, as elsewhere, a firewall can conceal the topology of your inside networks and network addresses from public view. But that�s only the beginning.
I�d like to start off with a brief review of some basic firewall models and cite two high-end commercial firewall products. I�ll conclude the article with an outline of some real-world Web browser-to-DBMS systems in which these or other firewalls can be used to permit or deny packets sent to them by different JDBC driver implementations.
Simple packet filtering. Packet filters work by distinguishing packets based on IP addresses or specific bit patterns. But note: Most security policies require finer control than this. Because of the limited information accessed, packet filters are unable to protect against application-level attacks and may be susceptible to sophisticated IP fragmentation and IP source routing attacks. This kind of firewall is typically found in routers, so they�re economical and fast. Since you probably need a router to connect to the Internet in the first place, there is no extra charge. Even if the router belongs to your network service provider, you�ll probably find that it will install any filter you want. Or your router can simply be a computer that contains two network interface cards (a dual-homed system) and runs an operating system like Windows NT or Novell NetWare.
Application-layer firewalls. Application-layer firewalls, or gateways, focus on the application layer of the OSI reference model of network architecture. Working at this level allows them to use dedicated security proxies to examine the entire data stream for every connection attempt. A virtual "air-gap" exists in the firewall between the inside and the outside networks, and proxies bridge this gap by working as agents for internal or external users. The proxies are specific for applications such as FTP or Telnet or protocols such as IIOP and Oracle�s SQL*Net. In the application approach, information flows through the firewall, but no outside packets do � thus providing a virtually "fail safe" architecture. Typically, they support security policies that require fine-grain control.
Stateful multilayer-inspection firewalls. These firewalls analyze all packet communication layers and extract the relevant communication and application state information. They parse IP packets and keep state information about connections in the operating system kernel. Instead of examining the contents of each packet, the firewalls compare the bit patterns to packets that are already known to be trusted. Stateful multilayer-inspection firewalls can be faster than application-layer firewalls � the proxy mechanism is at a lower level � but they are also more complex; they can have some of the advantages and shortcomings of each of the previous two models.
Now you are probably asking yourself which of these three different types of firewalls is more secure and delivers the best performance. As is so often the case, this question can only be answered on a case-by-case basis after you consider the topology of your network, the services you plan to use, and the services you plan to offer. In limited circumstances, a simple packet-filtering router can be just as secure as a firewall costing 10 or 20 times as much. The reverse is also true; buying an expensive firewall will give little security if it is not properly configured.
Raptor Systems Inc.�s Eagle (at press time, Raptor announced that it was merging with Axent Technologies Inc.) and Check Point Software Technologies Ltd.�s FireWall-1 are high-end commercial firewalls. Both are available on Unix and Windows NT platforms, and both use rules, provide load balancing, and strong authentication (such as S/Key and CryptoCard), Virtual Private Networks (VPNs), and so on. But, they employ different technologies and maintain different industry alliances.
Compaq Computer ships Eagle firewalls with every Windows NT server, and IBM OEMs FireWall-1 for its AIX (IBM�s version of Unix) enterprise security software suite. Hewlett-Packard resells both. Raptor�s firewall uses application-layer gateways that rely on proxies for each protocol or service, while FireWall-1 uses stateful inspection technology.
Both companies recently announced plans to integrate new scanning capabilities for Java applets into their products. Raptor will include Finjan Software Ltd.�s SurfinGate software in the next version of its Eagle firewall, code-named Gold, which should be available now. Finjan�s software analyzes Java classes to which an applet is written. The programs then compare those classes with a company�s defined Java security policies. When they don�t match, the applet isn�t allowed through. As this article goes to press, Finjan is still negotiating with CheckPoint, which is expected to integrate Java scanning technology from Digitivity Inc.
There are many good reasons for selecting either one of these two firewalls. One feature that helped me choose Eagle was that it does not use First In First Out (FIFO) rule prioritization employed by most firewall products. The rule set is treated as "flat" so that the most significant rules can be applied. This means you can define your rule set without worrying about the order in which you put your rules.
In general, a firewall must deal with a protocol or service (for example IIOP, SQL*Net, or RealVideo):
You can gain access to a database from a JDBC applet or application through an intervening firewall by any of the methods I just listed, but in many cases, the second and third of these methods can�t deliver as much functionality, performance, or security as the first. For example, multithreading � the basis for high performance in a multiuser system � may be present only with the first method. Similarly, a choice of strong authentication schemes may also only be supported with the first method. And when your firewall uses encryption, HTTP tunneling may be at a disadvantage, compared to other methods.
You need to determine the maximum number of concurrent connections that a firewall can maintain and the maximum data throughput supported under multiple firewall configurations. In general, firewalls yield better overall performance when running on high-end Unix vs. Windows NT because the former is still better able to exploit today�s hardware platforms. But you can neutralize this advantage by using slower 10Mbits/sec Ethernet network interface cards or even 45Mbits/sec T3 cards. Go to 100Mbit/sec Ethernet if you need to exercise the full capacity of a resource-rich firewall machine.
When you require encryption, the maximum data throughput will be far lower, so enable encryption only on specific services. This ensures optimal performance without sacrificing privacy.
The "maximums" I�ve spelled out in the previous few paragraphs are largely a function of the hardware resources you make available in the platform on which you run your firewall. The two most obvious resources are memory and CPU (including symmetrical multiprocessing, or SMP). The performance of a firewall can benefit enormously from an increase in each of these computer components but only under certain conditions. As you might have guessed, adding memory can increase throughput but not until the connections to your firewall expand to fill existing RAM. Only then will additional memory make a difference. Naturally, the faster your CPU, the faster the processing of firewall rules. But running your firewall on an SMP workstation may or may not yield improved performance. For starters, some leading firewall vendors report that their products either won�t run on some SMP machines or can�t benefit from the increased "horsepower" SMPs make available. Not so for other firewall vendors just now preparing to release upgrades to their products that will exploit SMPs. Both the SMP story and the feature list of the new firewall releases are changing rapidly as this article goes to press. For example, Microsoft recently released Windows NT Server Enterprise Edition, and Raptor�s next release of Eagle has been optimized for running on SMP. Anyone wanting to find a hardware/software firewall package that provides a good match for his or her own load conditions might want to consider a single source (such as Hewlett-Packard) that offers a wide range of high-end and midrange options: SMP workstations (either Unix or Windows NT) plus a choice of the firewalls (Eagle and Firewall-1). A single source is in a position to speak more even-handedly about the various options. Because single sources have different kinds of technology to sell, they can recommend the most appropriate combination of hardware and software for achieving your design goals without fear that you might be co-opted by one or more of their competitors.
Consequently, you need to uncover this kind of information � not always an easy task � for any firewall you plan to use. Otherwise, the productivity obtained from the thousands (or even millions) of dollars you�ve spent to get the highest transactions per minute DBMSs or the fastest communication links to your client workstations may not be as high as you had planned.
Which platform you should choose to run your firewall depends on your specific network configuration, the required performance, and even the skill set of the security administrators within your organization.
In addition to the white papers and other documentation available at the Web sites of Raptor, Checkpoint, and other firewall vendors, firewall product-neutral information on firewalls and related Web security matters can be found at locations such as web.mit.edu/security/www, java.sun.com/sfaq, and www.finjan.com.
JDBC allows Java applets and applications to access different DBMSs through the same interface in much the same way as ODBC, but it requires no end-user configuration of data sources, thereby delivering an easier-to-deploy-and-maintain middleware solution. In the JDBC model, Java programs load JDBC drivers (software layers that implement the JDBC API for accessing data from DBMSs). Broadly speaking, there are four basic types of JDBC implementations:
I used PowerJ Enterprise, a new Java development environment from Sybase�s Powersoft division, to build simple applets to test drive several JDBC drivers for the preparation of this article. Before continuing any further, let�s examine the particular drivers shipped with PowerJ.
Client-centric JDBC. Sybase�s jConnect for JDBC is a pure-Java implementation of its proprietary TDS protocol. Running on top of the TCP/IP network protocol, TDS enables jConnect to access Sybase SQL Server, Replication Server, and OmniConnect directly. Here, a native-protocol, all-Java driver converts JDBC calls into the network protocol used by a DBMS directly. In general, this type of implementation is ideal in cases where the highest performance is required. But these network protocols are proprietary.
Client-centric JDBC/ODBC bridge. A Java and C/C++ implementation, the JDBC/ODBC bridge is a JDBC driver based on a traditional client-side ODBC architecture. Such a bridge is available at no cost from JavaSoft; in some cases (for example, where the client desktops already have ODBC drivers installed), it provides a very competitive solution. However, not being coded in pure Java, the JDBC/ODBC bridge does not support downloaded Java applets. It works only with Java applications.
Network-centric JDBC. XDB Systems Inc.�s JetConnect is a network-centric JDBC driver made up of two parts: a pure-Java JDBC client and a JDBC server that includes a JDBC/ODBC interface. (See DBMS, June 1997, for a review of JetConnect.) This type of JDBC driver translates JDBC calls into a database-independent net protocol, which is then translated into a database-specific protocol by the middle-tier server.
This server-centric JDBC driver can have a lower cost of ownership than the client-centric JDBC drivers do. The DBMS drivers only need to be located on the JDBC server platform. And this pure-Java JDBC client implementation is installable, portable, and secure on all Java-capable platforms including the new network computers from Sun and Oracle.
However, at a minimum, an additional communication hop and protocol translation are required before the translation is made to ODBC. Then there is the overhead of going from ODBC to the native protocol before the actual database is accessed.
As shown in Figure 1A, extensions to JetConnect are available to connect you to DB2 databases using IBM�s DRDA technology. XDB products excel in this arena. This architecture provides a high-performance catalog by creating an image of the target database�s system catalog tables on the gateway.
CORBA-based network-centric JDBC. Visigenic Software Inc.�s (recently acquired by Borland International Inc.) VisiChannel for JDBC uses a network-centric JDBC driver based on CORBA. This type of implementation uses IIOP, which is optimized for the kind of Internet data transfers used for database access. (Data access with "sessionless" HTTP results in poor performance and limited scalability.) The server component connects to a server-side ODBC driver to provide DBMS access.
Java programs can take advantage of Java�s multithreading capabilities; these capabilities are exploited by the VisiChannel for JDBC Server and Client. The VisiChannel for JDBC Client driver is thread-safe, allowing an application to have multiple thread-executing SQL statements against ODBC drivers that are thread-safe. JDBC calls against the same connection are serialized and execute in sequence. If an application issues multiple concurrent requests against statement objects associated with the same connection object, the requests are internally serialized by the driver. An application must issue SQL statements in a valid order.
The VisiChannel for JDBC Client driver is asynchronous at the connection level. An application can have multiple outstanding asynchronous JDBC calls against many different connections. A connection can have multiple statements, although each statement is limited to one outstanding asynchronous request. As shown in Figure 1B, VisiChannel for JDBC is the ideal data access technology for applets that run in Web browsers and access CORBA-compliant software objects or ODBC data sources over the Internet or an enterprise intranet.
Of necessity, my account of each of these JDBC implementations has been far from thorough. You can find more information on the different types of JDBC drivers as well as an up-to-the-minute list of the companies from which they�re available at java.sun.com/products/jdbc. You can also refer to JDBC Database Access with Java, a very recent work by Graham Hamilton, Rick Cattell, and Maydene Fisher published by JavaSoft Press (Addison-Wesley, 1997). This book has been expanded and adapted from the JDBC specification to include a tutorial and extensive reference material for programming.
Most of my consideration of network security and performance appears in the firewall section of this article. But what can the small firm or organization that doesn�t have a high-end commercial firewall do to have secure and efficient database access from its Java applets and applications? It should consider using a commercial JDBC implementation that incorporates data encryption (for security) and fast compression techniques (for performance). And ideally, it should use digital certificates to ensure that remote users are indeed who they claim to be. In some cases, these organizations may even want to use VPN links such as those found in the soon-to-be-ubiquitous Windows 98 and elsewhere. And the list of options goes on.
The XDB products shown in Figure 1C � an upscale solution to be sure � make database access to sensitive data more secure and efficient through application-level security and the elimination of SQL streams.
Application-level security provides the ability to grant privileges to applications rather than to data resources. This means that developers do not have to grant privileges to customers or provide blanket privileges to unknown users in order to allow them access to data. The application can be written to require password authentication and even privileges to use the application, but once the user has been authorized to use the application, the application can proceed with its programmed activities regardless of the user privilege set on the underlying database. In other words, when you grant authority to an application, not a user, he or she can�t take the password that grants access to the application and use it with tools like Sybase�s ISQL or Oracle�s SQL*.
Plus to get additional information from the data source. Data integrity is also improved because data manipulation is performed only under program control.
Elimination of SQL streams is an interesting option because passing SQL statements across the wire is risky. These SQL statements can provide valuable clues to hackers bent on cracking into the system. As an added benefit, techniques for eliminating long SQL strings can both reduce network traffic and improve database server performance.
The previous paragraphs are mostly about securing the server in the absence of a firewall. But published discussions of JDBC security usually center on how Java can safeguard the client. Currently, applets have a very strict set of security rules that must be followed when they are run through certain browsers. With these browsers, they are restricted in their access to the client machine as well as other machines. In fact, the only machine to which they are allowed to make a direct database connection is the machine from which they were downloaded. Furthermore, these applets are only allowed to run the code that has been downloaded with the applet. These last facts could be used by the designer of a JDBC applet to control access to the databases were it not for the fact that these restrictions are relaxed when applets are run using applet runners such as the JDK AppletViewer or the HotJava browser. Therefore, Java security notwithstanding, firewalls � or at the very least the options outlined in the previous paragraphs � are still a good idea when it comes to protecting your data.
Figures 1A, 1B, and 1C show not just the basic drivers described previously but also some other complementary products that extend the basic JDBC solutions. These extensions are not shipped with PowerJ; they are sold separately by the third-party vendors of the associated basic drivers.
Clearly, such extensions can add to the flexibility of your system design. In general, however, throughput performance in a distributed system is determined by how many times the data must be copied as it travels from its source to its final destination. The more middleware layers there are to traverse, the more times a data packet is copied, resulting in lower throughput performance. So just as I cautioned you about asking the question "which firewall is most secure and most economical to use" in the previous section on firewalls, I will now caution you about asking which JDBC driver is fastest and yields the greatest return on your investment without first considering the overall system in which it is used. Here again, it�s all one big trade-off.
I�ve been focusing on JDBC, however, traditional middleware protocols such as SQL*Net will usually still play an important part in your system. Fortunately, most of today�s firewalls do account for them.
Firewalls are indispensable assets in most organizations today. However, like all technologies, firewalls can create problems of their own. Imagine the case where your organization�s Web server publishes a Java applet that makes calls to a JDBC client. It then sends messages to a JDBC server (a TCP service) running on a particular port of a host at your site. As the administrator of your site, you configure your firewall to allow this traffic in either direction. But you may have neither knowledge nor control of the remote site whose browser downloaded your applet. If a firewall at that site is configured to deny traffic destined for this same port, you have a problem. Here�s an instance where an intranet over which you have control can provide a more certain solution than the Internet, over which you have relatively little control.
Implicit in this whole discussion has been the notion that the firewall was positioned to protect internal hosts (DBMSs) from outsiders. But an Internet firewall is only a controlled gateway. It cannot stop attacks from malicious insiders, nor can it take the place of education and security policies and procedures. An Internet firewall is part of an overall security plan. Since the majority of network and system attacks occur from inside of corporate networks and are launched by "inside" or trusted people, you may also want to consider additional firewalls behind the perimeter ("bastion") firewall defense.
A good deal of what I�ve said is theory. Here�s why: Once you�ve acquired as much information as you can from the vendors of the products whose features interest you, a useful starting point in database application system design is the drawing of preliminary block diagrams. You use them to show the relationships among the components that you believe will provide a desirable solution. At that point, you can count the number of "hops" from browser to DBMS required by each of the designs you are considering. All things being equal, the system with the smallest number of hops will yield the best performance. But all things are not equal, as a rule. So like everybody else, you�ll need to try each of your proposed designs (in a pilot lab, not on your production system) to see how it actually works. Understanding the theory should help you come closer to your goal of selecting the right components at the outset.
| Firewall Vendor Information: |
|---|
|
| JDBC Driver Vendor Information: |
|---|
|
