the Corba/Java Firewall

Transcription

1 Firewall Security for Corba and J2EE/EJB with the IIOP Domain Boundary Controller Corba and Java-RMI based applications can be directly and securely made accessible to users outside the internal network, i.e. outside the firewall, by adding an IIOP Domain Boundary Controller component to the exisiting firewall installation. This security gateway solution provides uncompromised firewall security and complete 4A security for Corba and EJB servers. Xtradyne White Paper March 2003 the Corba/Java Firewall Copyright Xtradyne Technologies AG, All Rights Reserved. Xtradyne is a registered trademark of Xtradyne Technologies AG. All other brand or product names are trademarks or registered trademarks of their respective owners.

2 Contents 1 Introduction The Problem IP Addresses and Port Numbers Packet Filter Firewalls IIOP over the Internet IIOP to the Webserver Network Address Translation Virtual Private Networks are not enough! Xtradyne s Response I-DBC Architecture The screened subnet architecture I-DBC Proxy Security Policy Server and Administration Console Functionality Firewall Traversal Replacing the address information in an IOR Passing IORs as parameters High Availability and Scalability High Availability and Scalability on system level High Availability and Scalability on the application level High Availability and Scalability as provided by the I-DBC A Functionality Authentication Authorization Administration Auditing Summary Acronyms Executive Summary Enterprise application systems based on the middleware technologies Corba and Java-RMI (for example IBM Websphere and BEA Weblogic) use IIOP as the protocol interface to the business logic. If the access to Corba or EJB servers has to pass firewall installations, an additional security gateway must be added to the existing firewall installation, otherwise the firewall security is seriously at risk. Xtradyne's IIOP Domain Boundary Controller enables the secure firewall traversal of IIOP interactions, and additionally provides detailed security controls (4A) for the business logic to be protected. This white paper covers the special security problems of IIOP and firewalls, the productized solution, and typical operation issues such as scalability and high-availability. Copyright Xtradyne Technologies AG, All Rights Reserved. Page 2

3 1 Introduction In today's networked economy, more and more corporate networks are linked together, either directly or via the Internet. Base technologies for application and enterprise integration are CORBA middleware and EJB application servers. Normally, the enterprise's security is maintained through firewall installations at the edge of the enterprise's own network, ensuring authentication, authorization, encryption, and security auditing. Unfortunately, standard firewall technology does not provide the means to securely run CORBA and EJB based distributed applications through existing firewall installations: CORBA and EJB middleware does not work together with traditional firewall concepts, and traditional firewalls do not provide application level security, such as fine-grained access control. The Xtradyne IIOP Domain Boundary Controller enables the operation of CORBA and EJB based applications through existing firewall installations without weakening the security provided by the latter; and the IIOP Domain Boundary Controller provides all application level security functionality needed, such as user authentication, user and operation based access control, SSL encryption, and detailed security auditing and logging. 2 The Challenge There are two essential problems when trying to use the Internet Inter-ORB Protocol (IIOP) across today s firewalls: Location-transparency and the dynamic allocation of addresses as done by CORBA middleware make it difficult to know in advance the host and port addresses used for transactions. Addressing information contained in an object reference is invalidated when crossing a Network Address Translating router. 2.1 IP Addresses and Port Numbers IP addresses and TCP port numbers play an essential role in the binding between a client and a remote target object. Generally, CORBA clients rely on the addressing information contained in Interoperable Object References (IORs) to contact CORBA servers: they establish a direct TCP connection to the target server, using the IP address and port number found in the IOR of the target object. Unfortunately a CORBA server creating an IOR is typically not aware of any firewall filtering or address translation performed at domain boundaries. 2.2 Packet Filter Firewalls A packet filter firewall located between client and server is likely to be configured in a way that remote invocations 1 are blocked. The application will be unable to complete the request. To enable all remote invocations on objects behind the packet filter firewall, the firewall would have to be opened for connections to all hosts running CORBA servers. A broad range of port numbers would have to opened on the firewall: any port a CORBA server could be listening on which is potentially any non-privileged port. Considering the security implications of such a firewall configuration, this is not an option. The protection at the domain boundary would be severely compromised. 1. In this paper the term remote invocation denotes a CORBA request or an RMI over IIOP request respectively. Copyright Xtradyne Technologies AG, All Rights Reserved. Page 3

