HP Software Universe Tutorial on DCE Daemonless and Outbound Communication

HP Software Universe
Hamburg, Germany -12th -14th November
Tutorial id: fr-1130/2

© 2003 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice
HP Software Universe
DCE daemonless and outbound-
only communication with HP
OpenView Operations
fr-1130/2
Volker Gaertner & Stefan Bergstein
OpenView R&D
November 14th 2003

November 12th-14th, 2003 HP Software Universe
Agenda
Why bother? What’s the problem?
DCE-daemonless communication (Volker Gaertner)
1. Current DCE RPC communication
2. DCE RPC communication without endpoint mapper
3. Configuration on managed nodes and management server(s)
4. Examples
Outbound-only communication (Stefan Bergstein)
1. The problem: no inbound connections allowed
2. SSH Functionality - concept of tunneling and port forwarding
3. OVO outbound-only using SSH tunnel
4. Configuring OVO - using SSH port forwarding

Why bother?
What’s the problem?

Managed environment
OVO Sever
managed node
OVO Agent
managed node
OVO Agent
managed node
OVO Agent
Operator UI
managed node
OVO Agent
managed node
OVO Agent
managed node
OVO Agent
Firewall Firewall Firewall
outbound outbound
outbound
InternetDMZ
customer site
Intranet
1
2
3
4
5
Normally, OVO requires
inbound communication on
port 135 and other ports,
but this can be avoided
with the daemonless
communication and SSH
tunnels
inbound
135
inbound
135
attack on port 135
or DCE lookup and
then attack on
another port

Current problems
• Recent virus attacks on port 135 (not only on Windows!)
– Customers don’t want to open port 135 on their firewall at all
– Shutdown the port mapper (dced) on system in the DMZ
• Inbound communication
– Current concept: message agent sends alarm/message
immediately to inform operator as fast as possible (no polling)
– Requires inbound communication (agent initiates communication)

Current DCE RPC
communication

Current DCE RPC Communication
1. RPC server starts up.
Either the RPC server (via opcinfo
variable) or the OS selects the
port on which the RPC server will
be listening.
The RPC server registers itself with
this port at the local DCE
endpoint mapper*.
2. The endpoint mapper stores this
information in its database.
RPC
client
endpoint
mapper
(port 135)
RPC
server
1
2
* dced on Unix, RPC Service on Windows
endpoint
mapper DB

Current DCE RPC Communication
3. The RPC clients starts and does
not know the server's port.
It queries the endpoint mapper
with
– the type of server it wants to
contact
– and some additional interface
specification uniquely
identifying the target server.
4. The endpoint mapper returns the
port number.
5. The RPC client can now contact
the desired RPC server directly.
RPC
client
endpoint
mapper
(port 135)
RPC
server
3 4
endpoint
mapper DB
5

DCE RPC Communication
without Endpoint Mapper

w/o Endpoint Mapper
A. The RPC server starts up.
It reads its port from the opcinfo variable
(OVO agent) or registry key (OVO/W
management server)
OPC_COMM_PORT_RANGE.
It does not register anywhere and simply listens
at this port.
RPC
client
RPC
server
A
opcinfo
Win registry

w/o Endpoint Mapper (cont.)
B. The RPC client determines from its local
configuration that the RPC server must be
contacted without an endpoint mapper
lookup.
It reads the name of the server port
specification file from opcinfo or the
registry
C. The RPC client reads the desired RPC
server port from the server port
specification file, based on the server
type and target node.
D. The RPC client now contacts the RPC
server directly.
RPC
client
RPC
server
D
opcinfo
Win registry
opcinfo
Win registry
port config
C
B

OVOW deamonless communication
OVOW server
1
server
• message action server is using one
customer defined port
• message action server and the deployer
can communicate directly to agent
(without remote DCE lookup)
agent
• no endpoint mapper on agent
• control agent (opcctla) is using one
• control agent does not register at local
endpoint mapper
• message agent can communicate directly
to server (without remote DCE lookup)
Available remote functionality:
No change – everything is possible 
1) start action, tools (apps),
start/stop/status of agent,
HPB via RPC only
2) deliver messages, action status,
annotations
3) remote policy/instrumentation
deployment
OVO agent
opcctla
msg/act
server
deployer
opcmsga
rpcd
2
Firewall inside
outside
port 135
policies,
act,cmd,
monitor
3
port 12001
port 12003port 135
rpcd
RPC Server
Endpoint mapper
RPC Client

