1 / 71

Making r11 Agent Technology talk through a Firewall

Making r11 Agent Technology talk through a Firewall. Last Updated 12/19/2005. 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

qiana
Download Presentation

Making r11 Agent Technology talk through a Firewall

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Making r11 Agent Technology talk through a Firewall Last Updated 12/19/2005

  2. Agenda • Introduction • Secured Remote MDB setup • Worldview Discovery • Configuring DIA for firewall • Managing CA Agents using DIA

  3. 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

  4. 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

  5. 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

  6. 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

  7. Testing Environment DMZ Server dawya01v05 Secured Zone MDB Server = I14y204

  8. Secured Remote MDB setup

  9. 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?

  10. DMZ NSM Install MDB Firewall Ingres Client Ingres Server 19016 DMZ Secured Zone

  11. DMZ NSM Install

  12. DMZ Install NSM

  13. Select Secured MDB Connection Fails as Ingres Client port not opened

  14. Ingres Client Shows port 19016 is blocked.

  15. 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>

  16. Ingres Ports Unix Source ported to Windows

  17. 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

  18. Open Ingres Port Ingres Client communicates with the Ingres Server successfully with port opened

  19. Ingres Client This shows Ingres port used to connect to the Ingres Server

  20. World View Discovery

  21. 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

  22. WV DiscoveryInitiated within Firewall SECURED dscvrbe –r .. DMZ MDB

  23. WV DiscoveryInitiated within Firewall • Ping Sweep • ICMP and SNMP opened

  24. WV DiscoveryPing Sweep • Discovery initiated within Firewall • Pingsweep require ICMP port to be opened

  25. WV DiscoveryClassification • SNMP (161) Required for Classification

  26. WV DiscoveryClassification • Additional Ports may be required if “Check Additional Ports” selected

  27. Firewall WV DiscoveryInitiated Outside Firewall No UDP through Firewall MDB Ingres 19016 dscvrbe –r ..

  28. 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”

  29. DIA

  30. Scenario #3 • We wish to configure DIA in a Firewall environment to reduce the number of ports to be unblocked. • What are the considerations?

  31. DIA MDB Firewall DNA Ports 11501 11502 11503 SECURED DMZ DIA UKB DMZ Server DNA Data Ports 11502 11504

  32. 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

  33. 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

  34. 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

  35. Secured Zone: Update ukb.cfg Set PROXY_UKB to Yes

  36. 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

  37. Secured: Active DMZ DNA • Launch diatool from the secured zone which is designated as UKBProxy • Activate DMZ DNA

  38. Secured: Active DMZ DNA Enter DMZServer Hostname

  39. Secured: Active DMZ DNA Activation Complete

  40. DMZ • Verify the DNA is activated correctly and reporting to the UKBProxy in Secured zone • Review ukb.dat file on the DMZServer

  41. DMZ - Verification This points to Secured Zone UKB, which is correct

  42. 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

  43. Secured Zone – UKB Proxy

  44. Secured Zone: UKB DMZ DNA Local DNA This shows DNA has been activated for DMZ server

  45. DNA Registration Port - 11501 Outbound Traffic

  46. DMZServer  UKBProxy Inbound Traffic responding via the active connection

  47. DNA RMIPORT - 11502 Outbound Traffic

  48. DMZServer  Secured : Port 11504

  49. DIA Ports

  50. UKB 11503 Port • This port is used by consumers, such as UMP, to communicate with UKB

More Related