4 2.2.1 IIOP over the Internet The problem appears as soon as IIOP traffic has to pass a packet filter firewall, regardless of the location of this packet filter firewall. In the most obvious case, IIOP is spoken end-to-end over the Internet and thus has to cross packet filter firewalls at the border to the public Internet IIOP to the Web Server In another, less obvious case, a servlet enhanced web server uses HTTP to interact with clients over the Internet but uses IIOP internally when its servlets access business logic implemented inside the intranet. Usually, web servers or application servers that are accessible from the public Internet are separated from the intranet with packet filter firewalls. Thus, the IIOP traffic between the servlets at the web server and internal application servers must pass at least one packet filter firewall. Also, in large organizations, firewalls separate different divisions or departments. Any CORBA service which needs to cross department boundaries, is faced with the firewall problem. 2.3 Network Address Translation The previously described problems become even more severe if Network Address Translation (NAT) is used. In this case, an IOR produced by a CORBA server behind the NAT packet filter firewall contains the IP address of the server host in the local network. If this IOR is delivered to external clients on the other side of the NAT firewall, any connection attempts to the CORBA server using the IP address contained in this IOR will fail. The internal IP address is not valid in the public Internet. NAT routers are not only employed at Internet boundaries. They are also used internally, for example after a corporate merger to connect the two networks. 2.4 Virtual Private Networks are not enough! A common approach for establishing extranet configurations involves the use of Virtual Private Networks (VPNs). Here, encrypted links across the public Internet tunnel traffic from one domain to another. Often client domains cannot be made part of a VPN. Further problems arise when an individual domain which is part of the VPN has a security hole, e.g. an uncontrolled channel to the public Internet. In this case, any partner domain attached via the common VPN to this insecure domain is at risk. That is, in addition to protecting the tunnels across the public Internet, the connection of the VPN to each domain must be protected by a firewall. This firewall enforces the separation of domains with regard to the security responsibilities and trust relationships. If CORBA middleware is applied, the firewall causes exactly the same problems as described in the previous sections. 3 Xtradyne s Response The only viable solution to the aforementioned problems is an application layer firewall. The XTRADYNE IIOP Domain Boundary Controller (I-DBC) is a functionally enhanced IIOP firewall component. It is applied as part of an existing firewall installation at the domain boundaries between an administrative domain and the exterior network (i.e. the Internet). Operating as an application-layer gateway for IIOP, the I-DBC protects the Intranet from illegal access while enabling inter-domain interactions of distributed business applications. The I-DBC is a plugable security solution, the business applications do not have to be adapted. The product is suitable for use with any distributed CORBA 2 or CORBA 2.x compliant applications as well as with Enterprise Java Beans using RMI over IIOP. Xtradyne s IIOP Domain Boundary Controller provides the following features: Copyright Xtradyne Technologies AG, All Rights Reserved. Page 4

5 Secure and Controlled Firewall Traversal: The I-DBC inspects and modifies IIOP messages and headers passing through, thus enabling a secure and controlled transmission of CORBA requests and replies across packet filter firewalls and NAT-Routers, for details please refer to section 5.1. High Availability and Scalability: For high availability and/or scalability demands multiple I-DBCs can be operated in a cluster. The service of the I-DBC will still be provided even if some hardware or software component fails. A failover mechanism will use a replica of a failed component. For scalability demands a traffic redirector is used to distribute requests amongst I-DBCs, for details please refer to section A Functionality: The I-DBC enforces fine-grained access control, thus guaranteeing that only trusted peers can connect and provides mechanisms Authentication, Authorization, Auditing and Administration, for details please refer to section I-DBC Architecture The I-DBC system is an infrastructure building block modularized into a number of components that may be physically separated: the I-DBC Proxy, the Security Policy Server and the Administration Console. I- DBC components can be distributed onto multiple hosts, located in different subnets. To provide a high level of security these subnets can be protected by packet filtering routers. In environments with less stringent security requirements a single node can host all I-DBC components. 4.1 The Screened Subnet Architecture Perimeter Network SMTP Proxy Protected Network Internet HTTP Proxy to the Protected Network to the Perimeter Network Security Policy Server Admin Console CORBA Server Exterior Router I-DBC Proxy Interior Router Log Host LDAP Server Logical View of I-DBC Components Internet Secure and Controlled Firewall Traversal to the Protected Network to the Perimeter Network Authentication Authorization Auditing Administration Figure 1 I-DBC Components in a typical deployment Scenario Copyright Xtradyne Technologies AG, All Rights Reserved. Page 5

