Architecture of a Distributed Object Firewall Proxy. Abstract

Transcription

1 NAI Labs #0768 Architecture of a Distributed Object Firewall Proxy July 16, 2000 Gary Lamperillo Gary_Lamperillo@NAI.com NAI Labs - The Security Research Division Network Associates 3415 S. Sepulveda Blvd. Suite 700 Los Angeles, CA Telephone Fax Abstract The Multi-Protocol Object Gateway (MPOG) provides access control for operations on distributed objects. MPOG provides support to allow distributed objects to cross enclave boundaries. An enclave is defined as an enclosed intra-network usually protected by a firewall. The MPOG is an application proxy server, written entirely in the Java programming language for platform independence, which has been installed on Network Associates Gauntlet Firewall. An application proxy server proxies connections from clients to application servers protected by enclave firewalls. The key distributed object technologies targeted in the MPOG are the Common Object Request Broker Architecture (CORBA) Internet Inter- ORB Protocol (IIOP) from the Object Management Group (OMG), Java Remote Method Invocations (RMI), and Microsoft Distributed Component Object Model (DCOM). The MPOG architecture provides reuse of the policy database and access control techniques for multiple distributed object technologies. The policy information can be identical for all distributed object models, since all such technologies have similar functionality, in that a remote invocation is made for a particular remote principal. This work is sponsored by DARPA and managed by Air Force Research Laboratory under contract number F C DARPA and Air Force Rome Laboratories have not approved this document for public release. Do not distribute to unauthorized personnel.

2 Architecture of a Distributed Object Firewall Proxy Gary Lamperillo Gary_Lamperillo@NAI.com 1. Distributed Object Technologies Corporations have embraced object oriented programming because of its promise to improve maintenance, reusability, and modifiability of software. With the recent growth of the Internet, there has been an increased need to use object oriented programming in a distributed environment. The distributed object technologies DCOM, CORBA, and Java RMI have become useful tools in creating distributed applications with relative ease. A common feature of these technologies is the notion of location transparency, an abstraction that lets a programmer call methods on an object without knowing where that object actually resides. An advantage of this feature is that programmers can continue to program within the context of a familiar model. Using distributed object technologies leads to the natural extension of using them from corporation-to-corporation and corporation-to-customer. However, handling of these protocols by commercial firewall proxies has not been developed prior to this effort. Prototyping and investigation into handling these emerging distributed object technologies have given us the opportunity to provide input to standards to modify specifications and/or code for increased firewall interoperation. The OMG CORBA 3 Firewall Specification is an example of NAI Labs efforts to facilitate interaction of distributed object technologies, in particular CORBA IIOP with firewall technologies [1]. Protected Enclave IIOP Client IIOP Server RMI Client MPOG RMI Server DCOM Client Firewall DCOM Server Figure 1: MPOG Message Routing 1

