|
ObjectWall is a proxy firewall developed specifically for IIOP. On this page, we answer the most common questions related to ObjectWall, the leading IIOP firewall on the market.
Frequently Asked Questions
 General
• Does CORBA/EJB run over a firewall? I heard this is impossible!
It is indeed very often heard that IIOP, CORBA’s main protocol, does not work over a firewall. And that therefore CORBA cannot be used over the Internet. But this is just an urban legend! CORBA runs very well over firewalls, with the full functionality, the development of large scale and complex applications based on CORBA and EJB running over the Internet is possible.
• But if CORBA over a firewall is possible, why do the Web Services folks say it is not possible?
One of the big arguments of the Web Service community against CORBA is that “CORBA does not run over firewalls, Web Services do!” The first part is not true! But there is indeed a big difference between firewall support for Web Services and CORBA. First of all, what is a firewall? An old, good definition is: “A firewall is a device enforcing a security policy at a domain boundary.” If the security policy explicitly allows a protocol or application, it has to be enabled on the firewall. If the policy does not allow it, the according traffic must not be permitted. This is how security is supposed to work at a firewall. If there is a clear need, a protocol can be enabled, based on a deliberate decision. That’s how CORBA is supported. You actively have to do something, installing ObjectWall and defining a security policy. At the end, you have a secure application, according to your security policy. Web Services simply run over a firewall, they are tunnelled through the HTTP protocol, whether this is in line with your security policy or not.
• Why is CORBA across a firewall so complex?
IIOP is a very powerful and flexible protocol, for example client and server can change their role in an application. There are also no fixed ports for IIOP and new objects or servers can be launched during runtime. This makes the handling of CORBA more difficult than handling simple request/reply protocols with fixed ports, like for example HTTP.
• On which platforms is ObjectWall available?
ObjectWall is available on Linux, FreeBSD, OpenBSD, Solaris and Microsoft Windows. If you have a requirement for a specific operating system, then please get in touch with us.
• I have a CORBA application to run over a firewall, but no interface description. Is this supported by ObjectWall?
No, this is not supported. You need the application’s IDL file; otherwise ObjectWall cannot understand the requests.
What about assurance?
• How secure is ObjectWall?
The term secure includes many aspects: Correctly enforcement of a given security policy, but also enforcement of the correct security policy. Here we will concentrate on the first aspect, which is called assurance.
ObjectWall was developed with great care, and is based on sound concepts and the CORBA specification. But, compared to proxies for simpler protocols, it is a large piece of software. Therefore there is a risk for vulnerabilities, like in all software of similar complexity. This risk is small, but not zero. We therefore recommend running ObjectWall in a restricted environment.
The safety, the correctness of request handling, of ObjectWall is very high, because it is strictly based on the CORBA specification.
• How well does ObjectWall protect servers?
ObjectWall can be used for access control on security unaware servers and translate between unencrypted IIOP and SSLIOP. This works very well, within the conceptual limitations of the CORBA specification. For example, ObjectWall, like all security at the middleware level, does not protect against vulnerabilities in the servant code. If there is a buffer overflow in the servant which can be exploited using well crafted arguments, ObjectWall does not protect against it, because it just sees legitimate arguments.
ObjectWall is a security tool providing specific functionality, firewall traversal and a specific set of access control functionality at a domain boundary or in front of a server. It provides the best protection functionality which can be achieved at these points, according to the CORBA specification. But just installing ObjectWall does not make a system completely secure, this is not possible. Security is a property of the system as a whole, optimal protection requires a detailed understanding of the CORBA specification and its limitations.
The ObjectSecurity team can help you with the development of secure applications, with bringing existing applications to an optimal security level and with assessing remaining risks.
• How can I improve the security and assurance my ObjectWall installation?
Installing security in complex environments can be tricky, if you want a maximum level of security. For example you can put ObjectWall into a restricted virtual environment and apply defence in depth, e.g. by using additional packet filters. For more information and help get in touch with the ObjectSecurity team.
• Why is ObjectWall called “reliable”
ObjectWall is called “reliable”, because it handles the most complex part of IIOP firewalling, the proxification of object references in requests, in a reliable manner. Some IIOP proxies try to proxify these references just by scanning for them in the IIOP message’s byte stream. Here a lot can go wrong. The proxy does not find the reference, or it finds something which looks like a reference, but it is not. The consequence in both causes is a disaster. ObjectWall completely unmarshalls the request, based on its interface description. This results in a deterministic proxification and a high safety level.
• Callbacks do not work!
A common reason for it is a wrong interface definition. To correctly proxify a reference, it has to be transferred as an object. If you move your references around by other means, for example as strings, the ObjectWall cannot find it. This is a feature, not a bug.
• Callbacks still do not work
Most likely this is a user configuration error. Please make sure that you correctly configured ObjectWall’s accepting endpoint on the inner network interface and also bind the initiator to the outer interface. You can also switch on debugging and use the administration tool to watch the reference translation process directly.
ObjectWall also depends on correct object references. In CORBA, using specific POA policies and SL3, it is possible to generate internally inconsistent and therefore incorrect object references, which cannot be understood by ObjectWall. But this is not a bug neither in CORBA, POA nor in SL3, but usually in a wrong setup of SL3 credentials.
• Does ObjectWall support very complex CORBA applications?
Yes, it does. We are using it running CCM based applications over the Internet. These applications have a complex architecture including callbacks, large interface descriptions, and many server process and objects. ObjectWall was developed to handle exactly such systems.
• Can I add or remove new objects during runtime
In most installations, ObjectWall is a long living daemon process. The admin interface allows a runtime configuration, e.g. adding or removing of proxy objects and adding of new interfaces to support. It also allows a monitoring of the system, including a detailed logging of all requests.
Performance
• How big is the performance impact of ObjectWall
There are lies, damned lies and benchmarks. This also applies to any performance numbers for ObjectWall. It is easy to proof that ObjectWall has almost no performance impact, and it is also easy to proof that ObjectWall has a high performance impact! It just depends on the benchmark. Therefore it is not possible to give really representative performance numbers, because it strongly depends on the application and environment. So let's better look at the factors which have an influence on the overall performance of systems with ObjectWall. But first of all, let's define performance: It consists of two parts, latency and throughput. The latency is the turn around time of a request, the throughout is the number of bytes you can move around in given time, e.g. in a sequence.
ObjectWall's main impact on the latency of an application is cause by the principal architecture of a proxy based firewall: Normally, a client sends a request to a server, and the server then sends the reply back to the client. A proxy based firewall, like ObjectWall, receives the request from the client and sends it to the server, and then relays the reply in the reverse way. So, instead of one invocation, we now have two invocations. If both the networks between client and the proxy, and the proxy and the server, have the same speed, the latency is doubled, plus the relatively small impact of the highly optimized internal processing at the proxy. This doubling of the latency is a principal property of all proxy based firewalls. In most practical applications of ObjectWall, it does not play a big role, because the properties of the networks are different. In most cases, one network is a fast LAN, and the other side is a comparatively slow WAN. In this case, the latency over the WAN is the most important factor; the additional latency of the second call over the LAN plays a minor role. For example, in several applications we are running CORBA over the Internet and over GPRS. In all such applications, the overall latency is completely dominated by the latency of the WAN, ObjectWall just has a minimal impact.
The second aspect of performance is throughput, e.g. bytes per second in a sequence. Here ObjectWall is heavily optimised; its impact on throughput is very small.
Please note that the interface description of an application can have a strong influence on the overall performance of a CORBA application. This also applies to ObjectWall; ObjectWall even tends to enforce this effect. Get in touch with us if you want to learn how to define efficient interfaces.
• What hardware do I need for running ObjectWall?
This is of course difficult to say and depends on your performance requirements. Our company firewall is a 1.1GHz box with 1GByte RAM with a WAN connection and several 1Gbps LAN interfaces. It is handling some very complex SecureMiddleware applications with large interface descriptions. Loading the IDL files into ObjectWall takes several minutes, with a high load. Then, during runtime, the load drops to almost zero, with a memory consumption of about 30MByte, because the WAN connection is by far unable to saturate this box. If we use normal applications between LAN interfaces, the load is still modest, of course depending on the application.
Access Control and Policy Enforcement
• How does Access Control work?
The ObjectWall Enterprise Edition uses the OpenPMF Policy Management Framework for the definition, management and enforcement of security policies.
Policies are defined in the OpenPMF Policy Description Language (PDL) and loaded into a central policy repository. During startup, ObjectWall obtains the policy from the repository and instantiates it. When a call arrives at ObjectWall, it is intercepted and checked for consistency with the policy.
OpenPMF provides a very high flexibility of security policies, and advanced central management and logging. It esp. allows a seamless integration of ObjectWall into an application’s or organization’s overall security architecture, for example policy roles defined for protecting servers can directly be reused, and all management and logging is handled in an unified manner.
• How does PDL look like, it is difficult to write?
Here is simple example of PDL:
policy /OS [*, *] {
policy /OS/ObjectWall [*, *] {
(client.name == Karel_Gardas)&(operation.name == create)&(target.type == IDL:Bank:1.0) : allow;
(client.name == Karel_Gardas)&(operation.name == deposit)&(target.type == IDL:Account:1.0) : allow;
(client.name == Karel_Gardas)&(operation.name == balance)&(target.type == IDL:Account:1.0) : allow;
(client.name == Karel_Gardas)&(operation.name == withdraw)&(target.type == IDL:Account:1.0) : allow;
};
};
Writing policies in PDL is not difficult; the language is simple, but flexible enough to support complex policies. The difficulty is writing correct and maintainable policies with minimal privileges, esp. in very complex systems with many interactions. This needs some thinking and, in complex systems, practical experience. PDL also supports security roles. This allows a separation of concerns in the policy definition: An application expert, who knows the interactions of the application in detail, defines the roles. A security administrator then later just adds the client information, the identities or roles of the clients using these application roles.
To facilitate the policy definition in very complex applications with many objects, we will support an assisted generation of the security policies in the near future.
• Is it possible to centrally manage several ObjectWalls?
Yes, this is supported by OpenPMF; you can centrally define and manage security policies for a large number of ObjectWall Enterprise Edition proxies and other services and application servers. This also supports a runtime modification of policies and a central logging of security events. In several installations we are managing ObjectWall proxies and large scale CCM based applications dispersed of large parts of Europe, without problems.
• Can I integrate the security enforcement for ObjectWall and my servers?
Yes, this is also the recommended method. You can use a single security policy for your whole application or even organization. This policy is then enforced at the application servers, services, the ObjectWall proxies and other places, depending on the policy. This gives you a single and consistent security policy.
• Can I use LDAP for authentication?
Yes, you can use LDAP based authentication with the ObjectWall Enterprise Edition. Thanks to underlying OpenPMF’s very flexible structure it is also possible to easily integrate other directory services or security infrastructures.
• Is logging supported?
A central logging of security relevant events is supported by the ObjectWall Enterprise Edition.
|
