making r11 agent technology talk through a firewall last updated 12/19/2005

Making r11 Agent Technology talk through

a FirewallLast Updated 12/19/2005

2 © 2005 Computer Associates International, Inc. (CA). All trademarks, trade names, services marks and logos referenced herein belong to their respective companies.

Agenda

- Introduction

- Secured Remote MDB setup

- Worldview Discovery

- Configuring DIA for firewall

- Managing CA Agents using DIA


Objectives

- Requirements of working through a firewall will vary for different sites

- The architecture will be highly dependent on

- Level of risk accepted

- Rules dictated by the firewall administration.

- Rules governing blocking and unblocking of ports.

- This presentation walks through some common scenarios dictated by different security administrations


Firewall Requirements

- Considerations for Firewall

- Reduce the number of ports to be unblocked

- Minimize port Contention

- Block UDP ports

- Minimize the number of hosts that requires ports to be unblocked

- Block traffic initiated from outside firewall


Need for Firewalls

- Exponential growth on Cyber Crime

- Hackers, cyber criminals, e-terrorists

- Problem caused by the denial of service attacks, high-lighted the need for a resilient and secure DMZ environment.

- Secure Internet environments requires Firewalls


Perimeter vs. Host Firewalls

- For this presentation we are only considering Perimeter firewalls.

- There are several consideration for deploying host firewalls and will introduce complexities for r11 if the host firewalls rules are not consistent


Testing Environment

DMZ Server

dawya01v05

Secured Zone

MDB Server = I14y204

Secured Remote MDB setup


Scenario #1

- We wish to deploy NSM in DMZ environment but want to use a MDB which resides in the secured zone

- What are the considerations?


Ingres Client19016

Firewall

MDB

DMZ NSM InstallDMZ NSM Install

DMZSecured Zone

Ingres Server


DMZ NSM Install


DMZ Install NSM


Select Secured MDB

Connection Fails as Ingres Client port not opened


Ingres Client

Shows port 19016 is blocked.


Ingres Client

- Ingres Client (Netserver) requires access to the MDB database residing on the Ingres Server

- This requires Ingres Client port to be opened inbound

- The port number will vary depending on Ingres Instance id.

- The default Ingres Instance is EI

- To translate the Ingres Instance id into the port number, click

- Covert Ingres Port

- Converted Unix source to Windows.

- Mdbport <instanceid> Instance Name Port

II 21064

EI 19016

wv 28336

http://ingresr3.ca.com/~crogr01/php/listenaddress2socket.php


Ingres Ports

Unix Source ported to Windows


Install Process

- Prior to NSM Install in DMZ , get secured MDB Server information including:

- MDB server name and Ingres Install id

- User ID and Password to connect to the remote MDB

- For NSM, this will be nsmAdmin

- For DSM, this will be ca-ITRM


Open Ingres Port

Ingres Client communicates with the Ingres Server successfully with port opened


Ingres Client

This shows Ingres port used to connect to the Ingres Server

World View Discovery


WV Discovery

- Discovery Considerations

- Initiate discovery from inside firewall

- Initiate discovery from outside firewall but MDB inside Firewall

- Temporary Unblock Ports for Auto Discovery

- NAT implication


WV DiscoveryInitiated within Firewall

dscvrbe –r ..

MDB

DMZ

SECURED


WV DiscoveryInitiated within Firewall- Ping Sweep

- ICMP and SNMP opened


WV DiscoveryPing Sweep- Discovery initiated within Firewall

- Pingsweep require ICMP port to be opened


WV DiscoveryClassification- SNMP (161) Required for Classification


WV DiscoveryClassification- Additional Ports may be required if “Check Additional Ports” selected


WV DiscoveryInitiated Outside Firewall

Firewall

dscvrbe –r ..

MDB

No UDP through Firewall

Ingres

19016


WV Discovery Limited Unblocked

- During the auto-discovery process objects are classified using SNMP therefore the SNMP port should be opened.

- Once auto-discovery is complete the port can be closed.

- It is also possible to run discovery outside the firewall then move the data via trix inside the firewall – this is NOT best practice and the customization is “more difficult than is apparent”


Scenario #3

- We wish to configure DIA in a Firewall environment to reduce the number of ports to be unblocked.

- What are the considerations?


DNA Ports115011150211503

Firewall

MDB

DIADIA

DIA UKB

SECURED

DMZ

DMZ Server

DNAData Ports1150211504


Requirements Recap

- From DMZ, connect to the UKB in the secured zone

- DNA from DMZ will be reporting to the secured zone UKB

- This will enable MCC and other GUI to communicate with DNA cells in DMZ

- DIA ports will be blocked inbound with the exception of data port

- DIA ports unblocked for all outbound traffic


Configuration

- Identify the potential candidate for UKB proxy in the secured zone.

- In our case, the most suitable candidate is the MDB server we wish to connect from DMZ

- For performance reason, this should NOT be Master UKB