3 2. Routing for Distributed Object Messaging Distributed object technologies typically assume the existence of a direct communication channel between the client and the server. Routers and firewalls, which may be intermediaries, have not in general been addressed in the protocol designs. Once a firewall proxy intercepts a message, it can be difficult to determine how to forward the message. A firewall can operate in a transparent mode where it masquerades as the internal server and thus enables clients to specify the server as the communication endpoint even though the firewall is an intermediary. This approach allows TCP/IP protocol data to provide the forwarding information that is not present in the message. However, this approach may be unsatisfactory, since it allows outside hosts to successfully address traffic to inside hosts, which is sometimes undesirable. If direct addressing is disallowed, then the transparent forwarding approach is disabled [2]. The CORBA 3 Firewall Specification specifies a method for hiding internal IP addresses from external clients, however, this has not been implemented by any CORBA vendors to date, and is not available for Java RMI or DCOM [1]. Figure 1 shows a message routing diagram for the distributed object technologies used by the MPOG. The approach taken for the MPOG project was to assume that direct routing is allowable and to utilize the firewall s transparent feature. However, facilities in the MPOG are available to route based on the CORBA, Java RMI, or DCOM interface requested. This feature may be useful when direct addressing is not allowed. Using the route by interface approach may be problematic where multiple servers support the same interface behind a firewall, or where it is desired to have flexibility in the choice of a server without changing the proxy s policy. The CORBA 3 Firewall Specification also has this limitation since it specifies a well-known port for CORBA servers. Using a well-known port or ports will limit the amount of CORBA servers per host. 3. Security Issues for Distributed Object Messaging 3.1 Security Protocol Handlers The MPOG determines the expected security protocol of the incoming distributed object messaging based on the incoming port destination. Failure to establish a security association with the expected security protocol causes immediate termination of the connection from the outside client. Currently two protocol handlers are developed in MPOG: the Secure Socket Layer (SSL) handler and the non-secure handler. The non-secure handler uses an unencrypted communication channel created by TCP/IP socket. The non-secure handler may be used in the corporate-to-corporate environment where encryption of messaging and authentication of users may not be necessary. The non-secure handler may be used with other security measures available in the MPOG to determine the trust rating and domain (OO-DTE domain, see next paragraph) of a client based on the IP address of the source. The IP address may be useful as the sole attribute from the client connection for access control determination when Virtual Private Networks (VPNs) are utilized between client and servers. The MPOG SSL protocol handler acts as the endpoint of an incoming SSL session by performing an SSL handshake during which the client authenticates to the MPOG which operates as a server. The purpose of the SSL handshaking phase is to negotiate the supported cryptographic parameters between the client and server [2]. Following the cryptographic selection, compression and cipher suites are negotiated. Next, the server sends a certificate according to the cipher suite s key exchange algorithm (the MPOG utilizes X.509 certificates). The client then authenticates itself to the MPOG using the appropriate client 2

4 certificate. Assuming the client s certificate is signed by a trusted certificate authority (CA), communications proceed using established session keys for encryption of the traffic between the client and the MPOG. The attributes associated with the client side X.509 certificate are utilized for assigning the client to an Object Oriented Domain Type Enforcement (OO-DTE [3]) domain. Once the client is authorized for a given method call or a given method call on a given object the MPOG creates a connection to the distributed object server. The server side authentication is similar to that of the client side authentication. The server side protocol handler in the MPOG can be separated from the client side protocol handler by associating the requested interface with a security protocol. 3.2 Access Control The MPOG access control mechanism has been developed in a manner that decouples the access control decision from the distributed object message handling. This was accomplished using the JavaBean constrained property mechanism to develop an access control JavaBean. The access control JavaBean is passed the security context, which may include the attributes associated with the security protocol of the connection and information on the requested object. Based on the security context, the authorization decision is made by the installed JavaBean, which currently performs authorization using Trust Management Language (TMEL [2]), Domain Specification Language (DSPEL [2]), and OO-DTE [5,6]. The separation of components allows experimentation with other access control mechanisms, and also allows the current access control mechanism to be easily experimented with in other projects. 3.3 Domain Derivation OO-DTE domain derivation is based on the security mechanism/attribute/value trio. An attribute may be an X.509 certificate field, an IP address, or a hostname. The language can also be extended to support other security mechanisms as they become available. During the initialization and policy updates of the MPOG a file in the DSPEL is processed. The DSPEL allows security mechanism/attribute/value rules to be logical ands, ors and nots. The first matching rule for a domain places the client connection, or user making that connection, to the MPOG in the corresponding domain name 3.4 Trust Management Although domain derivation described in the previous section associates a domain with the incoming connection, all user or incoming connections associated with a domain may not be trusted at the same level. TMEL can be used to specify the trust level of all credentials issued by a particular authority, e.g. all X.509 certificates issued by a certain CA should be trusted at a certain level. There is a specified minimum trust rating that all attributes of a credential must meet in order for the credential, as a whole, to be considered trustworthy. For example, all certificate attribute values (i.e., issuer_name, subject_name, key bit length, etc.) must have a trust rating greater or equal to the minimum trust rating in order to consider the certificate as a whole to be trustworthy [2]. If any of the attributes have a trust rating below the minimum, then access is disallowed. 3.5 Per-Object Access Control The OO-DTE plug-in utilized in the MPOG makes access decisions for an incoming distributed object call after the domain is derived and the trust rating is determined. The incoming distributed object call specifies an operation, interface, and possibly an object name. The per-object access control relies on assigning unique identifiers (object names) to objects. A mechanism for defining per-object access for CORBA requests has been developed using CORBA interceptors. Using the operation, interface, and if 3

