HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

20.8 ENHANCED SECURITY

OpenView supports industry standard system security features. These features introduce multiple layers of security enhancements. Some of these are at the socket layer and go up through the application layer. In this section, we discuss some of the most popular security components available for TCP/IP environments. When the enhanced security options are installed on the management server, you have the option to choose the security method to configure on a node-by-node basis.

20.8.1 Data Encryption Standard (DES)Private Key

DES is a single-symmetric key used for encryption and decryption. The key is a single large random-number (from 64 up to 128 bits), used by the client and server to encrypt and decrypt messages. Here is an example of how the algorithm works: Node A sends a message that is encrypted with the

fully qualified domain name (FQDN) of the node. A message arrives at the server after transmission over the network is decrypted using the client's FQDN. When authenticated, the message moves to the next upstream process. The message is decrypted and authentication of the server is performed on the managed node by a decryption routine.

20.8.2 RSAPublic Key

Developed by Ronald Rivest, Adi Shamir, and Leonard Aldeman, RSA differs from DES because the encryption algorithm uses two keys. RSA is based on a standard called

Public-Key Cryptography (PKC). Originally based on the ANSI draft standard X9.42 an algorithm developed by Diffie-Hellman, one key is private and the other key is public. The size of the key generated by the algorithm is up to 512 bits. The PKC servers keep users' public keys. The server validates the users' ownership of their public keys. Here is an example of how the algorithm works: Node A sends a message to server encrypted with the server's public key. At the server, the server's private key is used to decrypt the message. When the server sends a message to the client, it is encrypted with the client's public key and decrypted by the client using a private key known only to the client.

20.8.3 Kerberos

Kerberos was developed as part of the Massachusetts Institute of Technology project Athena (and specified in RFC 1510). Kerberos is an add-on service that provides authentication and can be used with many network protocols including RPC. Kerberos uses

Data Encryption Standard (DES) encryption to protect data as it travels across the network. DES uses tickets (also called keys) that are encrypted with a secret password and the ticket can only be decrypted at the other end with the same secret password. The secret password is stored on the Kerberos server.

The Kerberos server provides a centralized authentication service. This key distribution function is to mutually authenticate clients to servers. There are three services involved in completion of the user or process authentication:

Key Distribution Center (KDC),

Authentication Service (AS), and

Ticket Granting Service (TGS). The six steps in the authentication process are outlined here for reference:

This authentication method initiates the client-server data exchange. Subsequent exchanges do not utilize all six steps and can be summarized as follows:

20.8.4 Distributed Compute Environment (DCE)




Distributed Computer Environment (DCE), developed by the

Open Software Foundation (OSF) provides configuration management, distributed file sharing, remote procedure calls, and user authentication. DCE enhances the Kerberos authentication model by using a combination of packet encryption, time-based authentication credentials, and a security server (called a "trusted third-party"). The DCE security server maintains an access control list similar to a database of users, servers, and security policies (this collection of data is referred to as the registry service). Authenticated RPC requires that each DCE principal (user, application program, computer, DCE cell, or DCE service) use a key known only to the client and the security server. The key is generated from a users secret password and is maintained by the registry service. Clients and servers use authenticated RPC based on the key (also called a ticket). The steps involved with obtaining the ticket are outlined here for reference:




• The RPC client reads its password from the key file on the node.

• The RPC client logs in and gets a login context (name/password) from the security server.

• When authenticated, the RPC client sends the RPC request.

• The RPC server checks the ticket with the password in the key file on the server.

The RPC client on the managed node is the message agent (opcmsga) process. The RPC server on the managed node is the control agent (opcctla) process. On the management server, the message receiver is the RPC server.

The base DCE client components include the shared libraries and daemons (rpcd/dced). Out-of-the-box, the DCE client components include the features for authenticated RPC. The configuration steps must be performed on every node within that will use DCE/RPC security.

The security services are configured on the managed nodes, which become members of a DCE cell. The cell includes a security server located on a managed node or the management server. A utility program called dce_config provides a menu-driven interface to help configure the local node into the cell. When configured for DCE/RPC, the management server will not communicate with nodes that are not members of the DCE cell.