6 The most typical firewall architecture used in sensitive environments with high load is the screened subnet architecture, depicted in the upper part of figure 1. The lower part of figure 1 presents the abstract logical view of I-DBC components. Located in between two routers inside the perimeter network, dual-homed host computers provide a very high level of control by running various types of application-level gateways, e.g. an SMTP or HTTP Proxy. Towards the Internet, the perimeter network is protected by an exterior router which permits connections to only a small set of services. At the border to the internal network, the interior router protects the internal network both from the Internet and the perimeter network. Direct access from the public Internet will be completely blocked by the interior router thus providing a layer of protection redundancy. Note that each of the routers may be configured to perform Network Address Translation (NAT) I-DBC Proxy Xtradyne s I-DBC Proxy is typically run on such a dual homed host as described in the screened subnet architecture. All CORBA traffic between clients in the public domain (Internet) and servers in the protected domain is routed through the I-DBC Proxy. The I-DBC Proxy supports strong encryption with full key length to ensure confidentiality and integrity on both external and internal links. Whenever the I- DBC Proxy needs to access security relevant information, e.g. access control information or a resolved host name, it sends a request to the Security Policy Server to obtain the requested information Security Policy Server and Administration Console The Security Policy Server (SPS) and Administration Console are typically located on hosts inside the internal network, i.e. behind the I-DBC Proxy and any existing packet filters. The SPS is a centralized server that comprises components that support Authentication, Authorization, Auditing and Administration. These components interact to provide controlled and accountable access to resources at application servers in the internal network. The SPS provides the I-DBC Proxy with authentication and authorization decisions. The Security Policy Server and the Admin Console can interwork with the security information storage server, e.g., the enterprise s LDAP Directory Servers to enable the integration of the I-DBC security policy with the enterprise user and group management system. The Administration Console allows for handy configuration of the I-DBC offering a graphical user interface for set up and maintenance. The Admin Console can be run remotely communicating with the Security Policy Server using plain IIOP or IIOP over SSL. 5 Functionality 5.1 Firewall Traversal When a client wants to use a service offered by a CORBA server, it needs an Interoperable Object Reference (IOR). If the service can be contacted via TCP/IP, the initial IOR for that service contains among other things a TCP address 1 to denote the contact point at which the object can be reached. When an IOR is created by the server s ORB, the TCP address will be the address of the service as known to the ORB Replacing the address information in an IOR Sometimes the address contained in the IOR cannot be used to contact the CORBA server. In this case the IOR has to be proxified, i.e. the TCP address in the IOR is replaced with another TCP address - the 1. A TCP address consists of a host name or IP address together with a port number. Copyright Xtradyne Technologies AG, All Rights Reserved. Page 6