5 specified, the object name, a type can be derived using DTEL++ policy files. The DTEL++ policy files can be generated for CORBA, by utilizing a DTEL++ compiler on modified CORBA IDL files containing type information. Currently, DTEL++ compilers are not available for Java RMI or DCOM, however, there are plans to extend the DTEL++ compiler to other distributed object technologies. The DTEL++ policy files are currently hand crafted for Java RMI; this approach may be utilized for DCOM handling. The files either generated by the compiler or by hand contain: 1) tables that bind to methods and 2) domain definitions that are described in terms of the types that can be invoked and implemented [4]. Types that can be invoked may be called by Java RMI, CORBA IIOP, or DCOM clients. The types that can be implemented allow Java RMI, CORBA IIOP or DCOM servers to support clients of these calls. If the server or client does not have the appropriate rights to implement or invoke the object, the access is denied. 4. MPOG Message Handling 4.1 IIOP Handling The CORBA IIOP was introduced by the OMG to provide ORB interoperability. Prior to the IIOP specification, ORB vendors used transports that did not interoperate with other ORB vendor s transports, since this was not stated in the specifications. Today, many CORBA ORB vendors support their legacy transport and IIOP for interoperation with other vendor s ORBS. The General Inter-ORB Protocol (GIOP) specification describes a standard transfer syntax (low-level data representation) and set of message formats for communications between ORBs. The IIOP specification describes the exchange of GIOP messages over a TCP/IP connection. There are seven GIOP message types that must be handled by the MPOG IIOP handler: Request, Reply, CancelRequest, LocateRequest, CloseConnection, Fragment, and MessageError. Of special interest to the MPOG is the request header in the request message from the client to the server. The request header contains a request id, object key, and operation name ORB Compatibility CORBA utilizes an object reference for interoperability between multi-vendor ORBS. The Interoperable Object Reference (IOR) is the data structure that contains this information. The object key is an opaque value that is a member of the IOR data structure. The client passes the object key to the CORBA server, which must map the object key unambiguously onto a corresponding object. The object key may contain an interface name, a server hostname, and an object name. Currently, the MPOG has been tested with the Inprise Visibroker ORB and the Iona Orbix ORB. The handling of the object key is the main area where testing of ORB compatibility with the MPOG is necessary, since there are no standardized fields and it is vendor specific. SSL authenticated IIOP connections are another area in which ORB compatibility testing with the MPOG is necessary. The MPOG has been tested with SSL authenticated IIOP connecting clients from both the Inprise Visibroker ORB and the Iona Orbix ORB. Due to incompatibilities with SSL Reference 3.0, the Iona Orbix ORB is incompatible with the MPOGs SSL IIOP handling. The MPOG supports IIOP versions 1.0 and Role-Based Access Control Role-Based Access Control (RBAC) decisions are based on the roles that individual users take on as part of an organization. A role specifies a set of transactions that the user can perform within the context of an organization. RBAC mechanisms have been integrated into the MPOG using a Role-Based plug-in. The Role-Based plug-in makes a decision on the authority of a user to utilize a certain role based on credentials of the user. The specified role is determined by the service context field in the IIOP request, if 4