20.8.5 GSS APIs




The

Generic Security Service (GSS)-

Application Program Interface (API) is provided with OVAS as a customizable security solution that enables you to develop and implement your own security requirements. GSS is defined by RFC-2743 and is incorporated as OVO's security protocol. When installed, the GSS functionality is enabled for the managed node communications via

ActionsNodeModifyCommunications . Select Network Security Protocol GSS. This option adds a new line item to the nodeinfo file OPC_NSP_TYPE GSS_API_V2.

OVO ANS only provides the interfaces for a GSS-compliant encryption product to be "plugged-in." OVO ANS does not provide this encryption by itself.

20.8.6 HTTP and S-HTTP




SSL encryption for HTTP ensures the integrity of transactions and the confidentiality of information exchanged via HTTP. The early development of the S-HTTP is a joint effort between

Enterprise Integration Technologies (EIT) and the

National Center for Supercomputing Applications (NCSA) at the University of Illinois and RSA Data Security. Several S-HTTP web servers are based on RSA's public-key cryptography and EIT's Secure HTTP software. S-HTTP provides application-level transaction security and supports digital signatures at the application level. OpenView uses the Public-Key Encryption model provided by Entrust.

Additional information about HTTP and S-HTTP can be found at http://www.dmc.ie/maim2002/mairead/practice/projects/MP4/indesl and http://www.eit.com/projects/s-http. Also refer to the HP OpenView Operations HTTPS Agent Concepts and Configuration Guide.

20.8.7 Secure Socket Layer (SSL)




SSL is an application-independent protocol. Sockets live at layer-5 of the OSI model. Sockets are either connection-oriented or connectionless. Connection-oriented sockets allow data flow (back and forth as needed) between the client and server. As socket, when established, represents the IP address and a known port number and is represented as follows:

10.2.12.14:23 represents the IP address and the well known telnet port

Sockets are used locally for

inter-process communications (IPC) and for Internet connections, as shown in the previous example. In using a TCP Socket, the connection setup uses a file descriptor for subsequent read and write operations. Check the established connections with the command

netstat in from the command line. Basic operation of SSL transmissions include the following steps:




• Client sends server a "hello" message

• Server sends over its certificate (includes server's public key)

• Client creates session-key and sends it encrypted to the server

• Server encrypts future communications with client's session key.

• Additional information about the SSL protocol is available at http://home.netscape.com/security/techbriefs

SSL helps secure the JAVA client console. This prevents eavesdropping of the passwords and message information that traverses the network between the client console and the management server. The client components are a component of the OVAS add-on package. After the OVAS secure JAVA client is installed on the server, distribution to the clients follows the standard procedure via http://<management_server_name>:8880/ITO_OP. The two files installed from the management server are ito_op.jar and ito_ssl.jar. The authentication certificates are generated on the server with the opcca utility provided with OVAS. The certificate is installed on the client in addition to the two (dot) jar files. The handshake protocol is initiated using SSL when you startup the JAVA client console. When the session initiates, the JAVA client GUI displays a closed padlock icon.

20.8.8 PAM Authentication




The

HP Configuration Guide for Kerberos Products on HP-UX states the following about PAM authentication: "HP-UX provides Kerberos authentication as part of the Pluggable Authentication Module (PAM) architecture that is specified in RFC 86 of the Open Group. PAM allows multiple authentication technologies to coexist on HP-UX. A configuration file determines which authentication module to use, in a manner transparent to the applications that use the PAM library."

OVO user accounts exist in two places on the management server, the database and the password file. The account names and passwords for each configured OVO user are authenticated by the PAM modules that are installed on the management server operating system. PAM authentication is configured in the /etc/pam.conf files. The configuration requires valid entries for each user in the OVO database (new users are added via the GUI) and the /etc/passwd file (with entries for all users accounts that access OVO).

20.8.9 SOAP (XML)




The World Wide Web Consortium (www.w3c.org) defines SOAP Version 1.2 as a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

SOAP (XML) technology replaces the DCE-RPCs for use with the HTTPS-based agent.