- Determine if SRV is defined in the DNS in DMZ environment. In most cases, this should not be the case and it is not required for DMZ

- If SRV is defined then additional DIA inbound ports may need to be opened


UKB Proxy

- In the secured zone, update ukb.cfg for the server that will be designated as UKBProxy

- Once updated, restart DIA service to pick up the UKBProxy settings


Secured Zone: Update ukb.cfg

Set PROXY_UKB to Yes


DMZ Server

- Verify DMZ Server is pingable from Secured zone

- This should be the real hostname of DMZ Server

- DIA ports are opened for outbound traffic. The port numbers are configurable in ukb.cfg and dna.cfg files

- Activate DMZ Server using diatools from the secured zone

- Verify the DMZ DNAs are registered correctly


Secured: Active DMZ DNA

1. Launch diatool from the secured zone which is designated as UKBProxy

2. Activate DMZ DNA



Enter DMZServer Hostname



Activation Complete


DMZ

- Verify the DNA is activated correctly and reporting to the UKBProxy in Secured zone

- Review ukb.dat file on the DMZServer


DMZ - Verification

This points to Secured Zone UKB, which is correct


Alternative Activation using Command Line- If GUI interface is not desirable, then DNA can also be

activated using the following command- C:\Program Files\CA\SharedComponents\CCS\DIA\dia\dna\bin\

autoactivatedna.bat


Secured Zone – UKB Proxy


Secured Zone: UKB

This shows DNA has been activated for DMZ server

DMZ DNA

Local DNA


DNA Registration Port - 11501

Outbound Traffic


DMZServer UKBProxy

Inbound Traffic responding via the active connection


DNA RMIPORT - 11502

Outbound Traffic


DMZServer Secured : Port 11504


DIA Ports


UKB 11503 Port

- This port is used by consumers, such as UMP, to communicate with UKB


Conclusion

- DIA / DNA blocked for DMZ inbound traffic with the exception of cgene, data ports 11502 and 11504

- DIA from secured zone determines which DMZ ports are blocked and plugs a hole to eliminate the need to unblock DIA inbound registration ports

Managing CA Agents using DIA


Scenario #4

- We wish to deploy CA Agents in DMZ

- What are the considerations for CA Agents in DMZ to communicate to DSM in the secured zone?


DNA Ports1150111502115039990

Firewall

MDB

DIADIA

Aws_dsm

SECURED

DMZ

CA Agents

DNAData Ports1150211504


Agent Communication - Configuration

- Configuration file

- %AGENTWORKS_DIR\SERVICES\CONFIG\

atservices.ini

- Section [SNMP]

- Parameter ‚UseSnmp‘

- ‚0‘ – DIA only

- ‚1‘ – SNMP only

- ‚2‘ – DIA to CA-Agents (Enterprise OID 791), SNMP otherwise

- ‚3‘ – can do both DIA or SNMP depending on target machine


Agent

SNMP

DNA

UseSnmp = 1UseSnmp = 0UseSnmp = 2

AWS_SADMIN

DSM Communication - ArchitectureManaged Node

AWS_ORB

AWS_AGTGATE

AWS_SNMP

DSM

AWS_ORB

AWS_AGTGATE

ManagerDIA installed

UseSnmp = 3

DIA ActiveDIA Not Active

CA-Agent

(791)Non-CA-AgentCA-Agent

(791)Non-CA-AgentAgent


USESNMP Settings

- If non CA Agents are to be monitored then aws_dsm should be installed in the DMZ.

- If only CA agents are to be monitored reporting to the secured DSM, then set usesnmp to 0.


Default UseSnmp

Default Setting of UseSNMP. Change it to UseSNMP=0 to force DNA communication


Cgene

- With useSNMP set to 0, Agent Technology will communicate with the DSM via DIA ports.

- This will result in cgene send and receive requests between secured zone DSM and CA Agents running in DMZ.

- Requires ports 11502 and 11504 to be opened inbound


Cgene send and receive test

- To verify Agent Technolgy can communicate with DSM via DIA, run cgene tests

- Setup cgene receive request on the secured zone

- Send cgene send to the secured zone DSM from the managed node.


Cgene Send and Receive Tests


DSM View

- CA Agents Discovered correctly without the need to open UDP ports inbound


Nodeview from Secured Zone


Traps via DIA

- Traps communication via DIA


MCC from Secured Zone


Agents Events via MCC


Port 9990

- DMZ aws_orb binds to 9990 for DIA communications


Port 9990

- DIA aws_orb communication via 9990

- aws_dsm and tools sending requests via port 9990


SNMP Traps

- If UseSNMP is set to 3, it will generate SNMP traps


Conclusion

- If configured correctly, then DMZ CA Agents can be managed by the secured aws_dsm without unblocking UDP inbound ports


Questions and Answers

Any questions?Any questions?

making r11 agent technology talk through a firewall last updated 12/19/2005

Documents

trade names

services marks

respective companies

outside firewall slide

dia slide

i14y204 slide

consistent slide

firewall mdb dmz nsm