6 a requested role is not specified as in the RMI and DCOM case, the default role for a given credential is utilized. The GIOP request and reply headers contain a Service Context List, which is utilized by ORBs to pass service data from a client to a server. A CORBA interceptor is utilized to add the role information to the service context in the IIOP messages. The OO-DTE plug-in uses the requested role as a parameter in its access decisions. Client Host Firewall Server Host Pentium 133 Mhz with 32 MB RAM Sun Ultra M H Z with 64 MB RAM Pentium 166 Mhz with 64 MB RAM Figure 2: Performance Test Performance Comparisons An Inprise Visibroker 3.0 ORB was utilized to create a CORBA client and server test application. The test application was modified to include the OO-DTE interceptors and the Visibroker SSL package was utilized for all client and server communications. The performance on an operation per CORBA interface basis was measured from the start of the request until the reply was received. In order to evaluate the overhead associated with the MPOG, the MPOG was compared against the performance characteristics of the Gauntlet plug proxy using the hardware described in Figure 2. A large amount of the MPOG proxy overhead can be attributed to establishment of another SSL connection between the MPOG and the CORBA application server. For very lightweight operation calls a comparison of SSL to Non- SSL CORBA server application calls results in a nearly 100% performance decrease. For the above scenario, the comparison of the MPOG proxy attributed to a 155% decrease in performance for very lightweight CORBA operation calls. It should be noted that as the processing time of the CORBA server operation calls increased this performance hit was greatly reduced. For CORBA server operations requiring 100 seconds of server processing time the performance reduction was only 22% [5]. 5

7 Server Host Registry 2 Lookup request RMI Client 3 Remote Object 1 Bind Remote Object to string 4 RMI Streams RMI Server Figure 3: Standard Java RMI Messaging 4.2 RMI Handling The RMI wire transport protocol [6] uses both a direct TCP/IP socket and HTTP for transport. The RMI transport layer normally attempts to open direct sockets to hosts on the Internet. On failure, the RMI call data is sent using HTTP either to a proxy server or the server depending on the setup. The HTTP transport allows RMI through proxies, but calls using HTTP are at least an order of magnitude slower than those sent direct over a socket. The HTTP transport doesn t provide any added security, also the HTTP approach only bypasses the firewall, and doesn t perform an authorization decision. The MPOG handles the direct socket attempt by the client, since handling of HTTP transport would not provide any advantage over the primary transport handling for RMI. Object Serialization is a Java specific term, which is used to describe the formatting of Java primitives and objects into streams of bytes. The RMI data over either a direct socket or HTTP uses Object Serialization as the data format. The primary RMI wire transport protocol is represented by a stream, which can be either in or out. Both the in and out stream contain headers which contain protocol information along with data formatted using Object Serialization [7]. To distinguish one remote method call from another, RMI uses an Object Identifier in the stream along with an operation number. The Object Identifier is a unique identifier for the remote object being called, it is composed of an address space identifier that is unique with respect to a specific host, and an object number. The Object Identifier, operation number, and the port/hostname of the server must be available in order to perform access control and routing of Object Serialized RMI messages. The RMI Transport layer creates a representation of the connection to the remote neighbor, which is called a live reference. The live reference class contains the host name and port number information. 6

8 Since the Object Identifier is dynamically assigned from the Java Virtual Machine (JVM), the MPOG policy must be continuously updated as RMI servers (or remote objects) enter and leave. Policies based on RMI interfaces and its associated operation names can be static since the string names are static, but the mapping based on Object Identifiers must be dynamic. Generally RMI clients locate servers using the RMI Registry. The RMI server registers the Remote Server Objects via the method call bind() of the Naming class. The Registry process runs on the same host as the RMI Server, and RMI clients connect to the registry directly using a known port and hostname. Figure 3 describes the current passageways of Java RMI traffic from registering of the server to client look up, and followed by client invocation, and setup of the Object Streams between the client and server. Firewall 4 RMI Streams MPOG RMI Client 2 Update Policy 3 Lookup request 5 RMI Streams MPOG Registry 1 Registration of remote objects with object identifiers, ports, host and operation numbers Server Host RMI Server Figure 4: Modified Java RMI Messaging The Java RMI Registry lookup model is unacceptable for protection of RMI servers behind a firewall. The Java RMI Registry model would require clients to directly connect to the server host and would not give the MPOG an opportunity to obtain the Object Identifiers. Our solution to this problem is to replace the standard Java RMI Registry with a new type of Registry on the firewall that can be used to locate 7

