HP -UX B6941-90001, Справочное руководство администратора

Страница: 369 / 548

Chapter 9 369
An Overview of ITO Processes
Secure Networking
Secure Networking
ITO’s concept of securing a network is based on the idea of improving the
security of the connection between processes either within a network or
across multiple networks as well as through routers and other restrictive
devices. For example, you could limit access to a network or a section of a
network by restricting the set of nodes (with or without ITO agents
running on them) that are allowed to communicate with the
management server across restrictive routers or even a packet-filtering
firewall. It is not important to ITO which element, the server or the
network of managed nodes, is inside or outside the firewall. For example,
a network of nodes inside a firewall could be managed by a management
server outside the firewall. Conversely, a management server inside a
firewall can manage nodes in or outside.
One way of limiting access to a network and consequently improving the
network’s inherent security would be to restrict to a specific range of
ports all connections between ITO processes on the management server
and a managed node. To simplify matters, ITO sets the default value on
the managed node to “No security” and allows you to select the security
configuration node by node. In this way, the administrator can change a
given node’s security level depending, for example, on whether or not
there is a need for a given node to communicate across a firewall or
through a restricted router.
The RPC Client/Server Connection
A connection between an RPC-server and an RPC-client needs at least
two ports: one on the server machine, one on the client. Each ITO process
that is either an RPC client or RPC server has its own port for
communication: the port remains blocked by the ITO process which owns
it until the process exits, whereupon the port becomes free for dynamic
assignment to the next RPC client-server request. For more information
on dynamic port assignment in ITO, see “Processes and Ports” on page
370.
An RPC client using DCE or NCS does not automatically know the port
number of the RPC server on the remote system and, consequently, has
to obtain this information before initiating an RPC request. The first
thing it does is to look up in the LLBD or RPCD on the remote system
the specific port number of the RPC server it needs to talk to: the LLBD