7 one of the IIOP Proxy, so that clients will contact the I-DBC Proxy instead of the real Server. Proxification of IORs is necessary when: A firewall blocks direct access to the server. The address contained in the IOR is unreachable from the Internet, i.e. the server runs on a non-routed IP address (e.g *). The traffic is redirected through I-DBC Proxy to perform access control. After converting the original IOR into a proxified IOR, the address in the proxified IOR is then reachable from the public network. Instead of providing the client with the original IOR, as done for clients which can directly connect to the server, the proxified IOR will be exported to the client application in the public domain Passing IORs as parameters Another situation requiring IOR Proxification is the passing of IORs as parameters in CORBA calls. The I-DBC Proxy automatically detects passing IORs and proxifies them accordingly in both directions. 5.2 High Availability and Scalability The following section presents how high availability and scalability can be achieved with the I-DBC. A more detailed description can be found in the corresponding white paper. For a start, here is a definition of the terms High Availability and Scalability: High availability (HA): The service of the I-DBC will still be provided even if some hardware or software component fails. This is achieved by replicating components of the I-DBC to eliminate single points of failure and providing health monitoring facilities. In case a component fails, a failover mechanism will use a replica of the failed component. Scalability: Adapt the service of the I-DBC to fit higher requirements in terms of number of clients, demands in throughput or latency. Scalability can be achieved in several ways. The type of scalability addressed in this section is obtained by operating multiple I-DBCs in a cluster. A traffic redirector is used to distribute requests amongst I-DBCs High Availability and Scalability on system level An external mechanism (on protocol level) is usually called cluster management software. A central part of this cluster management software is the traffic redirector. Examples for cluster management software are Sun Cluster 3 or Linux Virtual Server. When clients of the service are not aware of high availability and scalability requirements, it is necessary to use a cluster management software. Typically this software presents the cluster host as a single virtual host and provides a single virtual IP-address to the client. The traffic redirector of the cluster management software simply redirects network traffic from a failed or overloaded component to another working and less busy one in a way possibly transparent to the client High Availability and Scalability on the application level The other possibility is to make the client aware of redundant components, thus providing high availability and scalability on the application level. This usually requires a higher development effort, but there are benefits: the application can be tailored more precisely to the requirements it has to fulfill. This includes but is not restricted to: faster failover, behavior based on knowledge about the failure state of components, better dynamic load balancing, improved stickiness of sessions. Besides, it saves the money for the cluster management software. Copyright Xtradyne Technologies AG, All Rights Reserved. Page 7

8 5.2.3 High Availability and Scalability as provided by the I-DBC The I-DBC offers several mechanisms to support high availability and scalability: In general, the recommended configuration uses at least the traffic redirector of a cluster management software at the domain boundary and does application level HA and scalability between I-DBC Proxies and Security Policy Servers (see figure 2). In other words, the I-DBC uses system level HA and Scalability towards its clients, but application level HA and Scalability internally. Therefore, an I-DBC installation can consist of multiple Security Policy Servers which constitute the Security Policy Server Cluster. All Security Policy Servers are configured the same way so that any of those Security Policy Servers can serve requests from any client. I-DBC Proxy Cluster Sec. Pol. Server Cluster From/ to the external domain I-DBC Proxy 1 Sec. Pol. Server 1 Traffic Redirector I-DBC Proxy 2 Sec. Pol. Server 2 Figure 2 Recommended High Availability / Scalability configuration Standard clients of these Security Policy Servers are the I-DBC Proxies. An I-DBC installation can have multiple clusters of I-DBC Proxies. Each I-DBC Proxy in a cluster shares its properties with any other I- DBC Proxy in the same cluster. In the standard case (as depicted in figure 2), a cluster management software will be running this cluster, distributing the traffic from the clients amongst the I-DBCs in this cluster. A typical cluster would consist of at least two I-DBC Proxies. The I-DBC Proxies are clusteraware. They interoperate with the cluster management, i.e. they supply the cluster management with a state information from which the cluster management can see if an I-DBC is still providing its service. Towards the Security Policy Servers, the I-DBC Proxies can do application-level high availability and scalability themselves. I-DBC Proxies failover to another Security Policy Server autonomously. Therefore, it is not necessary to have a separate cluster management installation for the Security Policy Server. Multiple I-DBC Proxies statically distribute the load to the Security Policy Servers A Functionality The Xtradyne I-DBC protects against illegal access and potentially malicious IIOP messages by including robust authentication, authorization, administration, and auditing features (4A) Authentication The authentication features in the I-DBC determine the identity of a sender and verify the accuracy of the claim. The I-DBC currently supports the following authentication mechanisms: anonymous access (no authentication) Copyright Xtradyne Technologies AG, All Rights Reserved. Page 8