9 remote objects behind the firewall. We call this replacement registry the MPOG Registry; connections to the MPOG Registry are based on SSL authentication, since the ability to connect and look up remote object references also provides the ability to replace existing object references defined by string names with other object references. Thus, authenticated clients can potentially cause a Trojan horse threat or a denial of service attack. Future enhancements to the MPOG Registry may be made to restrict registration of an RMI server interface to principals with specific X.509 credentials. Figure 4 shows the improved RMI architecture that is more appropriate for firewall interoperation Modifications to the RMI System Several modifications have been made to the Java RMI system. The Java RMI source code had to be modified to obtain object identifiers, live reference information (port and host), operation names, and operation numbers. The above mentioned information was maintained in non-serialized classes which was, in most cases, private attributes without public methods for obtaining the data. The UnicastRemoteObject class was modified to register every Remote Object with the MPOG Registry. This is a major difference from the standard operation of the Java RMI system, where only a start up object is registered, and further remote object references can be returned by method calls. The standard RMI was unsatisfactory, as discussed previously, since all of the mappings from the Object Identifiers to the remote objects would not be defined for the MPOG. The modified UnicastRemoteObject performs a standard RMI method to the MPOG Registry. The UnicastRemoteObject constructor was modified to include two additional parameters: the MPOG host name, or IP address; and the MPOG Registry port number. The RMI client must connect directly to the MPOG Registry to locate the Remote Object reference. This information can be passed in as command line arguments to the RMI client, in order to provide added flexibility to the application Access Control on Object Stream The MPOG Registry invokes an RMI method call of the MPOG to inform it of configuration updates. Connections from clients to the specified internal ports will only be granted access to the remote object which maps to the Object Ids which are associated with that server port for the remote object. Therefore, mappings from Object Ids to remote objects are not global to the RMI Handling system of MPOG, but are defined per service port. The RMI Streams are set in response to a client request and are maintained through the duration client and server communication unless access is denied for any operation or due to invalid object stream formats. Currently, only RMI Output Streams specifying a protocol type of Stream Protocol are allowed. Two other protocols exist according to the Java RMI Specification, the Single Operation and Multiplex protocols. Remote objects do not currently appear to have access to these protocols. The Object Ids are parsed from the Object Serialization stream and compared to Object Ids of known remote objects. If a mapping is not possible a no permission exception is propagated to the client and the streams are closed. Access control decisions can be determined once the mappings to valid remote objects and operation names have been made Performance Comparisons Utilizing the same configuration as described in Figure 2, a lightweight JDK 1.2 RMI operation call was repeated 1000 times from an client external to the firewall to an internal server and the average roundtrip transaction time was compared between a Gauntlet plug proxy and a MPOG proxy. The overhead associated with RMI operations resulted in a 2500% decrease in performance when the MPOG proxy was 8