OVOU deamonless communication
OVOU server
RPC ServerEndpoint mapper RPC Client
1
server
• message receiver (opcmsgrd) is using one
customer defined inbound port
• distribution manager (opcmsgrd) is using one
• request sender can communicate directly to
agent (without remote DCE lookup) using
only outbound ports
agent
• control agent (opcctla) is using one customer
defined outbound port
• message and distribution agent can
communicate directly to server (without
remote DCE lookup) using each one inbound
port
Available remote functionality
No change – everything is possible 
HPB via RPC only
2) deliver messages, action status, annotations
3) remote policy/instrumentation deployment
(RPC only)
OVO agent
opcctla
opcmsgrdovoareqsdr
opcmsga
rpcd
2Firewall inside
outside
port 135
policies,
act,cmd,
monitor
3
port 12001
port 12003
opcdistm
opcdista
port 12002
port 135
rpcd

OVOU deamonless communication
w/o deployment
OVOU server
RPC Server
Endpoint mapper
RPC Client
1
server
only outbound ports
agent
• control agent (opcctla) is using one
customer defined outbound port
• message agent can communicate directly
to server (without remote DCE lookup)
using one inbound port
• manual policy/instrumentation deployment
(via opctmpldwn) [3]
Available remote functionality
HPB via RPC only
2) deliver messages, action status,
annotations OVO agent
opcctla
opcmsgrdovoareqsdr
opcmsga
rpcd
2
Firewall inside
outside
port 135
policies,
act,cmd,
monitor
3
port 12001
port 135
rpcd
port 12003

Configuration