9 IP source address (IP-based authentication) usernames and passwords (HTTP basic authentication) public-key systems using X.509 certificates (SSL / TLS) RSA SecurID Each mechanism provides a different type of security protection and requires a different type of configuration. Since the I-DBC performs authentication in a transparent manner, applications do not need to be modified to make use of this functionality Authorization The authorization features in the I-DBC determine which resources a client may access and which operations it may request a service to execute. The I-DBC enforces access control policies based on a resource s IOR as well as the operation name in a request. The I-DBC offers role-based access control (RBAC) for the various access control and permission levels. Access control policies are managed according to resources, roles, users, and groups, which are easily configured with the I-DBC Admin Console Administration Figure 3 Screenshot of the Admin Console: Defining Access Control Policies The I-DBC Admin Console is a key part of the I-DBC. The I-DBC Admin Console is an intuitive, advanced graphical user interface for managing security policies, audit event notifications, public-key certificates, SSL profiles, and other configuration settings. System administrators use the console to change network settings, security properties, and auditing levels (for an example console see screenshot below). The following types of security policies can be configured with the I-DBC Admin Console: Copyright Xtradyne Technologies AG, All Rights Reserved. Page 9

10 authentication How does a sender authenticate itself? What mechanisms are allowed? access control What resources may an authenticated user access? Can a client access the whole service or just particular operations? message protection Are IIOP messages cryptographically protected to ensure message integrity? auditing Which events does the I-DBC monitor and record? Auditing The auditing features of the I-DBC keep track of resource usage, monitor access, and evaluate success or failure events within the system. With the I-DBC Admin Console, a system administrator can determine which events generate a notification. The resulting success and failure records create an audit trail for evaluating intrusion detection responses, performing post-mortem security analysis, or generating transaction evidence. The I-DBC currently generates the following types of audit events: operational status, such as startup/shutdown activities as well as resource allocation warnings connection status, such as accepted, established, or closed requests as well as protocol handshake success and failures authentication status, such as successful and failed attempts authorization status, such as access allowed or access denied conditions policy status, such as IOR exposure, policy changes, or license expiration For each event, the I-DBC captures a date, time and the reason for generating the event. With the I- DBC Admin Console, a company can monitor access to services and track the exchange of IIOP messages. 6 Summary The XTRADYNE IIOP Domain Boundary Controller (I-DBC) is an application-layer firewall dedicated to the controlled and secure transfer of IIOP traffic across an enterprise s domain boundary. The I-DBC analyzes the structure of IIOP messages and headers passing through. It makes selective forwarding decisions and enforces fine-grained access control at object and operation level. The processing of IIOP messages enables distributed business applications to operate across existing packet filter firewalls without compromising the protection established at the enterprise s domain boundary. There is no need to modify existing CORBA or EJB based business applications. The I-DBC supports arbitrarily complex CORBA and EJB based business-to-business applications as well as inter- and intra-organization information systems. The I-DBC integrates with existing user and policy management by using LDAP enabled directory servers. While being independent of specific ORB products, it supports elementary special features of leading CORBA and EJB products, e.g. of BEA, IBM WebSphere, Borland, Sun and IONA. 7Acronyms CORBA I-DBC Common Object Request Broker Architecture IIOP Domain Boundary Controller Copyright Xtradyne Technologies AG, All Rights Reserved. Page 10

11 EJB HTTP IOR LDAP NAT RMI SMPT SSL VPN Enterprise JavaBeans Hyper Text Transfer Protocol Interoperable Object Reference Lightweight Directory Access Protocol Network Address Translation Remote Method Invocation Simple Mail Transfer Protocol Secure Socket Layer Virtual Private Network About Xtradyne Xtradyne is a security software vendor offering application-level proxies and security gateways built specifically to address the needs of large corporations and enterprises. Xtradyne's runtime products help companies extend their automated business processes beyond corporate firewalls towards partners without compromising security. Application-level security implemented by Xtradyne's turnkey security solutions provide a very economic way to address the increasing needs for security in CORBA, J2EE, and XML Web Services. Due to Xtradyne's unique approach, additional security can be added with minimal time to market, extremely reduced reengineering costs, and very low total costs of ownership. Further information: Xtradyne Technologies Xtradyne Technologies Schoenhauser Allee 6/ Connecticut Ave. NW Berlin Washington, DC Germany USA Phone +49-(0) Phone Fax +49-(0) Fax info@xtradyne.com Copyright Xtradyne Technologies AG, All Rights Reserved. Page 11