Common Object Request Broker Architecture (CORBA) and Internet Inter-Orb Protocol (IIOP) (Building Internet Firewalls, 2nd Edition)

14.5. Common Object Request Broker Architecture (CORBA) and Internet Inter-Orb Protocol (IIOP)

CORBA is a non-Microsoft-developed object-oriented distributed computing framework. In general, CORBA objects communicate with each other through a program called an Object Request Broker, or orb.[35] CORBA objects communicate with each other over the Internet via the Internet Inter-Orb Protocol (IIOP), which is TCP-based but uses no fixed port number.

[35]In a rearguard action against the proliferation of acronyms, CORBA users almost always treat this as a word ("orb") instead of an acronym ("ORB").

IIOP provides a great deal of flexibility. It permits callbacks, where a client makes a connection to the server with a request and the server makes a separate connection to the client with the response. It also permits bidirectional use of a connection; if a client makes a connection to the server, the server is not limited to responding to requests from the client but can make requests of its own over the existing connection. IIOP does not provide authentication or encryption services, leaving them up to the application.

All of this flexibility makes it basically impossible to make blanket statements about CORBA's security. Some applications of CORBA are quite secure; others are not. You will have to analyze each CORBA application separately.

In order to help with security, some vendors support IIOPS, which is IIOP over SSL. This protocol provides the basic protections SSL provides, which are discussed later, and therefore will help protect applications that use it from packet-sniffing attacks.

14.5.1. Packet Filtering Characteristics of CORBA and IIOP

Because there is no fixed port number for IIOP or IIOPS, the packet filtering characteristics of CORBA will depend entirely on your implementation. Some orbs come with predefined port numbers for IIOP and IIOPS, and others allow you to allocate your own or allocate ports dynamically. (Some orbs don't support IIOPS at all.) In addition, a number of orbs will allow you to run IIOP over HTTP.

IIOP is extremely difficult to control with packet filtering. A packet filter cannot tell whether an IIOP connection is unidirectional or bidirectional, so it's impossible to keep the server from executing commands on the client using packet filtering. In addition, if your application uses callbacks, you may need to allow connections in both directions anyway, further reducing your control over the situation.

14.5.2. Proxying Characteristics of CORBA and IIOP

There are two different ways of using proxying with IIOP. One of them is to use a proxy-aware orb, which knows how to use a generic proxy like SOCKS or an HTTP proxy server. Another is to use an IIOP-aware proxy server, which can interpret IIOP port and address information. There are multiple implementations of each of these solutions.

Either kind of proxying provides better security than can be managed with packet filtering. Using a generic proxy requires less configuration on the firewall, but it makes your security entirely dependent on the orb and the applications developer. An IIOP-aware proxy server will allow you to add additional protections by using the firewall to control what operation requests can be passed to the orb.

14.5.3. Network Address Translation Characteristics of CORBA and IIOP

IIOP includes embedded IP address and port information and will require a network address translation system that's aware of IIOP and can modify the embedded information.

14.5.4. Summary of Recommendations for CORBA and IIOP

Do not try to allow all CORBA through your firewall; make specific arrangements for individual CORBA applications.

For maximum security, develop single-purpose CORBA-aware proxies along with the CORBA application.