Security - Telenor

More documents

Recommendations

Info

Figure 4-1 3 Levels of different firewalls 56 Application Transport (IIOP/TCP) Network (IP) from a client object in the enclave of a group, for example the Research Lab, over the Internet, to a server object in a server enclave. It passes from the client object to the firewall of the Research Lab, then to the firewall of the department, then to the firewall of the organisation, then over the Internet to the server side firewall, and finally to the server object. Such cascading presupposes the ability of invocations to pass through a series of firewalls even when the latter do not use the same technology. 3.5 Transparency A CORBA firewall should be transparent to users (application programmers, administrators and end-users). Schreiner [11] has proposed a transparent firewall that allows a client object to use the normal IOR of the server object instead of a proxified address. The client attempts to connect to the server object as though no firewalls were present. The firewall intercepts the request and launches a proxy object, which relays the request to the server object. In Schreiner’s opinion this will make things simpler for programmers and administrators since it obviates the need for proxification and will only work if the incoming side uses an officially assigned IP address. It occurs to me, however, that the use of officially assigned IP addresses will limit the use of dynamic IP addresses. Will the use of interceptor and smart agent technologies be the trend in the development of the new generation of firewall technologies? 3.6 Interoperability As described earlier, firewalls have two distinct duties, inbound protections that are used to control external access to internal resources, and outbound protections that are used to limit the outside resources that should be accessed from within the enclave. In order for an ORB to establish a connection to an object in another ORB, outbound and inbound firewalls that need to be traversed must be known. Information about outbound firewalls is specified in the client side ORB, and information about inbound firewalls may also be specified in the case of Intranet and Extranet configurations. Application proxy objects (socket, request header & body) IIOP/TCP proxy, SOCKS (socket & request header) Packet filter (IP header) In general, however, the client side knows nothing about the server side, so that the only interoperable way of giving the client access to the information about inbound firewalls is to have this information included in the IORs provided by the server. 3.7 Management A CORBA firewall needs a secure interface through which administrators can configure it remotely and manage security policies. The functionality of this interface should permit the security policy to be configured dynamically. Preferably the firewall should be auto-configurable. Such functionalities are of paramount importance in the dynamic world of the Internet, since closing down a site is inconvenient and can be costly. The management functionality must also support key management interfaces if the firewall is to be involved in the encryption and decryption process as described above. CORBA firewall management should also be integrated into the organisation’s overall security management systems, especially into CORBA <strong>Security</strong> Services [9] management. 4 The OMG Firewall Proposal The Joint Revised Submission on CORBA Firewall <strong>Security</strong> (submitted in response to the OMG Firewall RFP (Request for Proposal)) [8] specifies the use of IIOP in network firewalls for controlling access to CORBA-based applications from Internet, Intranet or Extranet, and specifies and describes how inter-ORB interoperability through such firewalls can be achieved. According to the Joint Revised Submission, firewalls are broadly speaking of two kinds (in contrast to Figure 4-1), transport level and application level firewalls. The former permit or deny access to different resources using different application level protocols on the basis of addressing information in the headers of transport packets, and thus on the basis of where things are coming from or going to, and not what is being accessed. The latter, on the other hand, are in addition restricted to granting or denying access to particular application level protocols, such as IIOP or HTTP, and to those resources known to the application protocol. Consequently, they can grant or deny access on the basis of both addressing information and specific resources. Figure 4-1 shows the operation of three different types of firewall. Each type operates on the basis of information available at a specific level, application level, transport level or network level. At the transport and network levels, IIOP can be handled like any other TCP/IP-based application protocol. This means that well-known firewall techniques like packet filters and transport-level proxies can be used. Telektronikk 3.2000
On transmission, the message body at the application level is encoded in CDR (Common Data Representation). CDR then translates IDL (Interface Definition Language) data types into a byteordering independent octet string. For such an octet string to be decoded back to IDL data type, the interface definition of the object is needed. This information, however, is not as a rule at the firewall with the result that the firewall is unable to decode the message body. This means that an IIOP proxy cannot base filtering decisions on the request body [11]. Since the mechanisms involved in interaction with a firewall will vary with the type of firewall, it is necessary to have a precise definition of which types of firewall are supported in CORBA if ORB interoperability is to be achieved. In this connection, the current joint revised firewall submission proposes three types of firewall (see below) for use in different situations [8, 11], a TCP firewall for simple and static applications, a SOCKSv5 [16] proxy for clientside firewalls, and a GIOP application level proxy for enforcing fine-grained security policies (especially on the server-side). 4.1 TCP Firewalls A TCP Firewall is a simple firewall that operates at the transport level, basing its access control decisions solely on information in TCP headers and IP addresses. When a connection request is received on a given port of the firewall, the firewall establishes a connection to a particular host and port. In the course of this process the firewall uses the combination of host address and port () to authenticate the client on the basis of the IP address alone. Having established the connection, the firewall will allow GIOP messages to pass through uninterrupted. In other words, ORB protocols are of no significance to a TCP firewall. A simple form of ORB interoperability through TCP firewalls can be achieved without any modifications to CORBA. TCP firewalls must be statically configured with host/port address information in order to process access requests. The server can then be configured to replace its own host/port address with that of the firewall in its IOR for use outside the enclave. How this is implemented varies with the situation. One method is to proxify the IOR manually. The client thus receives an IOR containing the address of the firewall rather than that of the server, and sends GIOP messages to the firewall (which forwards them to the server) under the impression that is where the server is. Due to the tradition of TCP/IP using one port per service, it is common practice to identify a TCP service by the port number used for the server. Telektronikk 3.2000 As a result, most of today’s firewalls make lowlevel access control decisions on the basis of port used. Since there is no well-known “IIOP port”, this practice does not facilitate ORB interoperability through TCP firewalls. As part of its proposed solutions, the OMG has defined a recommended “well-known IIOP port” and a “wellknown IIOP/SSL port”. This will enable client enclaves with TCP firewalls to permit access to IIOP servers by enabling access to this port through their firewalls. The OMG’s firewall RFP points out that, while these ports are not mandatory since IIOP servers can be set up to offer service through other ports, the ports serve as a basic guideline for server or TCP, SOCKS or GIOP proxy deployment, and make it possible for client enclaves to identify or filter immediately the traffic as IIOP without processing. 4.2 SOCKS Firewalls The SOCKS [16] protocol is an open Internet standard (IETF RFC1928) which performs network proxying at the transport layer, mainly on the client-side. SOCKS creates a proxy which is transparent to either party, and which serves as a data channel between clients and servers based on TCP or UDP. In this case a client can have control over which server it wishes to connect to, in contrast to the situation when normal static mapping of TCP connections by a TCP proxy is used. A SOCKS firewall could then reasonably be referred to as a “dynamic TCP proxy”. SOCKS consists of a SOCKS proxy server on the firewall and a client-side library. In the client program the normal network calls of the socketinterface have to be replaced by the corresponding calls of this SOCKS library, and the process is called ‘socksification’. The server is unchanged. The socksified client calls the corresponding functions of the SOCKS library. These SOCKS functions communicate transparently with the client and server over the SOCKS proxy server on the firewall. Figure 4-2 shows a typical scenario of a client communicating with an application server through a SOCKS firewall. There are six phases to the communication process: In the first, the client authenticates itself to the SOCKS proxy server, and if successful, the process proceeds to Client application linked with SOCKS client library 1 2 3 5 SOCKS proxy server Relay data Figure 4-2 SOCKS proxy firewall traversal scenario 4 6 Application server 57
Page 2 and 3:
Telektronikk Volume 96 No. 3 - 2000
Page 4 and 5:
Øyvind Eilertsen (34) is Research
Page 6 and 7:
4 E(P) = a ⋅ P + b (mod 26) D(C)
Page 8 and 9: 6 In 1997, NIST initiated the proce
Page 10 and 11: 8 decrypt the signed hash value, re
Page 12 and 13: Lars R. Knudsen (38) is Professor a
Page 14 and 15: Table 1 Timetable for AES Table 2 T
Page 16 and 17: 14 K m i Stream cipher algorithm Fi
Page 18 and 19: 16 6 Use of Encryption in Telecommu
Page 20 and 21: 18 mode, integrity mode, key divers
Page 22 and 23: 20 7 Beaver, D. Computing with DNA.
Page 24 and 25: 22 In both cases, my trust depends
Page 26 and 27: 24 A number of standard PC applicat
Page 28 and 29: Henning Wright Hansen (28) is Resea
Page 30 and 31: 28 Securing Locally Stored Informat
Page 32 and 33: Figure 3 A simple Public Key Infras
Page 34 and 35: 32 The Policy Control Center An imp
Page 36 and 37: Tønnes Brekne (31) is on leave fro
Page 38 and 39: 36 Sets definable by such predicate
Page 40 and 41: 38 A failure is caused by some type
Page 42 and 43: Figure 1 This figure illustrates th
Page 44 and 45: 42 ating system(s) and/or platform
Page 46 and 47: Message Sender Recipient Message pa
Page 48 and 49: 46 Assume some agent a carries with
Page 50 and 51: 48 gateway from attack, while the i
Page 52 and 53: 50 transfer at the expense of secur
Page 54 and 55: 52 7 FORE Systems. Firewall Switchi
Page 56 and 57: Figure 2-1 Object invocations throu
Page 60 and 61: 58 phase two, in which the client r
Page 62 and 63: 60 5 CORBA Firewall Traversal 5.1 F
Page 64 and 65: 62 7.2 Visibroker Gatekeeper of Inp
Page 66 and 67: 64 References 1 Abie, H. An Overvie
Page 68 and 69: Cost Figure 1 Minimising total cost
Page 70 and 71: 68 In the coming years it is likely
Page 72 and 73: 70 financial, social, environmental
Page 74 and 75: Consequence 72 Insignificant Substa
Page 76 and 77: 74 in a one week time-frame, using
show all

Security - Telenor

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?