White papers
• Detailed configuration information can be found in the
corresponding white papers for OVOW and OVOX:
“DCE RPC Communication Without Endpoint Mapper”
• OVOW:
– http://openview.hp.com/sso/getdoc?doc=/500/products/oper
ations_for_windows/tech_whitepaper/ovowin72_twp_dce_comm
_jul03.pdf (channel web / ask your HP representative)
• OVOX:
– http://ovweb.external.hp.com/ovnsmdps/pdf/dce_em_unix_a07
15.pdf (or http://ovweb.external.hp.com/lpe/doc_serv )

New configuration variables
try to contact the server’s endpoint mapper if no local configuration is foundKey Type Value Explanation
COMM_REGISTER_RPC_SRV String TRUE or
FALSE
Register/do not register RPC interfaces with endpoint
mapper
OPC_COMM_LOOKUP_RPC_SRV Bool TRUE or
FALSE
Contact/do not contact endpoint mapper (if no local
configuration is found)
OPC_COMM_PORT_MSGR Int One
number
Specifies at which port the message interface of the
Message Action Server is listening on the
Management Server(s).
OPC_COMM_PORT_DISTM Int One
number
Specifies at which port the distribution interface of the
Message Action Server is listening on the
Management Server(s).
OPC_COMM_RPC_PORT_FILE String Full path If set, it points to a port specification file with
dedicated ..msgrd, …distm and opcctla entries per
target

• File syntax:
– Standard OVO patterns can be used.
– Empty lines are accepted.
– Comments start with “#” but must be the very first character
– Configuration data must be specified using 4 standard elements, separated
with white spaces:
– SelectionCriteria
NODE_NAME Node name pattern or exact match1
NODE_ADDRESS IP Addresses pattern or exact match1
– SrvType
opcctla Management Server contacting the Agent
opcmsgrd Message Agent contacting the Mgmt. Server
opcdistm Distribution Agent contacting the Mgmt. Server
– Port Port number to contact this RPC server
– Node Node name or address pattern for this rule.
Port Specification File - Syntax

Examples

Port Specification File (Managed Node)
Example port specification file on a managed node:
#
# SelectionCriteria SrvType Port Node
# ----------------------------------------------------------------
NODE_NAME opcmsgrd 5000 primaryserver.hp.com
NODE_NAME opcdistm 5000 primaryserver.hp.com
NODE_NAME opcmsgrd 6000 backupserver.hp.com
NODE_NAME opcdistm 6001 backupserver.hp.com
Primaryserver.hp.com is an OVOW server where the distm and msgrd interface are using
the same port (5000)
Backupserver.hp.com is an OVOX server where the opcdistm process is listening on a
different port (6001) than the opcmsgrd (6000).

Port Specification File (Server)
Example port specification file on the management server:
#
# SelectionCriteria SrvType Port Node
# ----------------------------------------------------------------
NODE_NAME opcctla 12345 <*>.hp.com
NODE_ADDRESS opcctla 12346 15.136.<*>
NODE_ADDRESS opcctla 12347 ^192.<1 -lt <#> -lt 10>.<*>
NODE_ADDRESS opcctla 12347 1.2.3.4
On all nodes ending with hp.com the opcctla can be found on port 12345.
On nodes out of the IP-range 15.136.<*> it uses 12346.
etc…

COMM_PORT_RANGE
"5000"
COMM_REGISTER_RPC_SRV
TRUE
COMM_LOOKUP_RPC_SRV
TRUE
OVO managed node “A” OVOW mgmt server “X”
registry
COMM_RPC_PORT_FILE
"/tmp/ports"
/tmp/ports
# Entry type Server Port Node
# -----------------------------------------------------
NODE_NAME opcctla 11111 A
NODE_NAME opcctla 22222 B
OVO managed node “B”
opcinfo
..RESTRICT_TO "opcctla"
..PORT_RANGE "11111"
..MGMT_SERVER "X"
..PORT_DISTM “5000"
..PORT_MSGR "5000"
opcdista
opcctla
opcmsga
OvEpMsg
ActSrv
Example A:
one OVOW mgmt server
..RESTRICT_TO "opcctla"
..PORT_RANGE “22222"
..MGMT_SERVER "X"
..PORT_DISTM “5000"
..PORT_MSGR "5000"
opcdista
opcctla
opcmsga

Example B:
one OVOW, one OVOU mgmt server
opcmsga
opcdista
OVO managed node "A"
opcinfo..MGMT_SERVER "X"
OvEpMsg
ActSrv
COMM_PORT_RANGE
"5000"
registry
opcmsgrd
opcdistm
OVOU mgmt server "Y“
RESTRICT_TO "opcmsgrd"
PORT_RANGE "5555"
RESTRICT_TO "opcdistm"
PORT_RANGE "6000"
opcsvinfo
mgrconf
/tmp/svports
# Entry type Server Port Node
# -----------------------------------------------------
NODE_NAME opcmsgrd 5000 X
NODE_NAME opcmsgrd 5555 Y
NODE_NAME opcdistm 5000 X
NODE_NAME opcdistm 6000 Y
..PORT_FILE "/tmp/svports"
RESPMGRCONFIGS
SECONDARYMANAGER
NODE IP "0.0.0.0" X
SECONDARYMANAGER
NODE IP "0.0.0.0" Y
[...]
OVOW mgmt server "X"

Required patches
Server side:
V HP-UX 11.0/11.11 PHSS_28962 05-MAY-03
V Solaris ITOSOL_00226 09-MAY-03
Agent side:
on HP-UX 11.0/11.11 server
V AIX PHSS_28949 14-MAY-03
V HP-UX 10.20 PHSS_28959 07-JUL-03
V HP-UX 11.0/11.11 PHSS_28958 06-MAY-03
V HP-UX 11.22 PHSS_28960 07-JUL-03
V Linux PHSS_28951 30-MAY-03
V NTIntel PHSS_28943 08-MAY-03
V Solaris PHSS_28948 12-MAY-03
V Tru64 PHSS_28950 30-MAY-03
on Solaris server
V AIX ITOSOL_00220 09-MAY-03
V HP-UX 10.20 ITOSOL_00224 04-AUG-03
R HP-UX 11.0/11.11 ITOSOL_00239 (planned)
V HP-UX 11.22 ITOSOL_00225 31-JUL-03
V Linux ITOSOL_00222 30-MAY-03
V NTIntel ITOSOL_00217 23-MAY-03
V Solaris ITOSOL_00219 09-MAY-03
V Tru64 ITOSOL_00221 30-MAY-03
Server side:
V Windows A.07.20
Agent side:
on Windows server
HP-UX agent A.07.20
Windows agent A.07.20
Solaris agent A.07.20
AIX agent OVOW_00035

Outbound-only communication
using SSH port forwarding
- An advanced use case -

Overview
• The Problem: No inbound connections allowed
• SSH Functionality and Benefits
• Concept of SSH tunneling and port forwarding
• OVO outbound-only using SSH tunnel
• Configuring OVO
• Using SSH port forwarding
• Summary and FAQ

The Problem: No inbound connections allowed
OVO Sever
managed node
OVO Agent
managed node
OVO Agent
managed node
OVO Agent
Firewall Firewall
outbound outbound
DMZIntranet
managed node
OVO Agent
managed node
OVO Agent
managed node
OVO Agent
Internet
outbound only
• Some companies don’t allow any
inbound connections into their Intranet
• Firewall administrators don’t open any
inbound port.
OVO agent
• message agent sends messages,
annotations, actions status, etc to the
management server
• distribution agent requests
configurations (templates, actions,
cmds, etc) from to the management
server
• both are inbound connections because
the agent initiates the communication
objective
• get rid of the inbound connection with
the DCE daemon-less feature and SSH
port forwarding
• full functional agent

SSH Functionality and Benefits
SSH Functionality:
• SSH secure command shells
• SSH port forwarding
• Secure file transfer protocol
The Benefits of SSH:
• Network security
• Strong authentication
• Public key cryptography
• Password authentication
• Host authentication
• Data encryption

The Features of SSH
The major features of SSH are:
• Customization: Can be customized to meet network or user requirements.
• Authentication: Provides strong authentication by using rhosts combined with RSA.
• X11 Sessions: Secures X11 sessions.
• Encryption: Encrypts data being transferred across the network. SSH uses various
types of ciphers, such as IDEA, DES, and triple−DES for encrypting data.
• Secures the network against various attacks, such as spoofing and packet sniffing.
• Arbitrary TCP/IP ports: Redirects ports through the encrypted channel in both
directions.
• Replacing traditional rlogin, rsh, and rcp services
• Replacing insecure programs
• Provides improved privacy encryption of all communications.
• User and Host authentication key: Uses 1024−bit host authentication keys.

mypc
Concept of SSH tunneling and port forwarding
8880
50123
SSH
tunnel
#
#ssh -n –N -R 50123:hello:8880 mypc
Example with a web server and browser:
WWW Server
hello.com:8880
http://hello.com:8880
http://hello.com:8880
http://localhost:50123
http://localhost:50123

OVO outbound-only using SSH tunnel
OVOU server
RPC ServerEndpoint mapper RPC Client
1
server
• distribution manager (opcdistm) is using one
only outbound ports
ssh tunnel
• message receiver and distribution manager
port are forwarded to the managed node
• tunnel is imitated from the server (outbound)
agent
• no endpoint mapper on agent needed
• control agent (opcctla) is using one customer
defined outbound port
• message and distribution agent communicate
to localhost (127.0.0.1)
OVO agent
opcctla
opcmsgrdovoareqsdr
opcmsga
rpcd
2
Firewall inside
outside
port 135
3
port 12001
port 12003
opcdistm
opcdista
port 12002
port 135
rpcdport 12001port 12002
Outbound
SSH tunnel

Configuring OVO
OVO Sever
DMZ
Intranet
Firewall outbound
Firewall
outbound
Internet
privpub
managed node
OVO Agent pub
managed node
OVO Agent pub
ssh tunnel OPC_RESOLVE_IP 127.0.0.1
OPC_DIST_MODE DIST_RPC
OPC_COMM_LOOKUP_RPC_SRV FALSE
OPC_COMM_PORT_MSGR 5000
OPC_COMM_PORT_DISTM 5002
OPC_RESTRICT_TO_PROCS opcctla
OPC_COMM_PORT_RANGE 12345
opcinfo
ACTIONALLOWMANAGERS
NODE IP ip_adr_of_mgr ““
mgrconf
OPC_RESTRICT_TO_PROCS opcdistm
OPC_COMM_REGISTER_RPC_SRV TRUE
OPC_RESTRICT_TO_PROCS opcmsgrd
OPC_COMM_REGISTER_RPC_SRV TRUE
opcsvinfo
for all nodes in DMZ
ssh –n –N
–R 5000:ovoserver:5000
–R 5002:ovoserver:5002
node

Using SSH port forwarding
• SSH2 must be installed and configured on all systems
• Port forwarding is initiated on the OVO server. E.g.,
# ssh -R 5000:mgmt_srv:5000 -R 5002:mgmt_srv:5002 managed_node
• Tunnel must be started for each node in DMZ.
• Useful ssh options:
-v : Verbose mode. ssh prints debugging messages.
-l login_name : user to log in as on the remote machine.
-N : Do not execute a remote command. Just forwarding ports.
-n : Redirects stdin from /dev/null. This must be used when ssh is
run in the background.
Note, don’t use –g. This allows remote hosts to connect to
forwarded ports.
• Public key of ‘server user’ shall be installed on managed
nodes, so that login without password can be done.

Create and exchange SSH user keys
Create and exchange user keys so that the management server can login into the
managed node without entering a password:
• Create on the management server user keys:
# ssh-keygen -t rsa
# ssh-keygen -t dsa
• Copy public keys to agent:
# cd ~/.ssh/
# scp *.pub agent
if needed, accept fingerprint this will add the agent in ~/.ssh/known_hosts
• Add public keys on agent:
# ssh agent
# cat id_rsa.pub >> .ssh/authorized_keys
# cat id_dsa.pub >> .ssh/authorized_keys
# rm id_rsa.pub id_dsa.pub
# exit
• You should now be able to connect from "server" to "agent" without a
password prompt.

OVO SSH tunneling at a Glance
The major benefits are:
• Outbound-only communication
• All standard agent features are available like on any other system.
• Customization on agent and server uses ordinary OVO Firewall and DCE
daemon-less features.
• Additional buffering and encoding of messages etc is not required.
Prerequisites to use this solution:
• SSH2 on all participating systems
• Certain custom code to start, stop, and monitor your SSH tunnels is
required
• Firewall must allow outbound SSH communication

FAQ (1)
• Does this work also with OVOW?
Since the DCE Daemon-less works equally, you can do this with OVOW, but you
have to consider that policy deployment works differently. Furthermore, the
Service Discovery agent has additional in-inbound connection.
• Is outbound-only communication with SSH port forwarding a supported
OVO feature?
This is not a feature. It is an use case of the DCE Daemon-less functionality. All
shown OVO keys and parameters are well-known features. OVO neither bundles
nor deliver any SSH. HP OpenView does not provide any support for SSH itself.
• Does OVO provide any functionality to manage the SSH keys?
No. You have to configure, run, and maintain your SSH by your own.
• Is there any SSH recommended for this use case?
No, but tests were successful with:
HP-UX 11.0 T1471AA A.03.50.000 HP-UX Secure Shell
HP-UX 11.11 T1471AA A.03.50.000 HP-UX Secure Shell
Win 2000 OpenSSH for Win 3.6.2p1 (Cygwin)

FAQ (2)
• Can I use port forwarding for M2M messages forwarding?
Yes. Note that you have to configure on the source server an
OPC_COMM_RPC_PORT_FILE with NODE_NAME opcmsgrd 5000 localhost.
• How is the scalability and performance of this use case?
Be aware that you have to start for each managed node a ssh client on the
management server. The ssh client does not need much resources, but you have
to manage these processes by your own.
• Do I have to run the tunnels under root/Administrator? No.
• Where can I find further information about SSH?
E.g., OpenSSH Manual pages: http://www.openssh.org/manual.html
• Where can I find further information about used OVO parameters?
– OVO DCE RPC Communication without Endpoint Mapper White Paper
– OVO Firewall Configuration White Paper

HP Software Universe Tutorial on DCE Daemonless and Outbound Communication

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to HP Software Universe Tutorial on DCE Daemonless and Outbound Communication

Similar to HP Software Universe Tutorial on DCE Daemonless and Outbound Communication (20)

More from Stefan Bergstein

More from Stefan Bergstein (13)

Recently uploaded

Recently uploaded (20)

HP Software Universe Tutorial on DCE Daemonless and Outbound Communication