10 utilized. The inefficiencies in the JDK 1.2 RMI protocol were attributed to the substantial decrease in performance as compared when the MPOG proxy was utilized for access decision on CORBA traffic. The overhead of the RMI packet inspection was quite large, and was attributed to the RMI wire protocol being less network friendly in comparison to CORBA IIOP. CORBA IIOP packages messages into request messages from the client and reply messages from the server. Although fragmentation is possible the packets in general are segmented very efficiently. On the other hand, the RMI wire protocol sets up 2 pairs of streams, which correspond to a TCP/IP s input and output streams from the client to the server and vice versa. Once these streams are set up the Java Object serialization protocol is utilized on these connections to transfer objects. These objects may not be packaged efficiently. Also, MPOG must also search these streams in an inefficient manner, since unlike the CORBA IIOP messaging, objects can be introduced several times in the same packet. When using CORBA IIOP, it is only necessary to search the request and the reply header for object names DCOM Handling DCOM is simply a high-level network protocol designed to allow Component Object Model (COM) based components to interoperate across a network. DCOM is the network enabling glue that sits in the middle of Microsoft COM. To provide this transparent access to remote COM objects, the COM libraries have been enhanced to allow object creation on other machines. In order to be able to create a remote object, the COM libraries need to know the network name of the server. Once the server name and the Class Identifier (CLSID) are known a portion of the COM Libraries called the service control manager (SCM) on the client machine connects to the SCM on the server machine and requests creation of this object. Due to the lack of use of Microsoft DCOM in DARPA projects, actual implementation of per object access control on DCOM messaging has been postponed. However, DCOM tunneling capabilities and DCOM parsing of Remote Procedure Calls (RPCs) through MPOG has been implemented Generic Protocol Handling As mentioned earlier, the MPOG architecture is very modular and additional handlers for TCP based protocols can be easily integrated. To take advantage of the per object access control, the TCP stream must contain an object name, which can be mapped to access rights in the OO-DTE policy files. 5. Conclusions The MPOG demonstrated that a relatively lightweight firewall proxy could perform access control on distributed object programming models. The MPOG performs packet inspection at the socket level for CORBA IIOP, and also handles Java RMI and Microsoft DCOM in this fashion. As demonstrated by the performance experiments for Java RMI and CORBA IIOP, the cost of adding the MPOG proxy is dependent on the distributed object protocol s network efficiency. The performance numbers for a CORBA request (discussed in section 4.1.3) shows that as the server processing time for operations increase the addition of the MPOG in the path has a minor decrease in performance. Additionally, this project demonstrated that an application proxy server written in Java can provide reliable, platform independent code at a reasonable overhead in comparison to C or C+ code. The introduction of a run-time interpreted language as a firewall proxy is controversial, since a firewall is perceived as a network component in which optimization techniques should be utilized in coding to produce better performance. However, the introduction of just in time (JIT) compilation techniques in 9

11 Java compilers have considerably reduced the extra overhead associated with Java code. The JIT compilation techniques can limit the overhead in relation to C or C++ code to 50% to 200%. However, if added speed is desired, tools that translate Java code to native code can be utilized. These tools may provide overhead that compares more favorable to that of C or C++ code. References [1] CORBA 3 CORBA/Firewall Security + Errata Specification. OMG orbos/ Document. July 6, [2] Sigma Interoperability Results and Recommendations. NAI Report #0767. NAI Labs The Security Research Division of Network Associates. December 8, [3] Scalable Access Control for Distributed Object Systems. D. Sterne, G. Tally, D. McDonell, P. Pasturel, D. Sames, D. Sherman, E. J. Sebes, To be published in Proceedings of the 8 th Usenix Security Symposium, August [4] Scalable Access Control for Distributed Object Systems. D. Sterne, G. Tally, D. McDonell, P. Pasturel, D. Sames, D. Sherman, E. J. Sebes, To be published in Proceedings of the 8 th Usenix Security Symposium, August [5] Performance Testing of the Multi-Protocol Object Gateway. D. Sames, D. Sherman, S. Pawlish., NAI Report # NAI Labs The Security Research Division of Network Associates. February 26, [6] Java Remote Method Invocation Specification, Revision 1.4, Sun Microsystems. Feburary 10, [7] Java Object Serialization Specification, Revision 1.4.1, Sun Microsystems. October 8,