|
|
|
|
Orbix Wonderwall Administrator's Guide |
The Internet Inter-ORB Protocol (IIOP), a specialization of the CORBA General Inter-ORB Protocol (GIOP), paves the way for using distributed CORBA objects over the Internet. This opening up of the Internet, however, brings its own problems and risks. There will always be a few users willing to exploit any security loopholes to cause damage to your system. Some level of security is necessary to keep these intrusions at bay. A typical approach to Internet security is to use a firewall to restrict access to hosts on your local network. The basic model is to direct all traffic to and from the internal network through a single access point that can monitor and control every transmitted message.
There are firewalls currently available that restrict access to a local network in a variety of ways--for example, access to certain hosts and certain commands can be limited. However, in a distributed object environment such as CORBA, it is important that security should have an object focus to it. Experience has shown that it is bad practice to implement security which is too coarse-grained. Users presented with a choice between two levels of security, one which is too restrictive and another which is too permissive, will inevitably choose the permissive level of security on occasion--and consequently a breach appears in the network defences.
Wonderwall is developed according to the firewall model and addresses the security issues arising from using CORBA over the Internet. It provides a flexible, object-oriented approach to security allowing control of access to individual objects even down to the level of individual operations on objects.
Wonderwall is a firewall proxy server that is specifically designed to filter, control, and log IIOP traffic between Orbix clients on the exterior (the Internet), and Orbix servers on the interior (the intranet). As such, Wonderwall monitors the IIOP requests and applies access control rules to determine whether to permit or block the request.
A typical approach to building a firewall involves restricting Internet access to a single IP port on a single host for each service. This host will be the only host which is physically connected to the Internet and the restriction to using a single well known IP port provides an additional safeguard.
A refinement of this model involves making the firewall host a dedicated, secure host, known as a bastion host. The bastion host is dedicated exclusively to the role of gateway to the Internet and its configuration can be hardened to make it extra secure against unwanted incursions. This approach has the clear advantage that much of the security effort can be focused on this one machine. For example, many directories on the bastion host can be made read only to root without inconveniencing anyone.
A typical approach to building firewall proxy servers for each of the Internet services to be made available. Additionally, these proxy servers are usually deployed on a bastion host. This is a host which is both connected to the external network, the internet, and the internal network. Wonderwall follows this pattern and implements an IIOP proxy server. The role of the server process is to listen to incoming messages on the well-known IP port and to pass on these messages to the internal network, after subjecting them to access control rules. When any potentially hostile or forbidden messages are encountered, these are blocked and not passed on to the internal network.
Traditional and typical firewall infrastructure, composed of packet filtering routers and application level proxies, can be used for protecting distributed CORBA application environments. However, the complexity of such environments increase the potential security loopholes. Administration and management overheads for the security policy would also increase. When using traditional firewall mechanisms when applied to distributed CORBA environments, Wonderwall can be used to establish an enclave of servers for which it controls access.
In contrast, Wonderwall which adheres to the application proxy firewall model, but at the same time uses message filtering techniques in the application of security policy is a simple stand-alone process, which requires no special privileges, forks or processes, and interacts with the bastion host in a simple manner.
Wonderwall's IIOP firewall proxy server has the following features which contribute to strengthening the security of an internal network:
The model on which Wonderwall is built supports the use of a bastion host as the basis of your firewall. You have only to install the Wonderwall server on the bastion host and it will act as a liaison between the outside world and your internal network. Alternatively, you can install Wonderwall on a regular host if you prefer.
All messages arriving on the server's well known port are filtered. Wonderwall is not just a facility to monitor initial connections to CORBA objects. For example, it will continue to monitor (and potentially block) all messages which pass between an external client and the internal CORBA object.
A number of message types are defined for the IIOP protocol and any or all of these can be blocked if necessary. The most important group of incoming messages are the Request messages which are used to invoke methods on CORBA objects. Wonderwall provides comprehensive filtering of these messages based on the content of the Request message header. This header provides all information needed to provide effective filtering. For example, the identity of the target object and the intended operation name. Request messages can be checked rapidly and passed to the internal network with little performance overhead.
Wonderwall provides the kind of fine-grained control of security which is needed for a distributed object environment. It allows you to control access to individual objects and, moreover, to allow or deny access to specific methods defined on that object. There are a number of other criteria which can be checked as will be seen later.
The logging facility of Wonderwall (which can be configured to focus on particular kinds of events) is a powerful facility for tracing the history of suspicious message exchanges. It is also broadly useful as a debugging and monitoring facility.
Wonderwall observes and promotes good security practice. For example, its approach to filtering is that everything is forbidden unless it is expressly allowed.
According to Wonderwall, a proxy server ought to behave simply and predictably.
By means of its integrated SSL support, Wonderwall supports end to end security between client and target servers.
As part of the SSL infrastructure, Wonderwall can authenticate agents on both sides of the firewall, that is, both clients and servers.
Chapter 2 Getting Started with Wonderwall explains how to set up and configure Wonderwall which is also fully interoperable. For further information, refer to Chapter 4, Interoperability and Wonderwall Operational Details.
Before learning how to use Wonderwall, however, it is necessary to have an elementary understanding of the IIOP protocol itself.
The IIOP protocol specifies the way in which CORBA messages are encoded for transmission. In particular, it specifies a universal format for the transmission of operation invocations across the Internet. This makes it possible for clients of one ORB to send operation invocations to any ORB across the Internet, and also to correctly interpret any return values received.
When an IIOP client sends a message to a remote object, it requires an Interoperable Object Reference (IOR) which stores the addressing information for that object. For the IIOP protocol, an IOR will include the following information:
When a CORBA client invokes on a target CORBA object, that is, it uses an IOR, it does so using the IIOP protocol. This invocation opens a TCP connection to the host and port contained in the IOR. The client's ORB then sends and receives IIOP messages over this connection. If multiple objects use the same host and port, the client can use the same connection to communicate with the other objects.
The IIOP model is based around two main message types: a Request and a Reply. Clients send Requests, and servers send Replies. There is also a set of message types used to handle unexpected error conditions or timeouts. Refer to ""Reply Message" on page 36 for further information.
In the same way that a filtering router can filter packets based on the packet header, Wonderwall filters incoming Requests based on the following information gleaned from the message header:
Refer to "HTTP Server" on page 19 and Appendix A, "iiopproxy and iortool" (page 157) for further details on the filtering mechanism and how it is specified. The body of Request messages cannot be filtered without knowledge of the Interface Definition Language (IDL) used to define the operations and parameters for each object, so only the message header parameters can be used in a filter.
In the present version of Wonderwall, any Reply messages which pass from the internal server out to the client are not filtered.
The basic component of Wonderwall is the executable iiopproxy. This process is intended to run on the bastion host listening for IIOP requests on a specified TCP port. Any requests which arrive on this port from external hosts are filtered so that access can be restricted to certain CORBA objects or operations behind the firewall.
You can control the filtering of packets by editing the configuration file iiopproxy.cf. This file allows you to specify a flexible set of rules for either allowing or denying access to certain objects or operations.
Once a given request has been allowed through the firewall, the process iiopproxy forwards it to the proper location on the internal network. The iiopproxy does this by looking up its own database of IORs which include all the externally accessible CORBA objects.
In the following chapter, Getting Started with Wonderwall, an example of a configuration file is given and the database of IORs set up so that the firewall can pass on requests to a couple of objects on the internal network.
|
support@iona.com Copyright © 2001, IONA Technologies PLC. |
|