Firewalls

Extending Network Management Through Firewalls
Design Secure Network Management Solutions Secure Network Management Communications Best Practice for DMZ Management
Stephen Hochstetler Harry Tanner Ramachandra Kulkarni Sebastian Mika
ibm.com/redbooks
SG24-6229-00
International Technical Support Organization Extending Network Management Through Firewalls
June 2001
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix G, Special notices on page 349.
First Edition (June 2001) This edition applies to Tivoli NetView Version 6.01, Program Number 5698-NVW. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 2001. All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Part 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction to firewalls . . . . . . . . . . . . . . . . 1.1 TCP/IP preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Well-known ports . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 High ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 The concept of the firewall . . . . . . . . . . . . . . . . . . . . . 1.3 The components of a firewall . . . . . . . . . . . . . . . . . . . 1.4 Terminologies associated with the firewall . . . . . . . . . 1.5 Firewall architectures . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Screening router . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Bastion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Dual-homed gateway . . . . . . . . . . . . . . . . . . . . . 1.6 Firewall objectives and firewall rules . . . . . . . . . . . . . 1.6.1 Beyond the firewall: filtering content . . . . . . . . . . 1.7 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Case study of VPN . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 . .3 . .4 . .4 . .4 . .5 . .7 . .8 . .8 . .9 . .9 . 10 . 11 . 11 . 12 . 17 . 17 . 19 . 21 . 23 . 23 . 26 . 28 . 30 . 33 . 34 . 35
Chapter 2. Network management . . . . . . . . . . . . . . . . . . . . 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Simple Network Management Protocol (SNMP) . . . . . . . . 2.2.1 IP network communication . . . . . . . . . . . . . . . . . . . . 2.3 Network management with NetView . . . . . . . . . . . . . . . . . 2.3.1 Centralized network management. . . . . . . . . . . . . . . 2.3.2 Distributed network management solution . . . . . . . . 2.3.3 Remote network management access . . . . . . . . . . . 2.4 NetView as part of a Tivoli system management platform . 2.4.1 Tivoli Decision Support (TDS). . . . . . . . . . . . . . . . . . 2.4.2 Tivoli Enterprise Console (TEC) . . . . . . . . . . . . . . . . 2.5 Network management in firewall areas and secure zones
Copyright IBM Corp. 2001
iii
Part 2. Network management environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Chapter 3. Management across a single firewall . . . . . . . . . 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Definition of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 General description of the testing environment . . . . . . . . . . 3.2.1 Tivoli NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Tivoli Mid-Level Manager (MLM). . . . . . . . . . . . . . . . . 3.2.3 IBM SecureWay Firewall . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Other tools used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Phase 1: Network management 101 . . . . . . . . . . . . . . . . . . 3.3.1 General topology for Phase 1 . . . . . . . . . . . . . . . . . . . 3.3.2 Building network components for Phase 1 . . . . . . . . . 3.3.3 Conclusion for Phase 1. . . . . . . . . . . . . . . . . . . . . . . . 3.4 Phase 2: Network management across a single firewall . . . 3.4.1 General network topology for Phase 2 . . . . . . . . . . . . 3.4.2 Polling using SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Troubleshooting techniques . . . . . . . . . . . . . . . . . . . . 3.4.4 NAT and firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Conclusion for Phase 2. . . . . . . . . . . . . . . . . . . . . . . . 3.5 Phase 3: Distributed network management across firewalls 3.5.1 General network topology for Phase 3 . . . . . . . . . . . . 3.5.2 Introducing NetView Mid-Level Manager. . . . . . . . . . . 3.5.3 Installing Mid-Level Manager . . . . . . . . . . . . . . . . . . . 3.5.4 Configuring NetView . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Testing communications between NetView and MLM . 3.5.6 Analysis of results . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.7 MLM remote installation . . . . . . . . . . . . . . . . . . . . . . . 3.5.8 Conclusion to Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . 3.5.9 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 . 41 . 41 . 42 . 43 . 44 . 44 . 45 . 46 . 46 . 47 . 53 . 53 . 53 . 70 . 71 . 77 . 78 . 80 . 80 . 81 . 81 . 83 . 86 . 89 . 91 . 97 . 97
Chapter 4. Management in distributed environments . . . . . . . . . . . . 101 4.1 Test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.2 Distributed management with MLMs . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.3 Distributed management using NetView in unsecure networks . . . . . 106 4.3.1 NetView in service provider TMR . . . . . . . . . . . . . . . . . . . . . . . 107 4.3.2 NetView in its own TMR regions . . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.3 NetView installation recommendation . . . . . . . . . . . . . . . . . . . . 116 4.4 TDS cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.4.1 Sample firewall configuration rule - Oracle database connection118 4.5 TEC connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 4.5.1 Forwarding events to TEC with NetView nvserverd daemon . . . 125
iv
4.5.2 Forwarding events to TEC with SNMP trap forwarding function 132 4.5.3 Forwarding events to TEC with tecad_nv6k application . . . . . . 139 4.6 Remote access to network management system . . . . . . . . . . . . . . . 141 4.6.1 Remote access with the Java Web client . . . . . . . . . . . . . . . . . 142 4.6.2 Secure Shell (SSH) access to network management system . . 146 Chapter 5. Network management through the VPN . . . . . . . . . . . . . . 163 5.1 VPN overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 5.2 VPN solutions in the market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.2.1 IPSec-based solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.2.2 Layer 2 based VPN solutions (data link layer). . . . . . . . . . . . . . 167 5.3 VPN and network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 5.3.1 SNMP and VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 5.4 Implementing VPN using IBM SecureWay FW for Windows NT V4.1 171 5.4.1 Static tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.4.2 Dynamic tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 5.5 Client to site VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 5.5.1 Implementing a client - site VPN using the Check Point VPN-1. 179 5.6 VPN client/server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.6.1 Windows 2000 VPN configuration. . . . . . . . . . . . . . . . . . . . . . . 210 5.6.2 AIX VPN connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 5.6.3 Firewall configuration rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Chapter 6. Network management in the DMZ . . . 6.1 The eBusiness architecture . . . . . . . . . . . . . . . 6.1.1 The corporate network . . . . . . . . . . . . . . . 6.1.2 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 The Internet . . . . . . . . . . . . . . . . . . . . . . . 6.2 eBusiness network management architecture. . 6.2.1 Discovery and configuration polling . . . . . 6.2.2 Internet connectivity . . . . . . . . . . . . . . . . . 6.2.3 Forwarding traps . . . . . . . . . . . . . . . . . . . 6.2.4 Tivoli Decision Support . . . . . . . . . . . . . . . 6.3 Consolidating enterprise network management 6.3.1 Alternative solutions . . . . . . . . . . . . . . . . . 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 . 261 . 261 . 262 . 264 . 264 . 266 . 268 . 278 . 286 . 288 . 292 . 296
Part 3. Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 Appendix A. IBM SecureWay Firewall installation . . . . . . . . . . . . . . . . 301 A.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 A.2 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Appendix B. Check Point 2000 enterprise suite with Firewall-1 4.1 . . 311 B.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 B.2 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Appendix C. Installing Check Point SecuRemote VPN client . . . . . . . 329 C.1 Prerequisites for SecuRemote client . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 C.2 Locating and installing the SecuRemote client . . . . . . . . . . . . . . . . . . . . 329 Appendix D. Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 D.1 IBM SecureWay Log Reporter. . . . . . . . . . . . . . . . . . . . . . . . . . . 335 D.2 Trap forwarding script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Appendix E. Installing the Ethereal Sniffer . . . . . . . . . . . . . . . . . . . . . . 341 E.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 E.2 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 E.2.1 Installing WinCap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 E.2.2 Installing Ethereal software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Appendix F. Using the additional material . . . . . . . . . F.1 Locating the additional material on the Internet . . . . . F.2 Using the Web material. . . . . . . . . . . . . . . . . . . . . . . . F.2.1 How to use the Web material . . . . . . . . . . . . . . . ....... ....... ....... ....... ...... ...... ...... ...... . . . . 347 347 347 347
Appendix G. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Appendix H. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 H.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 H.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 H.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 H.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
vi
Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. Theoretical firewall environment8 Screening router9 Dual-homed gateways10 VPN case study13 Network management concept20 Network management with Tivoli NetView24 Distributed network management with NetView26 Remote access to network management system30 Tivoli system management structure31 NetView in connection with TEC and TDS33 Phase One topology for Scenario One47 IP routing on Windows NT 4.048 NetView IP map topology49 NetView for Windows NT IP map topology51 Phase 2 network topology for Scenario 153 SWF configuration client57 Network objects58 Creating network objects59 Network object group60 Creating a rule61 SNMP response rule63 Creating a service64 Service composition65 Adding a connection67 Connection details68 Connection control69 Netmon seed file editor71 Log facilities72 Adding log facilities72 Sniffer host placement76 Start packet capture76 Live capture and results77 CNAT and NAT78 Network topology and communications for Phase 380 NetView SNMP configuration for MLM85 NetView with APM installed86 MLM alias table87 MLM interface status table88 Packet capture for MLM traps to NetView89 TCP conversation from MLM to NetView90
vii
41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83.
MLM remote installation from the Tivoli Desktop. . . . . . . . . . . . . . . . . . . 92 MLM installation output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 MLM remote installation analysis - Part One. . . . . . . . . . . . . . . . . . . . . . 93 Remote MLM installation analysis - Part Two . . . . . . . . . . . . . . . . . . . . . 94 MLM remote installation communication summary . . . . . . . . . . . . . . . . . 96 Network management in SP networks . . . . . . . . . . . . . . . . . . . . . . . . . 101 Test environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Distributed management with MLMs . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 NetView in SP subnetworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Distributed management with NetView in one TMR . . . . . . . . . . . . . . . 108 Installation managed node from TMR server . . . . . . . . . . . . . . . . . . . . 110 Installation NetView from TMR server . . . . . . . . . . . . . . . . . . . . . . . . . . 113 NetView in unsecure networks with separate TMR . . . . . . . . . . . . . . . . 115 NetView database integration in TDS analysis . . . . . . . . . . . . . . . . . . . 117 NetView database connection through firewall . . . . . . . . . . . . . . . . . . . 119 Oracle database connection rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Forward events with nvserverd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Event forwarding administration from NetView to TEC . . . . . . . . . . . . . 126 TEC server configuration in NetView for UNIX . . . . . . . . . . . . . . . . . . . 127 Communications between NetView and TEC . . . . . . . . . . . . . . . . . . . . 128 Dynamic rule configuration for RPC communication . . . . . . . . . . . . . . . 130 Sending events from NetView to a restricted TEC port . . . . . . . . . . . . . 132 Forward all events to TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Configuration of trap forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 NetView trapd configuration dialog box . . . . . . . . . . . . . . . . . . . . . . . . . 135 Forward specific events to TEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Definition of specific events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Forward only rule passed events to TEC . . . . . . . . . . . . . . . . . . . . . . . 138 Communication NetView NT and TEC Server on NT . . . . . . . . . . . . . . 141 Remote access to network management servers . . . . . . . . . . . . . . . . . 142 Communication between Java Web client and NetView server . . . . . . 144 Telnet connection with subsequent export of X11 GUI . . . . . . . . . . . . . 147 X11 Forwarding through encrypted tunnel . . . . . . . . . . . . . . . . . . . . . . 148 SSH test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 SSH authentication setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 SSH port forwarding setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 SSH session startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Running SSH session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 VPN main menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Tunnel definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Exporting the tunnel definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Importing a tunnel definition at the partner firewall . . . . . . . . . . . . . . . . 176 View of the imported tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
viii
84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126.
Activating the tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Client to site VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Check Point FireWall-1/VPN-1 login panel . . . . . . . . . . . . . . . . . . . . . . 180 Create new network object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Defining network object of type network . . . . . . . . . . . . . . . . . . . . . . . . 181 Workstation properties of the network object . . . . . . . . . . . . . . . . . . . . 182 Defining network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Authentication option for the workstation . . . . . . . . . . . . . . . . . . . . . . . 183 VPN parameters definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 FWZ encryption properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Encapsulate the traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 User creation menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 User creation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 User authentication definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 User encryption properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 FWZ properties configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Creating the VPN rule (left half of the panel). . . . . . . . . . . . . . . . . . . . . 190 Creating the VPN rule (right half of the panel). . . . . . . . . . . . . . . . . . . . 190 Policy install. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Policy installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Accepting unauthorized FWZ traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Policy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Create a site on the SecuRemote client . . . . . . . . . . . . . . . . . . . . . . . . 195 SecuRemote client authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Tracer Route example of encryption and encapsulation . . . . . . . . . . . . 197 Telnet to a secure host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Telnet to secure host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 VPN traffic - sniffer output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Java Web client (normal communication, non-VPN) . . . . . . . . . . . . . . . 200 NetView Java Web client authentication . . . . . . . . . . . . . . . . . . . . . . . . 201 Java Web client map options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Sniffer output of the Java Web client after VPN implementation. . . . . . 202 SecuRemote client behind a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Rule definition to allow ipip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Rule definition to allow port 259 on the firewall . . . . . . . . . . . . . . . . . . . 205 Defining the service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 SecuRemote Connection 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 SecuRemote Connection 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Regenerate the rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 VPN client/server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Creating a new security policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Security Policy creation wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Define the security policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
ix
127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169.
Request for secure communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Policy Wizard - Edit panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Policy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Tunnel end point definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Policy network type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Policy authentication methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 IP filter list addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 IP filter addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Filter wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 IP traffic source definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Traffic destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 IP protocol type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 IP filter wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Complete filter rule creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 IP filter list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Filter action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Filter action wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Filter action name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Filter action general options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Communication with non-IPSec computers. . . . . . . . . . . . . . . . . . . . . . 224 IP traffic security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Filter action wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Filter action selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Security rule wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 IP security rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Assign the rule to the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Filter properties of the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Sniffer output of the ping packet from the client to the server . . . . . . . . 230 VPN configuration panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 IP security start options dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Internet key management application . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Key management tunnel properties panel. . . . . . . . . . . . . . . . . . . . . . . 234 Key management policy panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Key policy property panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Key management proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Key management proposals properties. . . . . . . . . . . . . . . . . . . . . . . . . 238 Transform properties panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Key management proposals properties after transform definition . . . . . 240 Key management policy panel after proposal definition . . . . . . . . . . . . 241 Key management policy panel after policy definition. . . . . . . . . . . . . . . 242 Key management authentication method . . . . . . . . . . . . . . . . . . . . . . . 243 Internet Key Management Application after key tunnel definition . . . . . 243 Data management tunnel dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212.
Data management tunnel endpoint definition . . . . . . . . . . . . . . . . . . . . 245 Data management policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Data management policy property panel. . . . . . . . . . . . . . . . . . . . . . . . 247 Data management proposals panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Data management proposal definition. . . . . . . . . . . . . . . . . . . . . . . . . . 249 Transforms properties definition dialog . . . . . . . . . . . . . . . . . . . . . . . . . 250 Data management proposal panel after proposal definition . . . . . . . . . 251 Data management proposals panel after new proposal definition. . . . . 252 Data management policies after new policy definition. . . . . . . . . . . . . . 253 Data management options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Internet Key Management Application after key tunnel definition . . . . . 254 Define the rule for IKE communication . . . . . . . . . . . . . . . . . . . . . . . . . 256 Define the rule for ESP communication. . . . . . . . . . . . . . . . . . . . . . . . . 257 Define the service for VPN rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Define the connection for the VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 The Prime Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 The Primary Network Management model (PNM). . . . . . . . . . . . . . . . . 265 DMZ discovery and configuration polling. . . . . . . . . . . . . . . . . . . . . . . . 266 NetView IP Internet submap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Object creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Internet Access object group properties . . . . . . . . . . . . . . . . . . . . . . . . 270 Internet Access group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Internet map after loadhosts command executed . . . . . . . . . . . . . . . . . 273 Relocating Internet networks to the Internet Access submap . . . . . . . . 274 Changing symbol properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Internet management submap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Internet Access disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Sample Internet connectivity events . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Trap settings for NetView NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Internet Access management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Performance management of exterior router without SNMP access. . . 283 Performance management of exterior router with SNMP access . . . . . 285 Sample router MIB-II report showing serial interface throughput . . . . . 286 Tivoli Decision Support for the enterprise . . . . . . . . . . . . . . . . . . . . . . . 287 VPN for secure communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Sending DMZ events directly to TEC . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Alternative Solution 2 - DMZ MLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Using MLM under NetView to filter traps . . . . . . . . . . . . . . . . . . . . . . . . 296 Enable IP forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Installing IBM Intermediate Support Driver . . . . . . . . . . . . . . . . . . . . . . 302 Insert disk for Support Driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Select IBM Intermediate Support Driver . . . . . . . . . . . . . . . . . . . . . . . . 303 IBM Intermediate Support Driver installed. . . . . . . . . . . . . . . . . . . . . . . 304
xi
213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255.
SecureWay Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Select components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 License agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Installation options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Confirm settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Setup in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Hardening the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Installation summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Check Point 2000 welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Check Point 2000 license agreement . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Check Point 2000 product menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Server/Gateway components selection . . . . . . . . . . . . . . . . . . . . . . . . . 314 Setup type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Gateway/Server module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Backward compatibility screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Destination location for firewall modules . . . . . . . . . . . . . . . . . . . . . . . . 317 Destination location for management client. . . . . . . . . . . . . . . . . . . . . . 317 Management client dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Destination location for reporting server . . . . . . . . . . . . . . . . . . . . . . . . 319 Reporting server modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Reporting server mail settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Web server settings of reporting server. . . . . . . . . . . . . . . . . . . . . . . . . 321 Destination location for reporting client . . . . . . . . . . . . . . . . . . . . . . . . . 321 Reporting client modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Firewall license installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Administrators dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Firewall IP-Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Configuration of GUI clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 IP Forwarding dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Key Hit session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Setup complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 SecuRemote Installation Welcome panel . . . . . . . . . . . . . . . . . . . . . . . 330 SecuRemote license agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Existing version dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 SecuRemote installation directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 SecuRemote Desktop Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 SecuRemote Network Bindings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 SecuRemote setup complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Control Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Local Area Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Local Area Connection properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Installing Network Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Select Network Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
xii
256. Select Driver for WinCap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 257. WinCap driver installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
xiii
xiv
Tables
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Comparing various gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SNMP protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 NetView status polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 MLM communication in distributed management . . . . . . . . . . . . . . . . . . . 27 FW1 Firewall configuration for Phase Two . . . . . . . . . . . . . . . . . . . . . . . . 55 Service and rule Configuration for Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . 79 Connections and services for Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Service and rule configuration for MLM traps to NetView . . . . . . . . . . . . . 90 Connection for MLM traps to NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Service and rule configuration - MLM remote installation from NetView . . 95 Connection for MLM remote installation from NetView . . . . . . . . . . . . . . . 95 General communications for MLM remote installation . . . . . . . . . . . . . . . . 96 Communication rules for distributed management with MLMs . . . . . . . . 105 Firewall rule for installation of management node . . . . . . . . . . . . . . . . . . 112 Firewall rule for NetView installation on managed node . . . . . . . . . . . . . 113 Firewall rule for NetView connection to database server. . . . . . . . . . . . . 118 Oracle databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Firewall rule for NetView connection to Oracle database . . . . . . . . . . . . 120 Firewall rule for RPC communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Firewall rule with restricted TEC reception port . . . . . . . . . . . . . . . . . . . 132 Firewall rule for NetView connection to Oracle database . . . . . . . . . . . . 135 Firewall rule for NetView NT communication with TEC NT . . . . . . . . . . . 141 Communication rules for Web client to NetView server . . . . . . . . . . . . . . 146 Communication rule for SSH connections . . . . . . . . . . . . . . . . . . . . . . . . 150 Firewall rule for SSH test lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Firewall rule for VPN client/server connection . . . . . . . . . . . . . . . . . . . . . 260
xv
xvi
Preface
With the complexity of our distributed computer networks today, the discipline of Network Management requires more knowledge than ever before. Long gone are the days when knowing whether your computer network was available was simply a matter of pinging a system to check for connectivity. With the added challenge of implementing security architectures in today s networks, the growing concern in the market place is how we manage our networks without compromising on security. As our economy is quickly evolving into businesses that depend on others, the concepts of eBusiness, outsourcing and Internet Service Provider architectures are becoming commonplace. This redbook will help you understand the network security paradigm and its implications for network management using the Tivoli platform. It will explore the most popular architectures that exist in secure networks today and explain some fundamental concepts that are essential for any IT management specialist. We will also discuss distributed network management and the issues that you need to understand in light of network security. The book will teach you, step-by-step, how to analyze your network environment and acquire the knowledge you need to implement an effective and secure network management solution. Various architecture solutions will be provided to illustrate practical methods of managing your network. These architectures will range from the simple to the more complex distributed nature. These solutions can be used as building blocks to manage your network in the real world. A separate section will discuss network management architectures relating to service providers. Addressing the needs for end-to-end enterprise and network management using the Tivoli platform in such environments, we will examine the protocol requirements for Tivolis NetView, Tivoli Enterprise Console (TEC), Framework (TMR), and Tivoli Decision Support (TDS) software. In an effort to address the security requirements for today s networks, we will also describe how to use different VPN tunneling techniques to enhance the security of network management communications. This will be especially useful for implementing solutions that allow remote network managers to securely manage their network from practically any location. We will describe the implementation of a VPN tunnel from Check Point FireWall-1 to the Check
xvii
Point s VPN-1 SecuRemote/SecureClient and to tunnel this established VPN through IBM SecureWay Firewall product. Finally, we will examine various solutions to manage DMZ and eBusiness environments. This section will also discuss and compare different high level architectures and methods to most effectively manage your DMZ and eBusiness environment using the Tivoli platform, as well as highlight some of the security concerns that influence how we design a solution. This information will be useful for network architects and managers that need to understand key network management and security concerns pertaining to such environments. This redbook will be useful for network and IT architects, support staff and network managers who require a much more in-depth understanding of the how to architect, design, and implement network management solutions in secure networked environments. A working knowledge of the Tivoli NetView Platform is assumed, as well as a general understanding of Tivoli Enterprise Console, Tivoli Decision Support, firewalls, and TCP/IP networking.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center. Stephen Hochstetler is a Project Leader at the International Technical Support Organization, Austin Center. He applies his 17 years of experience as an IT Tivoli Specialist to his work at the ITSO, where he writes extensively on all areas of Systems Management. Before joining the ITSO, Stephen worked in the Tivoli Services organization of Tivoli as a Network Management Specialist. For the last four years, he has concentrated on architectural work and the design of network management solutions for large customer environments and service providers. Harry Tanner is a Network Management Specialist in the Network Services arm of IBM Global Services Australia in Sydney. He has five years of experience in systems and network management. Prior to assuming his duties in IBM, he spent six months as a HP Openview consultant for various major corporations. He holds a degree in Computer Engineering, is a qualified MCSE, and is a certified Tivoli NetView and HP Openview consultant. His areas of expertise include network management systems, integration, and the design and development of network and systems
xviii
management tools. He has also been leading the development of network management systems for IBMs Shared Network Infrastructure (SNI) in Australia for the past year. Ramachandra Kulkarni is a security consultant with iflex solutions ltd - India. iflex is part of the Citigroup worldwide and caters to banking and financial domains of the industry. He has a total of eight years of experience in network design, administration, and network security consulting, as well as training on network security products. He has worked with IBM Global Services, as well as with IBM India, as a consultant and trainer prior to joining iflex. He currently consults on security implementations for various major clients of iflex worldwide. He also conducts information system audits for various corporate clients. He is certified by Microsoft and Novell, and is a certified solution expert on the Tivoli SecureWay firewall. Sebastian Mika is an advisory IT-Specialist of IBM Global Services Germany in Berlin. He has a total of five years of experience in software development, systems, and network management. He holds a degree in telecommunications and business and is a qualified MCSE. He is involved in major consulting and implementation projects for systems and network management in the banking, finance, and service provider sectors. His areas of expertise include software development, UNIX, Tivoli systems, and network management platforms, as well as other multi-vendor management software, such as HP Openview. Thanks to the following people for their invaluable contributions to this project: International Technical Support Organization, Austin Center Caroline Cooper, Morten Moeller, Axel B cker, Wade Wallace Tivoli Systems, Austin Urs Schwarzenbach Tivoli Systems, Raleigh Rick Reed, James Shanks, George deSocio IBM SNI Development Team, Boulder CO Andrew J. Bernoth cbi, Reno Richard T.Nall
xix
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Please send us your comments about this or other Redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 375 to the fax number shown on the form. Use the online evaluation form found at ibm.com/redbooks Send your comments in an Internet note to redbook@us.ibm.com
xx
Part 1. Concepts
Chapter 1. Introduction to firewalls

What does security mean? There is always a trade-off to be made between making a computer secure and the functions it can provide. This balance is very difficult to achieve and has led to a common comment among security experts that the most secure computer is one that is completely turned off. With the advent of networking technologies and the Internet, the problem of security has been compounded, because the communication channel on which the network depends is itself prone to attacks. An attack can be defined as a process in which computing resources are rendered inaccessible by authorized /unauthorized people. Attacks can be of two types 1. Passive attacks: Tapping or tracing the communication. These are the most difficult attacks to predict. Theoretically, any and every communication can be tapped by an intruder who could then take advantage of the communication to gain access to other resources in an organization. 2. Active attacks: This is a direct taking-over the functionality of the computer and using the information stored in these resources to render the network of computer unusable. It does not matter if an attack is done for fun or for profit; it is always your invaluable data which will be at stake.
1.1 TCP/IP preview

Although it is assumed that the user who is reading this redbook has fair knowledge of TCP/IP, the following section gives a brief overview of the ports and other related subjects used in this redbook. As you will later appreciate during the configuration of the firewall, an in-depth knowledge of ports and general security principles will be very beneficial. Each process that wants to communicate with another process identifies itself to the TCP/IP protocol suite by one or more ports. A port is a 16-bit number used by the host-to-host protocol to identify to which higher-level protocol or application program (process) it must deliver incoming messages. We refer to ports as belonging to one of two major groups: well-known and high ports.
1.1.1 Well-known ports

Well-known ports belong to standard services, for example, Telnet uses port 23 and Tivolis oserv uses port 94. Well-known port numbers range from 1 to 1023 (prior to 1992, the range between 256 and 1023 was used for UNIX-specific servers). On UNIX, the ports up to 1023 are privileged in the sense that the daemons using them are generally run as root. This does not apply to Windows NT. Well-known ports are typically odd numbers, because early systems using the port concept required an odd/even pair of ports for duplex operations. Most servers require only a single port. There are exceptions such as the FTP server, which uses two (20 and 21). Originally documented in RFCs, the well-known ports are now managed and assigned by the Internet Assigned Numbers Authority (IANA). The reason for having well-known ports is to allow clients to be able to find servers without the need for implementation-specific configuration information. On most systems, these ports can only be controlled by system processes or by programs executed by privileged users. The well-known port number list is available at:
http://www.iana.org/assignments/port-numbers
1.1.2 High ports

High ports are those above 1023. Given that a port is a 16-bit number, the range of high ports is from 1024 to 65535. Note that organizations can request IANA to track ports - either well-known or in the range of 1024 to 49151. These tracked ports are known as Registered ports. However, as any application can make use of ports in the 1024 to 49151 range, there is no guarantee that a port named in this range will be used by the registered service. The range of ports between 49151 and 65535 are usually referred to as dynamic or private. High ports are not controlled by IANA beyond the registration of ports already described. On most systems, any high port can be used by ordinary user-developed programs. Confusion due to two different applications trying to use the same port numbers on one host is avoided by writing those applications to request an available port from the host TCP/IP implementation. Because this port number is dynamically assigned, it may differ from one invocation of an application to the next.
1.2 The concept of the firewall

Every time an organization wants its internal computer network to be connected to the Internet, it faces a challenge in terms of how to keep the internal network safe from the outside intruders while allowing employees access to the external world in order to meet various business requirements. Hackers (a term used to describe users on the Internet who indulge in
unauthorized attempts to get into the company network) can theoretically break into the company network and steal or damage the important data, damage important computer systems or the entire network. To overcome this challenge and allow themselves to be protected against hackers, companies build firewalls to give their employees legitimate access to the resources outside the company network and prevent an unauthorized external entry into their network. A firewall is a combination of hardware and software that will sit in the entry point to the company network (or the point where company network is connected to the Internet) and will monitor the type of traffic coming into the company network and make decisions if the packet is going to be let in or not. To understand how a firewall works, consider this example. Imagine a building where you want to restrict access and to control people who enter in. You define, in the architecture of the building, a single lobby as the only entrance point. In this lobby, you have some receptionists that welcome, some security guards that watch, some video cameras that record, and some badge readers to authenticate people who enter the building. This works very well to control a private building. But imagine that a non-authorized person succeeds in entering. To protect the building against any actions from this person is more difficult. However, if you supervise his or her movements, you at least have a chance to detect any suspicious behavior and repair any damage. When you are defining your firewall strategy, you may think it is sufficient to prohibit everything that presents a risk for the organization and allow the rest. However, because of new attack methods, you may not be able to prevent every attack and, as in the case of the building, you need to monitor for signs that somehow your defenses have been breached. Generally, it is much more damaging and costly to recover from a break-in than to prevent it in the first place. Now, coming to what a firewall is, in the above example, it is the TCP/IP equivalent of a security gate at the entrance to your company. All traffic (data packets) must be screened by it and the security guard (firewall) there allows only authorized people (packets) to gain entry into the company building (network).
1.3 The components of a firewall

The components of a firewall include: 1. Packet filtering (also called a screening router) 2. Application Proxies
3. Circuit level gateways 4. Virtual Private Networking Screening Routers can look at the packet IP address (Network layer), and even the types of connections (Transport layer) and then provide filtering based on that information. A screening router may be a stand-alone routing device or a computer that contains two network interface cards (dual-homed system). The router connects two networks and performs packet filtering to control traffic between the networks. Administrators program the device with a set of rules that define how packet filtering is done. Ports can also be blocked; for example, if your company security policy is that only Web browsing (HTTP) is allowed and the rather dangerous FTP not to be allowed, packet filtering by the screening routers can achieve this by implementing appropriate rules. An application-level proxy server provides all the basic proxy features and also provides extensive packet analysis. When packets from the outside arrive at the gateway, they are examined and evaluated to determine if the security policy allows the packet to enter into the internal network. Not only does the server evaluate IP addresses, it also looks at the data in the packets to stop hackers from hiding information in the packets In case any employee of the company wants to access a server on the Internet: 1. A request from the computer is sent to the proxy server. 2. The proxy server contacts the server on the Internet with its address as the source address (not the actual computer which requested it). 3. The proxy server then sends the information back from the Internet server to the actual computer which requested the data. By doing this, the IP address of the internal (company) computer is never known outside of its own network. Proxy servers also log the information on who has requested and what are the transfer details to make an analysis of the Internet access. The IBM SecureWay Firewall provides application level proxies (FTP, Telnet, and HTTP). Circuit level gateways - This type of proxy server provides a controlled network connection between internal and external systems. A virtual "circuit" exists between the internal client and the proxy server. Internet requests go through this circuit to the proxy server, and the proxy server delivers those
requests to the Internet after changing the IP address. External users only see the IP address of the proxy server. Responses are then received by the proxy server and sent back through the circuit to the client. While traffic is allowed through, external systems never see the internal systems . The IBM SecureWay Firewall provides a circuit level gateway that is called as the socks server. Table 1 shows the differences between the application level gateway and the circuit level gateway
Table 1. Comparing various gateways
Particulars Operates in OSI Layer Require proxies for each service (for example, HTTP, FTP, and so on) TCP/IP Translation Logging Modified Client Required URL filtering capability
Application level Gateway Application Yes
Circuit level Gateway Transport through session No
Done at the Proxy Provided No Yes
Done at the client Usually no logging Yes No
Virtual Private Network - Section 1.7, Virtual Private Networks on page 11 gives an introduction on VPN and also gives a case study of VPN.
1.4 Terminologies associated with the firewall

Secure Network (SN) Typically, this is the organization network where all the safe data resides. This is the area where all the applications that are required for the day to day business of the company are run. Examples of these could be the company accounting function as well as the company payroll function. See Figure 1 on page 8. A combination of hardware and software, with the help of expertly built
Firewall (FW)
access rules, that ensure the perimeter security of the organization. Demilitarized Zone (DMZ) A network added between the company network and the external network to facilitate layered security. Typical elements that we will find in DMZ would be the Web servers and mail servers. A general purpose computer which has at least two network interfaces.
Dual homed host
Network Address Translation (NAT) The procedure by which a router/firewall modifies the source IP address. This is done for security reason as this process will enable to hide the actual internal address. Virtual Private Network (VPN) A connection which normally spans geographic location and uses the Internet as the connecting medium. It also uses tunneling and encryption techniques to ensure the security of the data.
Firewall DMZ Router

Internet
10.69.14.X
Secure Network
Figure 1. Theoretical firewall environment
1.5 Firewall architectures

The following section will describe the various firewall architectures.
1.5.1 Screening router

The first and most commonly used strategy is to separate the private IP network from the Internet by inserting a router between them. This router
filters all IP packets passing through and is called a screening filter. This way, you can prevent access to machines or to ports in the private network and also do the reverse: prevent an inside machine from accessing the Internet. The connections are made as shown in Figure 2. But if you do this, there is no way to control what happens at the application layer. That is, you may want to allow one type of traffic across the gateway but not another. You could manage this at the application host itself, but the more machines on which you have to impose controls, the less control you have. Nonetheless, a screening filter is a very useful tool to use in conjunction with other tools as a security building block.
Secure Network Internet Screening Router
10.69.14.X
Figure 2. Screening router
1.5.2 Bastion
A bastion is a machine placed between the secure and non-secure network where the IP forwarding is broken, which means no IP packet can go through this machine. As the routing is broken, the only place from which you can access both networks is the bastion itself. Therefore, only users who have an account on the bastion, with a double identification (one for the bastion and one for the remote host), can use services on both the networks. This has some disadvantages, because the bastion may have to support many users. It is important to enforce good password control here, because if a hacker manages to break into a user ID, he or she can then impersonate the user and get into the private network. Besides this security point, supporting a great number of users will require a big machine. To avoid having users logged in to this machine and to reduce load on the machine, application proxies and SOCKS are now being used.
1.5.3 Dual-homed gateway

In this case, you can protect the dual-homed gateway from external attacks with filtering. For example, if you forbid external access to the telnet daemon,
you reduce the threat of an external attack. If you have some nomadic machines that are hosted outside but need to connect to hosts inside the private network, you can limit the exposure by using a proxy server and perhaps using smart card authentication techniques. The pictorial representation of the dual-homed gateway is shown in Figure 3. The IBM SecureWay Firewall for Windows NT comes with a configuration similar to a dual-homed gateway.
Secure Network Dual homed Firewall

Internet 10.69.14.X
Figure 3. Dual-homed gateways
1.5.3.1 Screened subnet A further development of this gateway is to use the subnetwork between the screening router and the bastion as a site for application services. This is increasingly common, as organizations want to provide machines that are widely available (such as Web servers) but still have strong protection for their private network. The screening router provides some protection for the service machines without unduly limiting access. This network is composed of two screening routers and one or several bastions. When you start considering this sort of solution, the cost becomes a major factor because, for reasons of integrity, each component in the design should ideally be a dedicated machine.
1.6 Firewall objectives and firewall rules

We have seen that there are a number of ways to configure a firewall, depending on the size of your organization and what you are trying to achieve. Before we look in detail at how to use the IBM SecureWay Firewall for Windows NT to achieve some of these configurations, let us state some high-level objectives and rules. There are a number of objectives that are common to all firewall cases: Only allow traffic to flow that you have determined is safe and in your interest.
10
Give away a minimum of information about your private network. Be able to keep track of firewall activity and be notified of suspicious behavior. These common objectives translate into a number of rules that you should always keep in mind: Anything that is not explicitly permitted should, by default, be denied. What this means is that when you set up your firewall you should be able to state exactly what traffic you want to pass through it. It should not be possible for any other traffic to pass. You should keep outside users out of your internal network wherever possible. Even if you are providing a legitimate service for outsiders to use, you should not trust them. If possible such services should be placed outside the firewall (possibly within a DMZ), isolated from your internal systems. You should do thorough auditing and logging. You should assume the worst, that at some time your systems will be compromised by a hacker. At this point, you need good logging functions to allow you to detect the hacker, retrace his or her movements, and prevent further damage.
1.6.1 Beyond the firewall: filtering content

Firewall technology must wage a continuous battle against the ingenuity of the hacker. This means continuing to be vigilant in preventing misuse of legitimate IP network services and new security holes. One area that has become part of this battlefield in recent times is the potential for exploitation of smart client function. As the Web browser becomes the complete do-everything client, Web-based applications start to rely on client side execution of programs, using techniques such as Java, ActiveX controls, and other plug-in functions.
1.7 Virtual Private Networks

Virtual Private Networking is a process by which organizations take advantage of the public network (Internet) to achieve connectivity for their branches as well as their remote users. The security of this connection is achieved by authentication and encryption. The following section looks at the various options to build a VPN. VPN s are deployed at two layers: 1. Data Link layer VPN (Layer 2)
11
2. Network Layer VPN(Layer 3 / IPSec) The protocols used for establishing VPN layers are: 1. PPTP (Point to Point Tunneling Protocol) 2. L2TP(Layer 2 Tunneling Protocol) 3. L2F(Layer 2 Forwarding) The protocol which is used to establish the network layer VPN is IPSec. IPSec in turn has three component protocols: 1. Authentication Header (AH) 2. Encapsulated security payload(ESP) 3. Internet key exchange (IKE) In this redbook, we will be concentrating only on the IPSec based VPN. There are two modes of IPSec operation: Tunnel Mode This type of operation is deployed between two gateways or a server to a gateway scenario. In this method, the traffic is tunneled between the client and the gateway of the destination network, not the exact host in the network. Technically speaking, the IP header will be modified and a new header will be added before the original IP header to reflect the gateway address, not the host address This type of operation is deployed where there is a requirement of end to end encryption. The resource demands on the communicating partners in this type of operation is huge. Technically, in this mode a new IP header will be inserted after the original IP header and this facilitates end to end transport mode.
Transport Mode
1.7.1 Case study of VPN

The following case gives an idea for deploying VPN, as shown in Figure 4 on page 13, and the benefits to the customer for using this technology.
12
VPN Gateway
Internet
Remote employee with IpSec client
Encrypted Traffic
Mail Server
Intranet Server
Figure 4. VPN case study
1.7.1.1 Case Overview iflex solutions is a software solutions and consulting company that is based in India. The company develops software at its facilities for their worldwide clients. As a part of their consulting and implementation process, many of their software engineers carry out some part of their work on-site at the clients place. Many employees are based at client locations all over the world. As part of an internal survey done by the company, iflex realized that the on-site engineers were not able to access their mail servers, the intranet servers where all their leave records and other administrative process were available, and the product support servers, which were located in their facility. Most of the engineers also felt that this is a requirement and not a luxury. The company IT team sat down with the report and discussed the survey results and came up with an decision to give access to the remote employees. 1.7.1.2 Action plan The IT team soon realized that giving access to the company mail server and the intranet servers without looking at all the potential security hazards would place the company information at a very high risk. Because the employees to whom the access was to be provided were all over the world, they could not use a dedicated line solution. IT then evaluated using SSL technology to access the mail server securely. It was a workable solution, but because of the resource demands of SSL technology, they found that the solution was a very slow and the remote employees were still not happy with this service.
13
Then IT team again started looking at alternate solutions that could fit the bill and decided that the deployment of a VPN solution would be the best solution in their case because: 1. Employees, wherever they were located, could access the company resources, which are authorized by communicating through a combination of a secure client software installation and the VPN gateway (which was the corporate gateway). 2. This would be possible as long as the remote employee has Internet access and the client software IPSec client installed in their laptop. As they went through various scenarios where the employees would be accessing the company network, they decided that they need to address a couple of points: 1. Identification How can we be sure that the origin of the data is from the company resource, that is, what happens if some other person has the access to the client software and then he/she tries to access the company network? 2. Authentication What will happen if the employee laptop is stolen? Will it be a problem because the client software is already installed in the laptop? Just because the person who has stolen the laptop has it should not allow him access; he must be subjected to some authentication that was done as the packet reached the corporate gateway. The final solution is outlined as follows: A certificate server will be installed in the corporate network and as soon as a remote employee tries to connect to the network, he will be verified for the appropriate keys to be exchanged between the corporate gateway and the remote user. Once the origin identification is successful, he will be forwarded to a RADIUS server for authentication. The RADIUS server in turn has all the remote users and the resources they can access. They had to procure: 1. VPN Gateway 2. RADIUS Server 3. Certificate Server 4. IPSec clients
14
This in turn ensured they could leverage the Internet as a backbone and then encrypt their data, so that even though their data is travelling on the public backbone (Internet), it is safe from somebody capturing and using it for whatever purposes. Each of their remote employees were given the client software; now the VPN has been implemented. Chapter 5, Network management through the VPN on page 163 contains a more elaborate description of the VPN s method of deployment, protocol description, and the firewall configuration needed to build a VPN. IBM SecureWay Firewall supports the VPN to be deployed by acting as a gateway.
15
16
Chapter 2. Network management

This redbook discusses network management (NM) in the context of security environments. It not only provides information for network and system administrators but also for firewall administrators, giving them a short overview of network management basics.This chapter will give an introduction to the network management challenges and business requirements of an efficient and secure network management solution. We provide an overview of the network management application NetView, which is part of the comprehensive Tivoli platform. We will also discuss how today s state of the art network management systems meet the needs of the managing and operating requirements in today s network infrastructures. This chapter also discusses firewall and other security topics, as well as network management communication protocols and Client/Server connections.The main points of discussion include: Simple Network Management Protocol (SNMP) Client/Server connections Centralized management Distributed management The following section describes how the communication between management stations and network clients are conducted. This will provide an overview of the Tivoli system management platform and associated Tivoli applications.
2.1 Introduction
Communications networks were developed in order to connect resources of an IT system structure and to enable common data communications. The growth and development of efficient computer networks fueled the growth for large scale deployment of client server systems. This led to a transition from host-based systems to peer to peer and client/server systems. One of the reasons the client server technology became popular was its ease of deployment. This led to large scale systems deployment in almost every corporation, and is the basis for critical applications deployed in enterprises today.
17
Networks have experienced constant growth. Apart from the basic needs for connectivity, today s networks cater to several additional services and functions. Enterprise critical applications demand that todays networks be efficient, high performance, economic, and highly available. Disruptions in the operation of networks can cause a deterimental impact on the business. For this reason there should be suitable procedures, processes, and tools for supporting administration and operations, as well as proactive monitoring of complex communication networks. Only then can problems and error situations be promptly detected and corrected. With comprehensive, centralized control of all network equipment and the whole network topology, operators are able to improve network reliability and reduce costs for maintenance and operation. Modern network management applications, such as NetView from the Tivoli management platform, provide the required functions and tools for the necessary network management processes. Network operation and administration can be broken down to these functions: Topology management: Visualization of the network architecture and components as well as clear representation of the network topology and its actual status. The documentation of the given infrastructures and integrated IT systems allows the system and network administrators to detect and localize problems and faults in the network. Configuration management : Offers central and uniform access to the network components. Integration of device configuration functions and tools of third party providers for efficient administration and configuration of the systems. Inventory functionality for network devices such as routers, switches, and cable modems allows quick access to hardware and software information for efficient problem resolution. The collection of inventory information is the basis for efficient rollouts and update planning. Event and fault management: The event management function permits the entry and processing of event and trap messages occurring in the network, for example, internal actions, such as passing events onto the responsible persons or administrators and the User Help Desk division, can occur. This provides the capability to discover problems before the users do. The information gathered enables the administrators to analyze the nature of problems and identify trends and potential weak spots in the technology infrastructure. The result: improved overall availability of the business systems. Performance management: Efficient performance and reporting functionality permit the development of trends as well as document the current status of the network s health. The generation of meaningful reports for the status and extent of utilization of the network resources is necessary to be proactive.
18
The NetView network management platform, which is part of the Tivolis system management platform, enables administrators to build efficient network management systems that address the needs of today s management concerns. NetView is based on the Simple Network Management Protocol (SNMP), which is the standard for the management and controlling of complex IP-networks, and its different components, such as switches, router, hubs and servers, in multi-vendor network environments. The following sections will provide a brief overview of a modern SNMP based network management system with an emphasis on firewalled network environments.
2.2 Simple Network Management Protocol (SNMP)

For the management and controlling of complex, heterogeneous IT infrastructures and networks which are a combination of multi-vendor devices, there is a need for standardized protocols and communication methods. The Simple Network Management Protocol (SNMP) became generally accepted for the management of heterogeneous IP-based network structures. The primary objectives of SNMP based network management are to reduce the complexity of the management functions and to have a standard network management protocol that will enable all the vendors to comply with. The increased popularity and implementation of IP-based communications networks contributed to the fact that the SNMP was established as defacto standard for network management solutions. SNMP is supported by all network hardware providers and proved as very effective for the management of complex networks. The Simple Network Management Protocol was developed by the International Standardization Organization (ISO) in 1988 as the universal network management solution. The SNMP standard is described in RFC 1157.
Note
You can find the RFC (Request For Comment) documents on following Web sites:
www.rfc-editor.org www.rfc.net
19
The SNMP architecture model is very easy and uses an open structure. The interfaces are open for all hardware and software providers. The concept of SNMP and its extension SNMPv2, are essentially based on a distributed model. The first component is the network management program, which is a specified SNMP manager that is implemented on a network management station (NMS). The second component is administered SNMP agents on the different network components and systems (routers, hubs, switches, server, and so on). Figure 5 shows the basic concept.
NMS Console
NSD
Server
Network Management System Agent
Switch
Agent
Router Agent
Client Agent
Figure 5. Network management concept
The SNMP network management operates according to a Client/Server principle. In this model, the SNMP-agents represent the servers, which put information about their structure and status to the management station. The NMS (the client in this model the client) polls, in regular intervals, the status, topology, and other information of the agents for the administration and monitoring of the components. The operating system of today s network components have such an agent for the SNMP network management. The agent provides the local network and system parameters as well as status information of its components in a database structure (the management information base (MIB)). The following information is an example of data available in the MIB: ARP information
20
Interface status Configuration data for hardware and software Performance data and error information Information on topology, connections, and protocols
This data available from the agent is the target for network management station requests. Through explicit requests to the network management station, the MIB fields for SNMP-agents will be selected. The station requests, in configurable intervals, the required MIB information for the managed agents and processes it for visualization. The successive query of all network components allows the network management station to build a complete topology and configuration database. On the basis of this information, the management station builds the topology view and shows the actual status of the network infrastructure. The query of performance and utilization data allows comprehensive performance analysis and reporting to be the basis for performance management. The setting of special MIB entries at the agents from the management station makes the central controlling and remote configuration of the agents possible. The SNMP protocol defines the option that agents can send traps for special status information. The agents send traps to the management station for status changing, errors, or other events. The network management station can proactively react with special actions and solve problems in the IT infrastructure. Modern network management systems, such as Tivolis NetView, provide very flexible event and error management functions for event processing and automated actions appropriate for the defined enterprise workflow.
2.2.1 IP network communication

For configuring and administering the firewalls and other security functions (such as access control lists (ACL) of network routers), it is necessary to know which IP resources will be needed for the communication between the network management station and the SNMP-agents and back. See Table 2 for details.
Table 2. SNMP protocol
Function SNMPRequest
Source NM station
Destination SNMP-Agent
Protocol UDP
SourcePort >1023
DestPort 161
21
Function SNMPReply SNMP-Trap
Source SNMPAgent SNMPAgent
Destination NM station NM station
Protocol UDP UDP
SourcePort >1023 >1023
DestPort 161 162
SNMP is an UDP based service. The SNMP agents of the network devices listen on UDP port 161. The network management station queries the required information from the UDP port 161 from a port greater than 1023. The trap sending process is also an UDP service. The agents sends its traps to the management server, which is listening for traps on port 162. NetView accepts traps sent by both UDP and TCP protocols. The SNMP authentication between server and client is based on a community string. A read community string allows the NMS to read MIB data structures from the network device. A write community string allows for the setting of MIB-data at SNMP-agent and therefore the configuration of the network device. In the today s version of SNMPv1 and SNMPv2, the communication is not encrypted, so you have to make sure that only authorized person have access to the SNMP communication. In general, you do not want someone unauthorized for the internal or external network to get SNMP information. You need to ensure that only the authorized network management servers can manage your devices. There are different ways to do this: Secure the network devices from unauthorized SNMP access by choosing different SNMP community strings than the common community strings public and write for the read and write, respectively, to the network devices. Register the authorized management servers at the SNMP management agents with the hostname and IP address. Registering these servers ensures that only the authorized stations have access to the provided management and configuration functions. Design a secure firewall architecture to prevent access to management information of network components from the outside. Modern firewall application provide effective functions against spoofing and hijacking attacks to the described client/server communication. (See Chapter 1, Introduction to firewalls on page 3 for details.) In general, do not allow everyone to SNMP query your network devices.
22
The new SNMP version, SNMPv3, which will become common in the future, extends the client/server authentication and encrypts the SNMP communication between server and clients. Chapter 3, Management across a single firewall on page 41 describes the firewall and security aspects of the SNMP communication in detail and shows different communication scenarios and their configurations.
2.3 Network management with NetView

This redbook describes the various network management scenarios on the basis of the NetView application with respect to the firewalled environment. NetView is the network management solution from the complex Tivoli enterprise management platform for network and system management tasks. It is a very powerful application which allows the effective management of complex IP-based enterprise networks. NetView supports different UNIX operating systems flavors, such as AIX and Solaris, as well as the Windows NT and Windows 2000 operating system. In this redbook, we will concentrate on AIX and discuss the differences for the Windows NT version of NetView. The network management application is based on SNMP, as described in Section 2.2, Simple Network Management Protocol (SNMP) on page 19. Figure 6 on page 24 shows NetView as the central network management station for the controlling of all network components.
2.3.1 Centralized network management

NetView collects all network topology data into its data base and represents these clearly in a hierarchical topology map. The systematic arrangement of the network objects takes place according to the given infrastructure. Additionally, SmartSets are formed by network objects, which enable a fast overview of their status. In administrable SmartSets, enterprise-critical components can be summarized clearly.
23
NetView Database
SNMP Agent
LAN/WAN
SNMP Agent SNMP Agent
SNMP Agent
SNMP Agent
Figure 6. Network management with Tivoli NetView
The network management system uses the SNMP protocol and Ciscos CDP for discovery of the network and building its powerful topology database. Besides the above described SNMP protocol, NetView also uses the ICMP (pinging) protocol for regular polling of the status and reachability of network devices and its interfaces (see Table 3). It polls in configurable intervals the status of the devices and information from routing tables, ARP tables, and other MIB field entries, which will be provided from the SNMP agent on the network components. This is an efficient process for automated detection of new network devices and changes in the network topology.
Table 3. NetView status polling
Function SNMPRequest SNMPReply
Source NetView SNMPAgent
Destination SNMPAgent NetView
Protocol UDP UDP
Source - Port >1023 161
Dest.Port 161 >1023
24
Function SNMPTrap PingRequest PingReply
Source SNMPAgent NetView Network objects
Destination NetView Network objects NetView
Protocol UDP ping/ICMP ICMP echo-reply
Source - Port >1023 0 8
Dest.Port 162 8 0
NetView provides a customizeable graphical user interface for the hierarchical visualization of the network topology. The NetView user and security management functions allow the administration of different access policies to the network management functions and different views to the network topology. Figure 6 on page 24 shows NetView working as the central event and trap receiver for all network components. The event management function allows you to define filters and rules for the processing of events, problems and fault messages. Additionally, Tivoli NetView can handle a variety of actions when responding to events and exceeded thresholds, including paging, e-mail, and programmable responses to specific failures. The open interface allows reporting to a central event management system, such as the Tivoli Enterprise Console TEC (for more information, see Section 2.4, NetView as part of a Tivoli system management platform on page 30) or forwarding filtered events to trouble ticket and help desk systems. The configurable SNMP SmartSet and reporting functions for performance and status entries of the SNMP agents allows the generation of utilization and performance graphs. NetView has the ability to produce real time statistics and graphs for the controlled network devices. The implementation of a RDBMS (Relational Database Management System), such as DB2, Oracle, or SybaseTM , provides further processing of collected performance and event data in specialized reporting and SLA (Service Level Agreement) management applications. Data analysis and generation of reports and statistics about the status and efficiency of the enterprise IT infrastructure can be produced. For example, the TDS system (Tivoli Decision Support) is such a application, which will be presented in Section 2.4, NetView as part of a Tivoli system management platform on page 30. The open interfaces and documented APIs allow the integration and implementation of multi-vendor management products and specialized add-on applications for the management of network products. CiscoWorks
25
2000 is an example for management of Cisco devices. A very good reference and introduction for extending network management systems is the redbook Tivoli NetView 6.01 and Friends, SG24-6019.
2.3.2 Distributed network management solution

The network management platform NetView offers unparalleled flexibility in a distributed environment. The NetView Mid Level Manager (MLM) function adds the capability to distribute management functions to remote locations with the help of MLM agents. It performs status polling, threshold setting, event automation, and automatic detection of new or deleted devices. Figure 7 shows the basic concept of the MLM distributed management environment.
NetView
MLMClient
MLMClient
SNMP Agent
SNMP Agent
SNMP Agent
Network A SNMP Agent SNMP Agent SNMP Agent
Network B SNMP Agent
SNMP Agent
SNMP Agent
SNMP Agent
Figure 7. Distributed network management with NetView
The distributed management solution represents a three-tier hierarchy, where the centralized network management station (NetView) realizes the central administration and monitoring of all its subordinated MLMs. Tivoli NetView Mid-Level Manager minimizes administrative overhead, and eliminates the need for dedicated management systems throughout the network. This management structure permits the distribution of status polling, status controlling, and performance data collecting activities to the MLM agents, and
26
relieves the management station for other management tasks. Figure 7 on page 26 shows such a scenario. The network management system will be configured with Mid-level Manager clients to operate in a regional management mode. The MLM manages a local region (such as a customer network) and forwards status polling, discovery, and event information to the central network management NetView server. Some of the benefits are a reduction in network traffic by distributing the status polling of network devices to locally implemented MLMs. The network management server communicates with the MLMs for status changes and other management data. The agents can filter the trap traffic and send only important traps to the NetView server. The communication between NetView and MLM agents is also based on SNMP protocol, such as the communication between MLM agents and network devices. Table 4 shows the communication details.
Table 4. MLM communication in distributed management
Function SNMP-Request SNMP-Reply SNMP-Trap
Source NetView MLM-Agent MLM-Agent
Destination MLM-Agent NetView NetView
Protocol UDP UDP UDP
SrcPort >1023 161 >1023
DestPort 161 >1023 162
The distributed management conception allows high flexibility and scalability for management of an increasing network infrastructure and solves network management performance problems. It also provides the added advantages for the network management over firewalls, because only connections (the right ports) between management server and agents have to be opened. The different communication aspects and requirements will described in detail in Section 3.5, Phase 3: Distributed network management across firewalls on page 80.
27
Note
For the design of distributed network management system with MLM, you have to focus on the following limitations: MLM can only automatically discover the local subnet where the MLM is installed. You have to install an MLM in every subnet where you want to distribute discovery function. NetView can discover remote subnets from a central location. Distributing large amounts of polling is not recommended because of the workload put on NetView s netmon (which is the polling and discovery daemon for NetView) process when it does the actual distribution. Netmons centralized polling performance has improved to a point where it is better to keep it centralized unless you have a slow or overused communication link that causes pings to fail. A further best practice of MLM is trap filtering in networks with trap traffic. A benefit is reduced network trap traffic. A second benefit is the reduction of the CPU utilization for NetView, which is normally needed for trap filtering and processing rules. Distributed MLMs that are not polling or doing discovery can still return value by filtering traps. Distributing large amounts of polling could be handled by distributed network management servers, as shown in Section 4.3, Distributed management using NetView in unsecure networks on page 106. See the following Redbooks for further conceptional discussion of MLM implementation: Examples of Using TME 10 NetView for AIX V5 and TME 10 Netview for Windows NT, SG24-4898 Integrated Management Solutions Using NetView Version 5.1, SG24-5285 Tivoli NetView 6.01 and Friends, SG24-6019
2.3.3 Remote network management access

NetView provides different ways for remote access to the network management system and its management data (See Figure 8 on page 30). These are: X-Windows access: The UNIX operating system provides the remote X-Windows (X11) access to the network management server. X11 servers can start a NetView session from the NetView server by using all the provided network management functions for topology, event, performance
28
and configuration management from the remote operator place. See Section 4.6.2, Secure Shell (SSH) access to network management system on page 146 for a discussion of the X11-Client/Server connection and its security solution. NetView-Client: The NetView-Client allows a separate graphical user interface to the NetView object database. Different operator workstations, running the client, can access the central NetView object database over a client/server communication. The clients can hold their own map database for the generation of their own views to the network topology. This distributes the processing performance for map handling from the NetView server to the separate clients. This function is provided for UNIX and Windows NT based solutions. The functionality and views to the network infrastructure can be arranged appropriately according to the responsibility of the administrators and operators. .
Note
The NetView product management team announced that the native NetView client is not the preferred remote access method. Therefore in this redbook we do not discuss in detail the communication requirements and configuration of NetView-Server in connection with the native NetView-Client. Java Web client: NetView has provided a comprehensive Java based Web client (see Figure 8 on page 30) since Version 6.0. It allows easy access to the management system from every operating system. We believe that this Web client will be the main access method to the management and controlling functions in future versions of NetView. It allows for the easy administration of distributed network management user interfaces and remote mobile access to the core functions of topology, configuration, and fault management. The client allows you to observe network activity from anywhere. Using the Web client, you can view network topology, events, node status, and SmartSets, as well as perform network diagnostics ( ping, traceroute, demandpoll, non-graphical generated MIB applications, and MIB browser). Technicians working at any of the stations in the corporate network or remote site can use the Java Web client to access and manage the network. By viewing the same status and alarm information, the NOC (network operating center) operators and a field technician can speed up the problem resolution process. See Section 4.6.1, Remote access with the Java Web client on page 142 for further discussion of this topic.
29
JavaWebclient Mobile Access JavaWebclient
NetView NM-Server
XW
in d ow s
Enterprise Network Operator
Operator
Figure 8. Remote access to network management system
2.4 NetView as part of a Tivoli system management platform

The network management application NetView is integrated into the comprehensive system management enterprise platform Tivoli TME10. In regards to communication requirements in a firewalled environment, it is important to know how NetView is embedded in the Tivoli management suite. The Tivoli management framework is based on a CORBA (common object request broker architecture) model. The Tivoli management model describes a hierarchical management structure with different management levels, known as the Tivoli Management Framework.
30
Figure 9 shows a basic overview of the management structure.
TMRServer
Managed Node/ Gateway
Managed Node/ Gateway
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Endpoint
Figure 9. Tivoli system management structure
The Tivoli enterprise framework environment is the basic structure for the implementation of the different system management components. This structure can be implemented as appropriate for the management requirements. The following sections show a brief description of the basic components. See the redbook An Introduction to Tivoli Enterprise, SG24-5494 for a more intensive discussion of this topic. TMR server: The TMR (Tivoli management region) server is a minimum installation requirement of the Tivoli enterprise management platform. It is the central management unit in the highest management level. The TMR server includes the binaries, libraries, data files, and graphical user interface needed to manage your Tivoli environment. The TMR server maintains the TMR server object database and coordinates all communications with Tivoli managed nodes and endpoints (through Tivoli gateways). The server also performs the authentication and verification necessary to ensure the security of Tivoli Enterprise data. Managed Node: A Tivoli managed node runs the same software that runs on a TMR server. Managed nodes maintain their own databases, which can be accessed by the TMR server. When managed nodes communicate
31
directly with other managed nodes, they perform the same communication or security operations that they would perform with the TMR server. The managed node is the installation basis for management gateways and other components. Gateway: An endpoint gateway controls all communication with and operations on Tivoli management agent (TMA) endpoints. A single gateway can support communications with thousands of endpoints. A gateway can launch methods on an endpoint or run methods on the endpoints behalf. A gateway is created on an existing managed node. This proxy-managed node provides access to the endpoint methods and provides the communications with the TMR server that the endpoints occasionally require. Endpoint: A TMA endpoint is any system that runs an endpoint service (or daemon). Typically, an endpoint is installed on a machine that is not used for daily management operations. Endpoints run a very small amount of software and do not maintain a database. The majority of systems in most Tivoli Enterprise installations will be endpoints.
Note
The installation requirements of NetView for UNIX require that it be installed on a managed node as part of an existing TMR structure or as a TMR server itself. NetView for NT does not have the requirement of being installed in a Tivoli enterprise framework, but of course it can be installed there.
The Tivoli enterprise framework can be implemented with special applications for the necessary management tasks of complex IT infrastructures. Thus, there are applications for remote controlling, distributed management for controlling of servers and clients and their applications, inventory management, and many others. For the network management tasks, we are especially interested in the communication of NetView with the Tivoli Enterprise Console (TEC) and the Tivoli Decision Support (TDS) application.
32
Figure 10 shows the basic connection of NetView to the TEC and TDS.
T EC
For w ar de ve n ts
e r ie s
TDS
N e tV iew DB
D
u B -Q
SNMP A gent
L A N /W A N
SNMP A gent SNMP A gent

Figure 10. NetView in connection with TEC and TDS
SN MP A g ent SNMP A gent
2.4.1 Tivoli Decision Support (TDS)

The TDS application is the reporting and analyzing engine of the Tivoli system management platform. The application uses available data and database systems for generating reports, statistics, and graphical views about the condition and development of the enterprise IT infrastructure. There are various adapters for the importing and processing of Tivoli Inventory data and importing of databases of the Tivoli Enterprise Console, as well as guidelines for processing distributed monitoring information. In connection to network management projects, TDS plays an important role in processing network data. There are comprehensive functions and tools for the importing of collected network data from NetView. TDS provides reporting and analysis functions for processing collected SNMP data on network utilization and performance which allows you to generate meaningful reports and graphs that reflect the network condition. TDS uses the NetView RDBMS for processing its functions
33
and generating of the reports (see Figure 10 on page 33). NetView collects the required SNMP data for network utilization, CPU performance, and interface throughput in the RDBMS. TDS queries the database for the data required for the generation of needed reports and statistics. Besides processing network performance data, TDS provide tools for the evaluation of network events. NetView collects all network events and traps in the RDBMS database. TDS generates graphical views and analyses from this data. For further discussion of the communication requirements between NetView and TDS, see Chapter 4, Management in distributed environments on page 101. In the TDS there are several guides available that show you how to create meaningful reports and graphs from this data. TDS helps you find the right interpretation and evaluation of the measured enterprise data. This allows you to have an objective overview of the condition and development of the enterprise network and its IT infrastructure. TDS can provide reports and analysis in several styles for the different administrative and executive levels of the enterprise. TDS provides, through its reports and analysis statistics, a basis for the further development of the network and also for the detection of bottle necks and problem fields in the available IT infrastructure. It helps you make the right decision for network investigation in the future. The following Redbooks give you a good overview of the provided functions and opportunities available for the implementation of Tivoli Decision Support, and greater detail on administrating and configuring TDS in different situations: A Design and Implementation Guide for Tivoli Decision Support , SG24-5499 Using Tivoli Decision Support Guides, SG24-5506 Tivoli Decision Support V2.1: New Features and Performance Optimization, SG24-5491
2.4.2 Tivoli Enterprise Console (TEC)

TEC is one of the Tivoli enterprise management applications. The application is mainly responsible for event management and automatization of enterprises. It is the central management application for all events, messages, and faults that will be generated in a complex IT infrastructure. Events can be generated from various resources. The TEC has all required adapters for the processing of traps, events, faults, and messages from the components of the enterprise IT infrastructure, such as servers, clients, applications, and network components.
34
NetView is fully integrated into the event management process of TEC (see Figure 10 on page 33). NetView sends specific events to TEC, which can be filtered in NetView and passed through a NetView rule. In the TEC, these events will be processed according to the defined workflows. For further discussion of the communication between NetView and TEC see Chapter 4, Management in distributed environments on page 101. The Tivoli Enterprise Console provides a very flexible console from where the operational personnel can view the discovered events and perform specific management actions and tasks to solve the detected problems. The TEC provides the solution as a part of the Tivoli management platform as a central point for managing, correlating, and generating automatic responses for the events. TEC allows the processing according to the severity level defined. This allows automatic handling of received events according to priorities you have determined. TEC also has comprehensive features to provide filtering and event correlation facilities to reduce the number of events that the operators will see. Customizeable rules allow the filtering of detected messages and definition of automatic actions. Different roles and access levels and definition of policies provide the distribution of TEC entries to the responsible administrators and operators. For more information about TEC, see the following Redbooks: TEC Implementation Examples, SG24-5216 An Introduction to Tivoli Enterprise, SG24-5494 Early Experiences with Tivoli Enterprise Console 3.7, SG24-6015
2.5 Network management in firewall areas and secure zones

Network management in firewall zones and through firewalls is becoming more important in today s networks. Enterprises now have started appreciating the need for security in their networks. The security of the data and access of only authorized people to the enterprise IT infrastructure and network is one of the most important topics today. Firewalls and other security technologies are described in Section 1.2, The concept of the firewall on page 4. In the enterprise network, there are different security zones and complex security derivatives, such as DMZs, with different access levels that have to be operated, controlled, and managed. Network administrators must have access over firewalls and other security technology along with their management systems. There must be access in order to manage the network components behind the firewalls and security barriers. Partnership and cooperation of enterprises implement corporate
35
networks and extranets where only specific traffic will be allowed through the firewalls. Remote access to network management functions over firewalls has to be allowed so that service providers and network administrators have access to internal network management functions. The following points show some aspects for the network management across firewalls: Managing network components behind firewalls: In enterprises, there are different internal security zones with different access and authorization levels for the users, operators and administrators. Often you can find, for example, network segments in areas with very important customer and enterprise secrets that must be defended against unauthorized access through an efficient firewall system. The availability, reachability, and reliability of these network segments and their components guarantees a comprehensive network management system. It guarantees that only this network management system has access to the provided network management functions of these components over the firewall gateway. See Chapter 3, Management across a single firewall on page 41 and Chapter 4, Management in distributed environments on page 101 for details. Managing network components in DMZ: Another important network area of an enterprise business is the demilitarized zone. As you have seen in Section 1.5, Firewall architectures on page 8, the DMZ is often constricted for the connection of the enterprise network to the Internet. The demilitarized zone is constructed with different security barriers, where the Web, mail and e-business servers are separated from the other intranet segments. The reliable connectivity of enterprises to the Internet and the safety process is very important for the existence of todays enterprises. So you have to manage all the network components that build these areas and constantly control the performance and reliability of the connection to the Internet and its components. See Chapter 6, Network management in the DMZ on page 261 for details. Managing network components of customers (service provider): Today s business developments have more and more specialization of enterprise activities. The companies try to specialize in their core competencies, so network service providers take over the operation of the IT infrastructure. They have to guarantee reliability and 100 percent service delivery of the operated networks. They have to guarantee, in service contracts, Service Level Agreements (SLA), which guarantee the reliability and service delivery for the customer networks. Network management systems are the tools for these guarantees and for early detection and correction of problems in the customer networks before they are escalated. See Chapter 5, Network management through the VPN on page 163 for details.
36
Managing network components of partner networks (extranets): The electronic data exchange between business partners requires a network connection between the involved companies. Extranets realize network connections between the interested firms. Secure extranets make it possible for business partners to share the proper resources in a secure environment. Enterprise overlapping network management systems control the extranets and their availability. See Chapter 4, Management in distributed environments on page 101 for details. Managing network components from outside (remote access): Technician and network administrators need, in emergency situations, remote access to network management functions when fast problem resolution is required. Of course it is guaranteed that only authorized persons are able to get remote access to the network management functions. See Chapter 5, Network management through the VPN on page 163. The chapters that make up Part 2, Network management environments on page 39 show scenarios where the different aspects and problems are discussed. We are concentrating on the communication requirements of network management in order to understand the required firewall rules. This includes the communication requirements for the connection to the Tivoli Enterprise Console and the Tivoli Decision Support application: NetView as managed node in Tivoli region NetView as TMR server Remote access from Java Web client to NetView NetView communication with TEC NetView communication with TDS For further discussion of the other system management aspects in the Tivoli system management platform and their communication requirements in connection with firewalls, see the redbook Tivoli Enterprise Management Across Firewalls, SG24-5510.
37
38
Part 2. Network management environments
39
Chapter 3. Management across a single firewall

In Chapter 2, Network management on page 17, we described some fundamental issues of network management architectures, especially pertaining to environments that encompass firewalls. We have also discussed key business requirements that are important in building an effective network management solution in a secure environment.
3.1 Introduction
This chapter describes the first case study that depicts a real world environment requiring network management across a single firewall. It is the first of a series of scenarios and will address some key communication issues when managing networks across firewalls. Note that our purpose in this redbook is to address communication concerns in network management and not firewall products. It will also describe the different components that make up the network management solution and various issues that may be encountered. While this scenario was the first and most basic architecture of network management from secure to unsecure environment, it is likely to be a foundational building block from which other network management architectures are built upon.
3.1.1 Definition of terms

The following information will describe some of the terms and acronyms used throughout this redbook. SN : UN : NM: Secure Network or Corporate Network Unsecure Network Network management
IBM SecureWay Firewall (SWF) : IBMs firewall software, used in our lab environment. Rule : Refers to the smallest configuration element that describes one specific traffic type permitted between the SN and UN. It will specify criteria, such as source and destination ports, protocol, such as TCP, and direction and fragmentation. The rule is the foundation on which all services and connections are built.
41
Service:
The service in SWF allows you to define a set of rules that are required for a specific type of traffic flow. For example, to allow FTP traffic to flow from the SN to the UN, a number of FTP rules are required. This may include rules to allow ACK, SYNC, DATA packets, and so on, between the two networks. The direction of the flow of traffic for each rule is also specified here. These rules make up a service allows the whole protocol to flow between the networks. You can also specify which time periods that you want to allow the traffic to flow. The connection is the final configuration you register in SWF for traffic to flow. It specifies the very specific network entities that you wish to allow services to flow between and in which direction it flows. You can specify, for example, FTP, telnet, and ping services between Network Managers in the SN to devices in the UN. The generic term used for the firewall. It will mostly be used to refer to the firewall system used at the time. SecureWay defines network objects as a way of defining different entities in your network. This can include a group of machines or whole networks. We will be defining some network objects in Phase 2: Network management across a single firewall on page 53. This is the interface of the FW attached to the unsecure network. This is the interface of the FW attached to the secure network.
Connection:
Firewall (FW) :
Network Object (NO) :
Unsecure Interface (UI) : Secure Interface (SI) :
3.2 General description of the testing environment

In our testing environment, we began by building the primary components of network management and devices that need to be managed. Each phase in
42
building the environment needed to be verified before moving to the next phase. This assisted us in troubleshooting any technical and communication issues that surfaced during the installation. The following components were used in the whole test environment for our first scenario. We will give a description of the components and general technical issues that were considered for using the component in building the environment. Any anomalies or undocumented features were also documented.
3.2.1 Tivoli NetView

The network management platform chosen for all our case studies is Tivoli NetView. We intend to cover aspects of both the AIX and Windows NT platform as well as the differences between the two. The following hardware, products, and release levels were used for the AIX OS platform: AIX Version 4.3.3 on RS6000 43P with 128 MB RAM Tivoli NetView 6.0.1 for AIX The NetView software was installed. The following hardware, products, and release levels were installed for the Windows NT OS platform: Windows NT 4.0 Workstation with Service Pack 5 on PC 300PL with 128 MB RAM Tivoli NetView 6.0.1 for Windows NT
Installing NetView
Please note that Tivoli NetView for AIX can only be installed after the Tivoli Framework software has been installed. While the TMR can be established on the same server as the NetView Server, we installed it on a different AIX server (ITSO8). The TMR shown in Figure 11 on page 47 was installed on ITSO7, as it will also be used to host the Tivoli Enterprise Console (TEC). The NetView Server software could be installed only after ITSO8 has become a managed node of the Tivoli Managed Region managed by ITSO7. Refer to the Tivoli NetView for UNIX Version 6.0 Installation and Configuration Guide, SC31-8442 for further details.
43
3.2.2 Tivoli Mid-Level Manager (MLM)

Tivoli Mid-Level Manager (MLM) is NetView s light weight network manager software that allows the network manager to distribute network management workload throughout the network. This scenario will test the MLM functionality on both the Windows NT and AIX platforms, as well as remote installation steps and communications across the firewall. The following hardware, products and release levels were used for the AIX OS platform: AIX Version 4.3.3 on RS6000 43P with 128 MB RAM Tivoli NetView MLM 5.0 The installation of MLM on AIX was performed from CD-ROM, from the Tivoli Desktop, and from the NetView GUI. The following hardware, products, and release levels were used for the Windows NT OS platform: Windows NT 4.0 Service Pack 5 on PC300GL with 128 MB RAM, 2 Ethernet NICs Tivoli NetView MLM 5.0.4 for Windows NT
Note
Note that installation of MLM on Windows NT can only be performed from CD-ROM. We installed MLM on Windows NT to ensure that communication channels over IP were the same for Windows NT MLM as well as AIX MLM.
3.2.3 IBM SecureWay Firewall

IBMs SecureWay Firewall was chosen as the main firewall product for testing purposes. It was chosen for its availability at the time of testing, and ease of configuration for building rules to allow traffic between secure and unsecure networks. As our purpose for the project is to evaluate the communication between NM components, this firewall served its function. The SecureWay Firewall was installed on the Windows NT version, as it was easier to configure and use compared with the AIX version. The following hardware, products and release levels were used for the Windows NT OS platform: Windows NT 4.0 Service Pack 5 with 128 MB RAM IBM SecureWay Firewall Version 4.1 for Windows NT
44
All methods for discovering which ports were used for communications between NM components were documented, as well as steps to create the appropriate rules, services, and connections used in IBM SecureWay Firewall. For further information on installing IBM SecureWay Firewall, please refer to Appendix A.2, Installation on page 301.
3.2.4 Other tools used

Other tools that were very useful in testing communications across the firewall environment are listed below (as well as were to find them). 3.2.4.1 The nvsnmptrap command This command is the generic command on Tivoli NetView for Windows NT. It can send traps at any time and can be of immense value when you require traps to be replicated and to test scripts. You will need to copy the following files from the Windows NT NetView host s \usr\OV\bin directory to the host where you wish to send traps from: libmib.dll, libov.dll, libovc.dll, libovutil.dll, libovw.dll, nvsnmp.dll, pnvmsg.dll sh32w32.dll, nvsnmptrap.exe Place these files in the \winnt\system32 directory so that all files will be in the path. To send a test trap, you can enter the following as an example:
nvsnmptrap destination 1.3 localhost 3 3 8
Just enter the nvsnmptrap command to get the full syntax of the command. 3.2.4.2 Ethereal Network Protocol Analyzer This tool was immensely valuable in troubleshooting communications between secure and unsecure networks. Ethereal is a freeware network protocol analyzer that can be installed on various flavors of UNIX and Windows. The software can be downloaded from the following site:
http://www.ethereal.com
The Windows NT packet capture architecture library WinPCAP also needed to be installed as a prerequisite to installing Ethereal. It installs a set of packet capture libraries that allow packet capturing for Windows. You can download this package from the following site:
http://netgroup-serv.polito.it/winpcap
45
We installed this on a laptop, as it was portable and can be used to capture packets on the different networks in our environment. See Appendix E, Installing the Ethereal Sniffer on page 341 for more information.
3.3 Phase 1: Network management 101

In a series of phases, we will describe the step-by-step buildup of our network environment for Scenario 1 along with the communications that must be established for our network management tools to function properly. Beginning with the very basic routed network with management, we will work our way to a security zoned networked environment with network management. Finally, we will discuss the security zoned networked environment with a fully distributed network management architecture. Some of the issues that need consideration when planning network management solutions in each of these environments of growing complexity will be addressed.
3.3.1 General topology for Phase 1

Figure 11 on page 47 shows the general topology of our two different networks separated by a router. Note that our router is actually the Windows NT Server (FW1), which will eventually become the firewall between the secure network (10.69.14.x) and our unsecure network (192.168.104.x). In the next phases, we will introduce the firewall function on the router (FW1) and the effects on communications between our NM server managed devices.
46
Figure 11. Phase One topology for Scenario One
3.3.2 Building network components for Phase 1

In this section, we will describe the relevant major steps for building each of the components shown in Figure 11. While we will not provide detailed instructions, we will highlight any important configuration issues that need consideration. 3.3.2.1 FW1 Firewall Server Our first step in building our environment was to establish proper communications between our 10.69.14.x and 192.168.104.x networks. After installing Windows NT 4.0 on FW1, we configured the two interfaces with TCP/IP and IP addresses, as shown in Figure 11. Service Pack 5 was applied after TCP/IP configuration and the server was rebooted. IP routing was enabled so FW1 could function as a simple router between the two networks. This was achieved by simply enabling IP Forwarding by selecting Networking->TCP IP Settings-> IP Routing Tab. The IP Routing tab is shown in Figure 12 on page 48. We then tested the basic routing function by executing a ping from MLM1 in the 192.168.104.x network to ITSO18 in the 10.69.14.x network.
47
Figure 12. IP routing on Windows NT 4.0
3.3.2.2 NetView for AIX The main steps in building a NetView Server are fully documented in the redbook Tivoli NetView 6.01 and Friends, SG24-6019. However, these are the basic steps we used to install and configure NetView 6.01 for ITSO8: 1. Install AIX Version 4.3.3 on the RS/6000 Server, if it has not been installed. 2. Configure TCP/IP communications as shown in Figure 11 on page 47 with the default gateway as 10.69.14.253. If the server already has a default gateway, you may need to add a static route by issuing the command route add 192.168.104.0 10.69.14.253 at the shell prompt. 3. Test TCP/IP communications by pinging ITSO7. 4. If DNS is not available, add the hostname of all the nodes so far in the environment into the /etc/hosts file, especially the TMR server ITSO7. Proper name resolution is especially important, as we discovered that remote installation of MLM requires the AIX rexec command. We needed to properly configure the host file of the MLM2 host file for reverse name resolution as well. 5. Ensure that the SNMP daemon is installed and running. You can check that it is running by running the command ps -ef | grep snmpd in a shell. 6. From the TMR server ITSO7, use the Tivoli desktop to install the managed node software to ITSO8, establishing it as part of the ITSO7 Tivoli Managed Region. 7. From the Tivoli Desktop of ITSO7, insert the Tivoli NetView 6.0 CD in the server and install the Tivoli NetView Server software onto the ITSO8 managed node.
48
8. Install the NetView Database Support module. (This will later be used in the management scenario in Section 4.4, TDS cooperation on page 116, where we will also introduce Tivoli Decision Support, which will use the event data provided by NetView.) 9. Insert the Tivoli NetView 6.01 Patch CD into the server and install the NetView 6.01 Patch Module onto ITSO8. 10. Ensure that NetView Daemons are running by either running ovstatus from the NetView server, or right-clicking on the NetView server icon at the Tivoli Desktop and selecting Control->Display Tivoli NetView Status->Display Status of Daemons. 11. From the NetView Server, open a shell and enter netview at the command prompt to start the NetView GUI client. Ensure that the IP map shows the NetView server. You should be able to see the nodes on your network, as shown in Figure 13. Note that all nodes on our network used public as the default SNMP community string with read-only access, and itso as the community string with read/write access.
Figure 13. NetView IP map topology
12. To ensure that SNMP communications are functioning properly, you can also issue the command snmpwalk itso7 system at the shell prompt. This should return system MIBII SNMP information back from ITSO7, as shown in following screen.
49
root@itso8 > snmpwalk itso7 system system.sysDescr.0 : DISPLAY STRING- (ascii): IBM PowerPC CHRP Computer Machine Type: 0x0800004c Processor id: 000677154C00 Base Operating System Runtime AIX version: 04.03.0003.0000 TCP/IP Client Support version: 04.03.0003.0000 system.sysObjectID.0 : OBJECT IDENTIFIER: .iso.org.dod.internet.private.en terprises.ibm.3.1.2.1.1.3 system.sysUpTime.0 : Timeticks: (6679183) 18:33:11.83 system.sysContact.0 : DISPLAY STRING- (ascii): system.sysName.0 : DISPLAY STRING- (ascii): itso7 system.sysLocation.0 : DISPLAY STRING- (ascii): system.sysServices.0 : INTEGER: 72 root@itso8 >
3.3.2.3 Tivoli NetView 6.01 for Windows NT Installing Tivoli NetView 6.01 for the Windows NT platform is a relatively straightforward process. Again, for further installation instructions, you should refer to the redbook Tivoli NetView 6.01 and Friends, SG24-6019. The only point we should note in the following steps is the installation of Windows NT SNMP service, which is a prerequisite for installing NetView, just as the SNMP daemon is a prerequisite for NetView for AIX. These are the steps we followed: 1. Install Windows NT 4.0 if it has not already been installed. In our environment, the server is ITSO18. 2. Windows NT SNMP Service needs to be installed using the menu path Control Panel->Networking->Services. We rebooted the machine. 3. Service Pack 5 needs to be installed after the SNMP Service is installed; otherwise, an SNMP Service error will occur when rebooting. Install the Service Pack and reboot the machine again. 4. We test to see if the SNMP service is functioning by issuing the snmpwalk itso18 system command from AIX NetView. It should produce a result similar to the one shown in the previous screen figure. 5. Ensure that other prerequisites are met, including Microsoft ODBC drivers versions that are required. 6. Now we were ready to install NetView. After installing NetView, we ran the NetView Console and saw that it was working as it should, with the IP Map containing all the nodes on the local network (as shown in Figure 14 on page 51). 7. For AIX, the Agent Policy Manager daemon C5d also needs to be running in order to enable NetView server to automatically manage MLMs it discovers. NetView for Windows NT automatically offloads polling to
50
discovered MLMs. To register and run the daemon for AIX, following these steps: a. Run the serversetup command. b. Select Configure > Set options for daemons > Set options for Agent Policy Manager daemon. c. Set the appropriate options required, such as logging, and click OK. This will register the daemon in the /usr/OV/conf/ovsuf file. It will start the daemon every time NetView is restarted. d. Run ovstart -v C5d. This will start the daemon. e. Run netmon -a 50. This will issue an action to create a SmartSet collection for the MLMs that netmon discovers. Note this is useful when you want to distribute the load of status of polling of nodes to particular MLMs, as well as allowing MLMs to manage nodes outside their own segment. Refer to the Tivoli NetView Mid-level Manager Users Guide, GC31-8445 and the man page for netmon for more information. f. You can check that the C5d daemon is running by issuing the ovstatus command. You can also check that the MLM SmartSet has been created.
Figure 14. NetView for Windows NT IP map topology
3.3.2.4 MLM1 server (Windows NT) The MLM1 server is used in Scenario 1 to be one of our basic managed devices as well as our Windows NT MLM server. We installed Windows NT 4.0 with TCP/IP configured with the IP address shown in Figure 15 on page 53. The SNMP Service was then installed and tested, as we did with the Windows NT NetView Server ITSO18. The SNMP Service was installed with
51
both a read-only community string ( public ) and a read/write community string ( itso ). The read/write community string is essential as the NetView server sends SNMP set packets to configure the MLM. The MLM software will be installed in the next phase of this scenario. 3.3.2.5 MLM2 server (AIX) At this stage,MLM2 is also used as a managed device for NetView, with only AIX Version 4.3.3 installed, TCP/IP has been configured and the basic SNMP daemon is running. We tested the SNMP agent from ITSO8 and were able to retrieve MIBII information. The only issue to highlight here again is that the read/write community string itso needed to be configured in the /etc/snmpd.conf file. We used the following steps to change the default private community string for read/write: 1. Open the /etc/snmpd.conf file. 2. Search for the line with community private 127.0.0.1... and add the line community itso itso18 255.255.255.0 read/write below it. We copied this line with host itso8 instead of itso18. This will allow only itso18 and itso8 to communicate with this community string. The snmpd.conf file provides documentation on the format for community string entries. 3. We refreshed the snmp daemon to reload the new community strings by issuing the command refresh -s snmpd. 4. We then ran a quick test using the command snmpwalk -c itso mlm2 system from ITSO8 and successfully retrieved system information through SNMP. Again we note that this server is only a managed device running an SNMP MIBII agent. The process of remotely installing MLM for AIX and the communication implications in a firewall environment is one of the main objectives for scenario 1. 3.3.2.6 Phase 1 testing To ensure every component was functioning as it should, we also tested basic SNMP communications across FW1 to MLM1. It was evident that it was functioning properly, because the Computer icon was correctly displayed for MLM1 and MLM2 on the IP Map topology on both NetView for Windows NT and AIX.
Note
Because only the basic SNMP service is installed on MLM1 and MLM2 at this stage, no MLMs will be placed in the MLM SmartSet by NetView at this time.
52
3.3.3 Conclusion for Phase 1

The basic building blocks for Scenario 1 were completed and communications across the basic router functionality on FW1 was established between NetView for AIX and Windows NT and the managed devices MLM1 and MLM2 on the other side of the router. In our next phase we will introduce the IBM SecureWay Firewall, and discover the communication issues that arise when it is installed and the implications for network management between the two networks.
3.4 Phase 2: Network management across a single firewall

In this next phase, we will introduce the IBM SecureWay Firewall on FW1, and establish our Secure Network 10.69.14.x (SN) and Unsecure Network 192.168.104.x (UN). With our NetView servers in the SN and managed devices MLM1 and MLM2 in the UN, we will show a situation that typically arises in corporate networked environments today, where network management servers need to manage devices across a firewall. The method by which we gather our communication requirements between the UN and SN and the steps to implement the firewall rules to allow appropriate communications will be discussed in detail.
3.4.1 General network topology for Phase 2

Phase 2 will introduce the IBM SecureWay Firewall on FW1, which is shown in Figure 15.
Figure 15. Phase 2 network topology for Scenario 1
53
The additional components for Phase 2 include the installation of IBM SecureWay Firewall on FW1 and NetView MLM software for Windows NT on MLM1 and for AIX on MLM2. Our approach in building the firewall configuration is to block all network traffic and progressively build a set of rules, services, and connections that will allow the traffic we require for network management communications to take place. 3.4.1.1 Introducing IBM SecureWay Firewall Until now, the Windows NT Server FW1 has served as a simple IP router between the 10.69.14.x and 192.168.104.x networks. Installing the SecureWay Firewall will distinguish between the SN and the UN. Here we will discuss the main issues when installing and configuring SecureWay Firewall. Further information on installation can be found in Appendix A, IBM SecureWay Firewall installation on page 301. As we mentioned in Chapter 1, Introduction to firewalls on page 3, a firewall installation requires some serious planning and forethought. Fortunately, our objective for the lab environment is to get the firewall installed so it can serve its purpose, that is, it will allow us to control which kinds of traffic can flow between the two networks. Here are the main considerations we undertook during the firewall installation and configuration: 1. Ensure that all the prerequisites for the server are met. As we mentioned in Part One, the system needs adequate resources for processing rules and filters on the traffic it manages. 2. Plan the server interfaces that define our Secure Network and Unsecure Network. 3. Ensure all general connectivity between the two networks that the firewall manages. 4. When hardening the firewall, make sure no important established connections exist between the two networks. Note that the initial installation will require a reboot of the server. You can refer to the full documentation of the IBM SecureWay Firewall installation in Appendix A, IBM SecureWay Firewall installation on page 301.
54
Note
The initial installation will have no rules, services, or connections configured, so all communications between the two networks will be blocked. We will now proceed with some basic rule configurations to allow general network management across the firewall. 3.4.1.2 Rule configuration In Phase Two, the basic services for network management now need to be configured in the FW. The following table is a list of firewall configurations required in this phase.
Table 5. FW1 Firewall configuration for Phase Two
Function Ping ICMP packets from SN to UNa ACK packets from ICMP ping back to SN Ping ICMP packets from SN to UNb ACK packets from ICMP ping back to SN Telnet to UN c
Source ITSO8 ITSO18 (SN) UN
Destination UN
Protocol ping/ICMP
SrcPort >1023
DestPort 8
ITSO8 ITSO18 (SN) FW1 (SN) ITSO8 ITSO18 (SN) UN
echo/ICMPACK
>1023
ITSO8 ITSO18 (SN) FW1
ping/ICMP
>1023
ech/ICMP-A CK
>1023
ITSO8 ITSO18 (SN) UN
telnet/TCP
>1023
23
Telnet ACK packets from UN to SN TFTP to UN d
telnet/TCPACK TFTP/UDP
>1023
23
ITSO8 ITSO18 (SN)
>1023
69
55
Function TFTP data from UN to SN SNMP requests to UN SNMP response data from UN to SN SNMP traps from UN to SNe
Source UN
Destination ITSO8 ITSO18 (SN) UN
Protocol TFTP/UDP
SrcPort 69
DestPort >1023
SNMP/UDP
>1023
161
ITSO8 ITSO18 (SN) ITSO8 ITSO18 (SN)
SNMP/UDP
>1023
161
UN
SNMP/UDP
>1023
162
a. This rule does not allow ping to the firewall FW1 itself, but only through FW1. b. This rule allows ICMP packets to the firewall and back. Specifically, for network management, all interfaces need to be managed, not just the secure interface. c. The Telnet service would generally be required for management of devices, such as UNIX machines, and routers; however, this would depend on your network security requirements. It is included for completeness. d. TFTP runs over UDP. TFTP would be required to devices such as Cisco routers. e. Traps normally sent over UDP are unacknowledged. In Phase Three, we will need to allow traps over TCP from specific hosts.
3.4.1.3 Preparing network objects firewall configuration Before creating the rules and services, it is important that we define some network objects (NO). Objects can be single objects or group objects. The basic objects we created include: NetView for Windows NT NetView for AIX NetView Clients (group of all NetView machines in SN) Secure Network (SN) Unsecure Network (UN) Here are the steps that we followed for creating objects. 1. Open the SWF GUI by selecting Start->Programs->IBM Firewall->Configuration Client . We will assume the GUI is open for all instructions from now on. See Figure 16 on page 57.
56
Figure 16. SWF configuration client
2. In the left pane, double-click on System Administration->Network Objects. This will open a dialog box, as shown in Figure 17 on page 58.
57
Figure 17. Network objects
3. Click on the entry Add a Network Object. This adds single entities to the SWF. 4. Enter the object name. Our first object is NetView NT. 5. Select object type as Interface.
Note
By enabling traffic from only one interface of a host, you tighten the security in your network, but reduce flexibility of traffic flowing from that host. You can specify other attributes for the network object, such as host, which means the network object covers all interfaces of that host. 6. Enter the description, IP Address, and Subnet Mask for the node. See Figure 18 on page 59.
58
Figure 18. Creating network objects
7. Click OK. 8. Repeat the steps 3-7 for: - NetView AIX (ITSO8) - Firewall Secure Interface (10.69.14.253) - Firewall Unsecure Interface (192.168.104.1) - TMR Server (ITSO7) 9. At the Network Objects dialog box, double-click on the entry Add Network Object Group. 10. The group we will create will contain the NetView objects in the SN we have just created. Click Select and select the NetView machines while holding Ctrl, and click OK twice (see Figure 19 on page 60).
59
Figure 19. Network object group
3.4.1.4 Example IBM SecureWay Rule configuration Now let us see how to configure rules from Table 5 on page 55 and build them into services and connections that will allow specific traffic to flow between the networks. We will take the rules that allow SNMP requests from the SN to the UN as our example. Here are the steps we followed in the lab environment to build these rules: 1. Select Traffic Control->Connection Templates and double-click on the Rules icon in the left pane of the SWF. 2. Double-click the top entry for a New rule. 3. The first rule is the SNMP request from the SN to the UN. Here we enter the following details (see Figure 20 on page 61): a. Rule Name and Description. This will be for SNMP Get from the SN to the UN. b. Set the Action. By default, we use Permit to allow traffic using this rule (see note below).
60
c. Set the protocol to UDP.
Figure 20. Creating a rule
d. For source port operation, select Greater than and port 1023. e. For destination port operation, select Equal to and port 161. f. For Interfaces Settings, select Both (by default). g. For Direction/Control:
61
1. Select Routing to both. local means traffic whose source or destination is the FW. route means traffic going through the FW. In the lab, we wanted to be able to perform SNMP requests to the firewall, as well as allow requests to the UN. 2. For Direction, select both. The direction states whether traffic is coming into the FW (inbound) or out of the FW (outbound). By selecting both, we allow traffic to come in and out of the FW (in other words, through the FW). 3. Set Log control to No. 4. Click OK. 5. This is one of the rules required for SNMP requests. We now require a rule for SNMP responses from the UN to the SN. Repeat Step 2. on page 60. 6. Enter the following details (shown in Figure 21 on page 63): a. Rule Name and Description. This will be SNMP Get Response 1, from the SN to the UI of the FW. b. Set the Action. Set the protocol to UDP. c. For source port operation, select Equal to and port 161. d. For source port operation, select Greater than and port 1023. e. For Interfaces Settings, select both. f. For Direction/Control: 1. Select Routing to route. We want traffic that is routed from the UN to the SN. We will not allow any responses to be destined for the FW itself. 2. Set Log control to No. 7. Click OK. The new rules for SNMP requests and SNMP request responses can now be used to create a service for SNMP requests.
62
Figure 21. SNMP response rule
3.4.1.5 Example IBM SecureWay service configuration After creating the firewall rules used to control network traffic, we can now create a SWF service that groups the rules we defined. In our example, we will create a service for SNMP that will encompass all the requirements to allow full SNMP request and return traffic. One thing to note here is that we do not concern ourselves with which direction the traffic will flow in the actual environment (that is, whether it is initiated from the SN to the UN and so
63
forth). In creating the service, we only need to define how traffic flows in respect to the initiator of that traffic. This is done so we can separate the actual requirements that allow this traffic to flow in general from the real environment, so it can be reused repeatedly for different connections. The actual traffic source and destination which controls the actual directional flow of this traffic in our environment is only defined when we create a connection. This will be explained in the next section. These are the steps we used to create the service for SNMP request and return traffic. 1. In the SWF Configuration Client, select Traffic Control->Connection Templates->Services . Refer back to Figure 16 on page 57. 2. Double-click on the top entry with Description Add a New Service, as shown in Figure 22. 3. Enter information in the Service Name and Description fields. In our example, this will be for SNMP Get Requests.
Figure 22. Creating a service
64
4. We now select which rules define this service. In the Service Composition area, click Select, as shown in Figure 23. 5. Select the rules we previously created (SNMP Get and SNMP Response) from the list, and click Apply after each selection. This will add these rules to the service. 6. Click OK. We now have the rules required for the service, as shown in Figure 23.
Figure 23. Service composition
7. As the directional flow of the SNMP response traffic should be directed back to the initiator, click on the SNMP Response Entry in the Rule
65
Objects Window and click the Flow button. The Flow arrow will change to a blue color, pointing in the reverse direction. Remember that this direction is only in respect to the initiator. 8. Click OK to complete the Service configuration. The service is now completely defined and ready to be used to create what SWF defines as a connection. We will create a specific connection using this service in the next section. 3.4.1.6 Example IBM SecureWay connection configuration After we have defined basic rules for traffic flow and grouped these rules into a service, we can now get specific in allowing this service to be permitted between different NOs. In this example, we will create a connection for SNMP Requests between the NetView Client group (SN) to the UN.
Note
By only creating a connection for the SNMP service from the SN (NetView s) to the UN, you also indirectly allow SNMP requests to FW1s UI (since the UI is part of UN). Consider also that SNMP requests from NetView can only be directed to the UI and not the SI, unless another connection is created specifically to the FW itself. Also note that the FW1 will need the SNMP Service installed if configuration and SNMP polling is required. This will depend on the security requirements of the network. If SNMP to the FW is strictly not allowed in the network, then in order to manage the FW through ping you may consider configuring NetViews topology manually for all the FWs interfaces.
Here are the steps for creating the connection for SNMP request and return data. 1. Select Traffic Control->Connection Setup. 2. Double-click on the entry with the description Add a New Connection, as shown in Figure 24 on page 67. 3. Enter the appropriate information in the Connection Name and Description fields.
66
Figure 24. Adding a connection
4. We now select which NO source the connection is permitted to be initiated from. In our example, it is the NetView Clients (NetView Clients referring to the NO label of a group of NetView servers). Click the Select button on the Source field and from the Network objects list, select the NetView Clients group object and click OK. 5. We now select the destination for the connection, which in the example is the UN. Click the Select button on the Source field, and from the NO list, select the Unsecure Network object and click OK. 6. We now select which services are permitted to flow from the source to destination that we have selected for this connection (in our example it is the SNMP Get service. Connection Services area). Click Select, select the SNMP Get service from the list of services, and click OK. See Figure 25 on page 68. 7. Click OK to complete the connection.
67
Figure 25. Connection details
8. After creating the connection, it needs to be activated to test that it functions properly. Click on Control from the Connection List dialog box. 9. Click Regenerate Connection Rules and Activate and Click OK (see Figure 26 on page 69.).
68
Figure 26. Connection control
10. Click Close. The connection is now complete and activated. In the next section, we will show how we tested the service to ensure that it is configured correctly. 3.4.1.7 Testing the connection configuration Each connection will require a different test. For this example configuration, we executed the snmpwalk command from each of the NetViews to MLM1, and were able to receive SNMP data from MLM1. Here is a sample of the test result:
69
root@itso8 > snmpwalk itso7 system system.sysDescr.0 : DISPLAY STRING- (ascii): IBM PowerPC CHRP Computer Machine Type: 0x0800004c Processor id: 000677154C00 Base Operating System Runtime AIX version: 04.03.0003.0000 TCP/IP Client Support version: 04.03.0003.0000 system.sysObjectID.0 : OBJECT IDENTIFIER: .iso.org.dod.internet.private.en terprises.ibm.3.1.2.1.1.3 system.sysUpTime.0 : Timeticks: (6679183) 18:33:11.83 system.sysContact.0 : DISPLAY STRING- (ascii): system.sysName.0 : DISPLAY STRING- (ascii): itso7 system.sysLocation.0 : DISPLAY STRING- (ascii): system.sysServices.0 : INTEGER: 72 root@itso8 >
3.4.2 Polling using SNMP

Prior to NetView Version 6.0, NetView for both AIX and Windows NT could only check the status of nodes using ICMP. NetView Version 6.0 introduces, in the netmon daemon, the facility to poll nodes using SNMP by checking the ifAdminStatus and ifOperStatus values for the interfaces (the only requirement is the nodes managed must support SNMP). This is also useful for checking interfaces that do not respond to ICMP, such as unnumbered serial interfaces on routers. Using SNMP for status checking, you can eliminate the need to open up the ICMP ports on the firewall and eliminate another security hole. netmon automatically configures routers containing unnumbered serial interfaces for SNMP status polling. In addition, you can also set the -P switch to the /usr/OV/conf/oid_to_type file for classes of devices to specify that SNMP should be used for status polling instead of ICMP. This behavior is set in one of three ways: 1. Automatically, if the node has at least one unnumbered interface. 2. Explicitly, by setting the IP address or range of addresses in your netmon seed file. This may be done by using the Server Setup application (select Configure > Set options for daemons >Set options for topology, discovery, and database daemons > Set options for netmon daemon ) by creating an SNMP Status entry using the Network Monitor Seed File Editor (you may also edit the netmon.seed file using a text editor, using the prefix $ to denote an SNMP Status polled node). The SNMP status entry can be created in the Special Features Tab of the Seed File Editor, as shown in Figure 27 on page 71.
70
Figure 27. Netmon seed file editor
Please to the man page for netmon and Tivoli NetView Administrations Guide V6.0 , SC31-8440 for further information.
3.4.3 Troubleshooting techniques

In the next lab environments, we needed some tools and methods of troubleshooting the network environment and especially concerning the FW. This section will provide some methods we used to understand the network traffic we wished to permit across the FW. 3.4.3.1 The IBM SecureWay logging facility The SWF has some built-in logging facilities to log different levels of data to the log files. However, our lab experience suggests that retrieving information to create reports on denied packets is not quite straightforward. Let us take a look at the Logging Facility by following these steps: 1. To open the logging facility, select System Logs->Reporting Facility. The dialog box in Figure 28 on page 72 appears.
71
Figure 28. Log facilities
2. Double-click on the entry <NEW>. The dialog box shown in Figure 29 will appear.
Figure 29. Adding log facilities
3. For Facility, choose Firewall Log.
72
4. For Priority, choose Warning. The priority specifies the level of detail of log messages. Warning is adequate for viewing denied packets, which we require for debugging firewall rule configurations. 5. Enter a name for the log file. Ensure that you place the file on a disk partition with adequate space (depending on how much traffic will be tested). We noticed that when specifying Debug priority, the log file grows very quickly and can cause the Firewall to lock up and even stop functioning. 6. Click OK to complete. 3.4.3.2 Reporting from the log file The log file that is created is only a raw text file that is difficult to read and decipher. However there is a log conversion utility that comes with SWF called fwlogtbl. This utility converts the log file into a set of table files used for importing into an RDBMS. The only resulting file that we need to use is f_match.tbl. You can search for more details in the online documentation; however, we used the following command to convert the log:
fwlogtbl -w -d c:\temp firewall.log
where -w overwrites any existing files (-a to append), -d is the destination directory for the table files, and firewall.log is the raw log file to convert. The raw log files are, by default, searched for in the \Program Files\IBM\Firewall\log directory, unless the full path is specified. A sample of the resulting f_match.tbl is shown below:
C:\> fwlogtbl -w c:\temp d:\firewall\log\firewall.log 2001-02-06-18.12.05.000000;fw1;92;1036;22;deny;inbound;10.69.14.18;255.255.255.255;udp ;68;67;route;secure;non-frag;0;none;276;local4.log;1;0;A;;;;10.69.14.253 2001-02-06-18.12.09.000000;fw1;92;1036;22;deny;inbound;0.0.0.0;255.255.255.255;udp;68; 67;route;secure;non-frag;0;none;576;local4.log;2;0;A;;;;10.69.14.253 2001-02-06-18.12.27.000000;fw1;92;1036;22;deny;inbound;10.69.14.254;224.0.0.1;(2);0;0; route;secure;non-frag;0;none;28;local4.log;3;0;A;;;;10.69.14.253 2001-02-06-18.12.49.000000;fw1;92;1036;22;deny;inbound;0.0.0.0;255.255.255.255;udp;68; 67;route;secure;non-frag;0;none;576;local4.log;4;0;A;;;;10.69.14.253 2001-02-06-18.13.12.000000;fw1;92;1036;22;deny;inbound;10.69.14.27;255.255.255.255;udp ;1729;9494;route;secure;non-frag;0;none;566;local4.log;5;0;A;;;;10.69.14.253
You can see clearly the packet details, its direction to the firewall (inbound), source and destination addresses, and so forth. You can easily use this command in a script to automate the log file conversion and filter the file according to source or destination address, and create a firewall block report. Here is a reporting Perl script (fwlogfil.pl) we wrote to filter the f_match.tbl file,
73
based on either source address, destination address, or both, and output to a file. The script is listed in Appendix D.1, IBM SecureWay Log Reporter on page 335.
Perl Installation
To run the script, you will need Perl installed on the system with the script (you can download most versions of Perl compilers from www.activestate.com or www.perl.org). Once installed, you can simply execute it from the command line, or combine it in a batch file, if you always use the same log and output files. The syntax for the script is:
fwlogfil.pl [-s source host/IPaddress] [-d destination host/IPaddress] reportfile
Also make sure the script is in your environment path before running the script or else it will not be found, unless you specify a full path to the script (it is simpler to add a Path entry to your scripts directory). Here is a sample output from the script to filter an f_match.tbl log file:
IBM SecureWay Firewall Block Report Date: 2001-02-06-18.36.36.000000 Protocol: udp Source/port: 192.168.104.1[137] --> Destination: 192.168.104.253[137] Status: deny Dir: outbound Date: 2001-02-06-18.36.37.000000 Protocol: udp Source/port: 192.168.104.1[137] --> Destination: 192.168.104.253[137] Status: deny Dir: outbound Date: 2001-02-06-18.36.39.000000 Protocol: udp Source/port: 192.168.104.1[137] --> Destination: 192.168.104.253[137] Status: deny Dir: outbound Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] --> Destination: 192.168.104.253[139] Status: permit Dir: outbound Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] --> Destination: 192.168.104.253[139] Status: permit Dir: outbound Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] --> Destination: 192.168.104.253[139] Status: permit Dir: outbound Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] --> Destination: 192.168.104.253[139] Status: permit Dir: outbound
3.4.3.3 Tracing communications using a sniffer In this section, we will demonstrate how a sniffer such as Ethereal or the Windows NT Network Monitor can trace the communication protocol details for an application. We will use our SNMP request and response as a simple example.
74
Note
The Ethereal Sniffer runs in promiscuous network mode and can capture all packets that pass the hosts ethernet network card. The native Windows NT Network Monitor is non-promiscuous and only captures packets to and from the host. Only the Microsoft SMS version Network Monitor runs in promiscuous mode. Ethereal was used because of its comprehensive coverage of features, including filtering different protocols, ease of use, and support of multiple platforms; also, it is freely available. Please refer to Appendix E, Installing the Ethereal Sniffer on page 341 for installation documentation of the Ethereal Sniffer. Here are the steps we used to capture a trace of an SNMP communications exchange between ITSO8 (NetView for AIX) and MLM1: 1. Ensure that the Ethereal Sniffer is installed properly. See Appendix E, Installing the Ethereal Sniffer on page 341 for help. 2. Attach the sniffer host to either side of the firewall FW1. (Note that for troubleshooting other scenarios, you may need to attach the sniffer to the network of the host that you suspect is having communication problems). We will attach the sniffer host to the UN for this example, as shown in Figure 30 on page 76. 3. Configure the sniffer host with the appropriate network IP address and mask for that network. We chose 192.168.104.7 and 255.255.255.0. 4. Disable SWF so all communications can flow freely between the SN and UN. To do this: a. Select System Administration, and then the Security Policy icon b. Select the Test Routing option and click OK. c. Click Yes and OK to regenerate the rules.
75
Figure 30. Sniffer host placement
5. Launch Ethereal and select Capture->Start Capture. 6. Set the name of the file for output and any filters, and click OK. See Figure 31 for details.
Figure 31. Start packet capture
7. At the shell prompt from NetView AIX (ITSO8), run snmpwalk mlm2 system.
76
8. After the response from the snmpwalk command completes, click STOP on the Capture box shown in Figure 32. 9. The captured packets will be displayed on the Ethereal panel, with detailed descriptions of each packet structure and data in the middle and bottom panes. You can select, for example, an SNMP Get packet and see the port details and SNMP response data, as shown in Figure 32.
Figure 32. Live capture and results
3.4.4 NAT and firewalls

If Network Address Translation (NAT) is used on the Internal Firewall, then in order to correctly translate the data payload in the SNMP packets to the correct IP address, Tivolis Comprehensive Network Address Translator (CNAT) can be placed between the Internal Firewall and NetView, as shown in Figure 33 on page 78. In this example, we have two networks that use the same network address (10.69.14.0). Since TCP/IP does not handle communications between duplicate addresses, NAT is used on the firewall to translate the external network to the 192.168.104.0 address. However, in the instance when SNMP packets are being sent from NetView to the translated network address, the TCP header will be translated to send the packet to the right destination, but the actual data payload returned could possibly contain true network addresses. As these addresses inside the payload (such as ARP addresses) are not translated by the firewall NAT function, this
77
information will be erroneous to NetView in the corporate network (as nodes are known to NetView by their translated address only).
Figure 33. CNAT and NAT
CNAT can be configured to perform the payload translation on different SNMP object identifiers as well as extend for almost any additional MIB that require payload address translation. See the redbook Tivoli NetView 6.01 and Friends, SG24-6019 for further information on network management using CNAT and NAT.
3.4.5 Conclusion for Phase 2

We have now introduced the functionality of the IBM SecureWay Firewall and showed how we can configure rules, services, and connections to allow simple network management across the firewall. Table 6 on page 79 and
78
Table 7 are a summary of the list of services and their rules, as well as the connections which we have implemented for Phase 2.
Table 6. Service and rule Configuration for Phase 2
Services Ping
Rules Pinga Ping Response
Protocol ICMP ICMP echo TCP TCP/ACK UDP UDP UDP
Src Port 0 8 >1023 23 >1023 >1023 >1023
Dst Port 8 0 23 >1023 161 161 162
Telnet
Telnet requestb Telnet response
SNMP Request
SNMP Get SNMP Get Response
SNMP v1 Trap
SNMP UDP Trap
a. Note that some rules are already included in the default SWF installation such as Ping, Telnet and so forth. b. While Telnet is not absolutely essential if availability is the only concern when managing a network across the FW (for example you may have dial-in access when problems occur), it provides instant access to configuring devices with telnet daemons across the FW. If no security policy is breached, we would recommend implementing the Telnet service.
Table 7. Connections and services for Phase 2
Connection SNMP out secure network Ping out secure network Ping FW Telnet out secure Traps in secure
Services SNMP Request
Source NO NetView Clients
Dest NO Unsecure Network
Description Allows SNMP requests from NetViews to devices in the UNa Allows NetView to ping UN devicesb Allows NetView to FW1 Allows NetView to telnet to UN devices Allows SNMP v1 traps over UDP from UN devices
Ping
NetView Clients NetView Clients NetView Clients Unsecure Network
Unsecure Network FW1 Unsecure Network NetView Clients
Ping Telnet SNMP v1 Trap
79
a. By default, the connection for both SNMP and Ping will allow NetView to also poll FW1s unsecure interface. However, because SWF turns off SNMP services on FW1 by default, and there may be security concerns when running SNMP of a FW, we recommend placing another connection specifically to the FW or placing the SI NO in the Unsecure Network NO group. When no SNMP is running on the FW, the only way to monitor the FW interfaces is via Ping. b. See Footnote a.
3.5 Phase 3: Distributed network management across firewalls

Up till now, we have progressed from an environment with simple network management within an unsecure network to one where communications traverse a single firewall. In this phase, we will now create the environment for distributed network management using Tivoli NetView. This will involve the use of the Mid-Level Manager agent (MLM) for both Windows NT and AIX. We will also show the configuration of communication requirements to allow NetView and MLM to properly communicate, and also the facility to remotely install MLM software to designated MLM servers running AIX from NetView servers on the SN.
3.5.1 General network topology for Phase 3

Figure 34 shows the network topology for phase 3, as well as the communication flows between NetView and MLM.
Figure 34. Network topology and communications for Phase 3
80
3.5.2 Introducing NetView Mid-Level Manager

NetView s MLM software allows the network manager to fully distribute the polling and data collection function to various intermediate level SNMP-based managers. This allows you to reduce the processing load on the central manager as well as reduce network traffic across expensive network links. MLM can also be used to filter traps at a local network level to further reduce unnecessary trap traffic.
3.5.3 Installing Mid-Level Manager

MLM software runs on a number of platforms, including Windows NT and many flavors of UNIX. We tested MLM on both Windows NT 4.0 and AIX Version 4.3.3 in our lab environment. In this section, we will summarize the steps for local installation from CD-ROM on both platforms, and remote installation on AIX from both the NetView GUI client and the Tivoli Desktop. As remote installation of MLM on AIX requires communication across the FW, we will shutdown the FW and analyze the communications that occur. We can then implement the required configuration on SWF to permit these communication requirements. 3.5.3.1 MLM on Windows NT Installing MLM on Windows NT is very straightforward. The MLM software runs on top of the standard SNMP service for Windows NT. Prerequisites The main prerequisite for MLM is that the SNMP service must be installed and configured correctly with both a read-only string and a read-write community string. The read-write community string is required, as the MLM is remotely configured using SNMP Set commands from the NetView clients. Steps for Installation 1. Insert the Tivoli NetView for Windows NT CD-ROM into the Windows NT server designated to be an MLM. 2. When the automatic installation screen displays, click the Install the Attended MLM option. 3. Click Finish and follow the instructions on the screen. 4. When asked if you wish to start MLM, click No and continue.
81
3.5.3.2 Local MLM installation on AIX There are two components that can be installed on AIX. One is the smmlm software, which is the actual MLM agent, and the mlmcfg, which allows you to configure the MLM locally. Prerequisites The main prerequisites are: AIX Version 4.1.5 4.3.3. X Window System Version 11.4 or later (for MLM Configuration Application). OSF/Motif Version 1.2 or later (for MLM Configuration Application). TCP/IP (ensure that the bos.net.tcp.server module is installed). The snmpd daemon is installed and functional. The read-only and read/write community strings are configured for snmpd. Steps for installation 1. Insert and mount the Tivoi NetView 6.0.1 CD_ROM on /mountpoint. 2. Run smitty install. 3. Select Install/Update from all available software, enter /mountpoint/MLM/AIX/MLM-AIX.5.0.1 for the path, and select OK. 4. Change the Preview Only field to No. 5. From the Software to install field, select F4 to get the list. 6. Select smmlm ALL to install MLM and press Enter. 7. Press Enter again twice to install the software. To install the mlmcfg configuration software, repeat the above steps, with the step 3 path changed to /mountpoint/MLM/AIX/CFG-AIX5.0.1, and in step 6, select mlmcfg ALL. 3.5.3.3 Starting and stopping MLM The following information shows how to start and stop MLM. On Windows NT After installing MLM, we recommend you stop the SNMP service through the Control Panel or by running net stop snmp at the command line. To start MLM, enter:
midmand -start
This will start both SNMP service and MLM. To stop MLM, enter:
82
midmand -stop
You can enter midmand only, and it will give all the options available. On AIX To start MLM, run:
midmand
To stop MLM, run:

midmand stop
You can refer to the TME 10 NetView for AIX Version 5 Release 1 MLM User s Guide, GC31-8448 for more information.
3.5.4 Configuring NetView

NetView needs to be configured properly or else it will not properly distribute polling to MLMs. The Agent Policy Manager (APM) daemon needs to be registered and running. APM works with nvcold to manage NetView s SmartSets, and also allows you to easily change configurations on multiple MLMs using configuration profiles. NetView s netmon daemon also needs to be configured properly to distribute polling load. Here are the steps we used to configure NetView for MLMs: 1. At the shell prompt, change the directory to /usr/OV/lrf. 2. Edit the netmon.lrf file and add the parameters -g, -z before the words :OVs_WELL_BEHAVED. The file contents should look like the one shown in the following screen. Note that you could also use an MLM seed file and use -Z mlmseedfile if you wished to specify which MLMs to use. The -g parameter instructs netmon to distribute status polling to MLMs it discovers, and the -z instructs netmon to distribute discovery of new nodes to the MLM (for nodes in the MLMs network).
83
Note
You can utilize MLMs a number of ways: The MLM can filter, threshold, and forward traps from devices. By adding -g to the netmon.lrf file, NetView will distribute polling to the MLM. By adding -z to netmon.lrf, NetView will distribute discovery of new nodes to the MLM. These can be configured in any combination.
netmon:/usr/OV/bin/netmon: OVs_YES_START:nvsecd,ovtopmd,trapd,ovwdb:-P,-S,-s/usr/OV/conf/netmon.seed,-u,-g, -z:OVs_WELL_BEHAVED:15:
Note
The product documentation for MLM 5.04 mentions to place the -a 50 as a parameter in the \usr\OV\lrf\netmon.lrf file, but we have found this to stop netmon from starting. The -a parameter is an action parameter and is normally used at the command line. 3. Run ovdelobj netmon.lrf. This unloads the current local registration for netmon. 4. Run ovaddobj netmon.lrf. This reloads the netmon daemon registration with the new parameters. 5. Run ovaddobj C5d.lrf. This is the local registration file for the APM and will load the daemon to start automatically. The APM needs to be running or else NetView will not recognize MLM nodes as actual MLMs. 6. Enter ovstop netmon to stop netmon. 7. Open the NetView GUI and select Options->SNMP Configuration. 8. Add an entry for the two MLMs, with public for the read community string and itso for read/write community string. This will allow netmon to automatically configure information (such as trap destination) and distribute polling of known nodes in the MLMs network to the MLM. See Figure 35 on page 85 for details.
84
Figure 35. NetView SNMP configuration for MLM
9. Enter ovstart -v to run APM s C5d daemon and netmon. 10. At the command line, run netmon -a 50. The -a 50 flag is an action to create an MLM SmartSet group to manage MLMs (this is only used if you are using -g with netmon). NetView should now have created a SmartSet for MLMs it is using. NetView should now be ready to use MLMs it discovers, and distribute status and discovery polling accordingly. Figure 36 on page 86 is what you should see on the NetView GUI.
85
Figure 36. NetView with APM installed
3.5.5 Testing communications between NetView and MLM

Once we have locally installed NetView for both Windows NT and AIX, we tested the basic communication channels between NetView s smconfig configuration facility for MLM. The smconfig tool allows you to configure remote MLMs and view information, such as trap logs, node status, and data collected. NetView communicates with MLMs using the SNMP get and SNMP set commands. NetView by default sets MLMs to send traps via TCP and not UDP. This is because MLMs are suppose to only send critical trap events to the MLMs manager(s) and standard traps, which run over UDP, are, by definition, not reliable. Traps sent over TCP ensure, to a greater extent, that the trap events will reach the NetView manager.
UDP versus TCP
If security policies in your environment do not allow TCP connections from the UN to the SN, then you need to configure the MLMs to send traps via UDP and not TCP. This is done by changing the port settings in the trap destination table entry using smconfig. Traps sent over TCP are more reliable, but requires more ports to be open on the FW. Another solution would be to use trap forwarding using UDP, encrypting the traps through an SSH tunnel to a SecureShell daemon on NetView. This would also hide any traps from a potential sniffer on the network. See http://www.openssh.org for more information.
86
First, we stopped the MLM software on MLM2 to avoid polling distribution complexity (with MLM2 running basic SNMP), and focused on only using MLM1 for the lab. After selecting MLM1 on the IP Map of NetView, we launched the MLM configuration tool by selecting Tools->MLM Configuration Application. By observing the details in the trap destination and alias table, for example, you can check if NetView has automatically discovered and set itself as a trap destination for the MLMs traps. You can also see if it has off-loaded any of its nodes in the MLMs network to the MLM for status and discovery polling. The Alias Table for MLM1 in Figure 37 shows a sample of what you should see in the Alias table.
Figure 37. MLM alias table
When you can verify that NetView has created entries for aliases of hosts to poll in the network as well as the trap destination entry, then the MLM configuration via NetView is functioning correctly.
87
Our next step is to test our traps from MLM1 to NetView. As we mentioned previously, traps are sent via TCP port 162 by default (however, to really understand how traps were being sent from MLM, we later used the Ethereal Sniffer for protocol analysis). From the analysis, we can create the appropriate new configuration for SWF. We configured MLM (in this example, we used the MLM1 on AIX) to test for node down events by opening the Interface Polling panel from the smconfig, as shown in Figure 38. We changed the status polling interval for our test node sniffer (IP 192.168.104.7) to 10 seconds to hasten the response from MLM. The Interface Status Table is shown in Figure 38.
Figure 38. MLM interface status table
88
The FW at this stage was turned off to allow full traffic flow between the UN and SN. After starting the Ethereal Sniffer to capture packets, we then pulled our Ethereal Sniffer s network cable from the hub and waited for a trap response from MLM. This was observed both at the Event Viewer on NetView, as well as the packet capture session. From the packet capture, we can see the TCP conversation in detail. A clearer version of the TCP conversation between MLM1 and NetView is shown in Figure 39.
Figure 39. Packet capture for MLM traps to NetView
3.5.6 Analysis of results

The diagram in Figure 40 on page 90 shows a description of the TCP conversation. From this diagram, we can create then create the rules, service, and connection for the traps from MLM. Note that the traffic overhead is substantially greater than for normal traps.
89
Figure 40. TCP conversation from MLM to NetView
Table 8 shows the additional rules we created in SWF as a result of the packet capture. Table 9 shows the new connection for the service.
Table 8. Service and rule configuration for MLM traps to NetView
Services MLM Traps to NetView
Rules TCP Trap TCP Trap Response
Protocol TCP TCP/ACK
Src Port >1023 162
Dst Port 162 >1023
Table 9. Connection for MLM traps to NetView
Connection MLM Traps to NetView
Services MLM Traps to NetView
Source NO MLM Hostsa
Dest NO NetView Clients
Description Allows SNMP traps over TCP from MLMs
a. In this lab, the Unsecure Network consists of only MLM nodes. In normal circumstances, a new NO group for MLM hosts would be created and used as the source NO.
90
3.5.6.1 Testing the configuration Once the above configuration was added to the SWF, we reactivated the SWF (using the Security Policy dialog box) by depressing the option to Test Routing and recompiling the rules. Again, we detached and attached our test node that was monitored by MLM1, and verified that node-down/up traps were successfully transported from MLM1 to NetView.
3.5.7 MLM remote installation

Our final requirement in Phase 3 is to configure communications to allow the MLM software to be successfully installed from a remote NetView server. The remote installation can be performed from both the Tivoli Desktop and the NetView Console. Once again, we used our Ethereal Sniffer to capture the TCP conversation between NetView and the MLM host. 3.5.7.1 MLM installation We prepared the sniffer to capture the TCP conversation between MLM and NetView during remote installation. These were the steps we took to install MLM from the Tivoli Desktop. Note that the firewall was deactivated during this time. 1. From the Tivoli Desktop, right-click on the NetView Server and select Administer MLMs->Install/Control the MLM on a node. 2. Change the MLM host field appropriately. 3. Enter the root password of the MLM host. 4. Enter the full path of the install image source as /cdmountpoint/MLM/AIX/MLM-AIX5.0.4. 5. Start the Ethereal screen capture. Click OK to start the install. See Figure 41 on page 92 for more details. 6. Verify from the results that the image was installed correctly without errors. See Figure 42 on page 92 for more details. 7. Stop the packet capture to analyze the results.
91
Figure 41. MLM remote installation from the Tivoli Desktop
Figure 42. MLM installation output
92
3.5.7.2 Analyzing the results From the packet capture, we discovered that two new protocols were being used by NetView to install the MLM software remotely. Figure 43 shows the Ethereal packet capture for the initial FTP of the MLM image.
Figure 43. MLM remote installation analysis - Part One
From our capture, we observed that the FTP process is standard and did not use any unfamiliar ports. The source port of NetView is allocated according to what is available. Two consecutive source ports from NetView are allocated at the establishment of the FTP session, both of which will be greater than 1023. We can see that while the initial destination port from NetView is 21 (which is the channel for all control data), the transmission of data actually comes from FTP-DATA port 20. Acknowledgements for both control and data are required. After the image has been transferred, a remote execute command
93
through the rexec protocol is used to actually perform the remote installation. The second part of the capture as shown in Figure 44 on page 94 (shows the conversation for the rexec command).
Figure 44. Remote MLM installation analysis - Part Two
Figure 45 on page 96 shows the overall communication channels that are used. From this analysis we can generate the new rules, services, and
94
connections to allow remote MLM installation through the firewall. These rules, services, and connections can be found in Table 10 and Table 11.
Table 10. Service and rule configuration - MLM remote installation from NetView
Services FTP
Rules FTP Control FTP Control Response
Protocol TCP TCP/ACK TCP TCP/ACK TCP TCP/AC
Src Port >1023 21 >1023 512 >1023 5000
Dst Port 21 >1023 512 >1023 5000 >1023
Rexec
Rexec Rexec Ack
Complex
Maina
Complex Main Complex Main Ack
a. The Complex Main service is required for rexec. It is initiated from the destination to the source.
Table 11. Connection for MLM remote installation from NetView
Connection
Services FTP
Source NO NetView Clients NetView Clients Unsecure Network
Dest NO MLM Hosts MLM Hosts NetView Client
Description Allow FTP from NetView to UN Allow rexec from NetView to UN Allow Complex Main comms to NetView
MLM Remote Installation
Rexec Complex Main
95
Figure 45. MLM remote installation communication summary
Table 12 shows generic communication information required for MLM remote installation.
Table 12. General communications for MLM remote installation
Function FTP Control FTP Control Response Rexec Rexec Ack
Source NetView Clients MLM Hosts NetView Clients MLM Hosts
Destination MLM Hosts NetView Clients MLM Hosts NetView Clients
Protocol TCP TCP/ACK TCP TCP/ACK
SrcPort >1023 21 >1023 512
DestPort 21 >1023 512 >1023
96
Function Complex Main Complex Main ACK
Source MLM Hosts
Destination NetView Clients MLM Hosts
Protocol TCP
SrcPort >1023
DestPort 5000
NetView Clients
TCP/ACK
5000
>1023
3.5.7.3 Testing remote installation communications We implemented the configurations, as shown in Section 3.5.7, MLM remote installation on page 91, and restarted the SWF. We verified that the installation was successful and thus confirmed the FW configuration required. We also tested the installation from the NetView Console Administer menu, and verified that the installation process is essentially the same as that from the Tivoli Desktop.
3.5.8 Conclusion to Phase 3

We have examined the requirements for the remote installation and management of NetView MLM across the firewalls and successfully configured the FW to permit these communication channels. This, in addition to the information that allows other related management protocols to the UN (as described in Phase 1 and Phase 2), encompasses the knowledge required to implement distributed network management using NetView and Mid-Level Manager in a firewalled environment. In our next section, we will discuss some of the security implications associated with using network management and MLMs across the firewall.
3.5.9 Security considerations

In these phases, we have allowed a number of protocols to flow between the networks. However, in real environments, a number of these protocols will most likely be against enterprise security policies. All of these protocols can be analyzed using a sniffer (as we have seen) and passwords, sessions, and other kinds of information are easily exposed. FTP, for example, uses unrestricted port ranges from the destination to the host and thus cannot easily be managed without opening a large range of ports in one direction or another. Strict security policies would definitely deny opening such port ranges. FTP is transparent in nature and data transferred is unencrypted. Telnet is also transparent and user names and passwords can easily be stolen. Telnet is considered more secure in that it only requires one port, but again is prone to attack. However, in most cases enterprises
97
would probably allow the telnet protocol out from the secure network to the unsecure network only, simply because telnet is a standard protocol that can be used to manage a large number of IP devices. It should be stressed that the firewall should only allow telnet from the network management servers to managed devices and in only this direction. Another protocol that is necessary is SNMP. SNMP requests are generally harmless in nature, but can prove quite powerful and even dangerous, especially when SET community strings are used to remotely configure devices. Most environments today still use SNMP v1 and v2, which is transparent and does not encrypt its data, and could easily be captured. While data transferred by requests are usually not that sensitive, SNMP agents today are becoming more sophisticated and can contain information such as equipment types used, contact details, and community strings. SNMP v3, as discussed in Section 2.2.1, IP network communication on page 21, is more secure and could be deployed to managed devices. However, there would be a need to also install and deploy v3 compliant agents, which are not very widespread at this stage. One consideration when using SNMP is to configure the FW to only allow SNMP requests in one direction from known hosts, such as the NetView servers (which we have done in our lab). The other consideration is to also configure the SNMP agents on managed devices to only accept SNMP requests and sets from known hosts. This will at least tighten security for SNMP traffic. The same considerations would also be required for SNMP traps from the UN to the SN. The FW should also be configured to receive traps in one direction to network management devices. Many routers today still use the TFTP protocol, which is also unsecure but necessary for remote transfer of new code. However, new systems today could employ new solutions such as SecureShell (SSH) to encrypt communications between devices. In fact, by using SSH, we could set up secure sessions to managed devices and possibly tunnel other protocols that communicate on singular ports. Some of the latest Cisco routers use SSH1 for remote communications to management hosts. It could be even possible to establish a SSH session between the MLM and NetView and securely transport all traps forwarded to the MLM through the SSH tunnel to NetView. We will discuss SSH and other protocols in the next few chapters. We have documented what is required for remote management and installation of MLMs. However, the remote installation facility or any of the remote facilities provided by the Tivoli Desktop or NetView console will involve the use of the rexec protocol. As most firewall and security administrators are aware, the rexec protocol is not a secure protocol and is prone to attacks. Thus, it is not recommended that the remote installation or
98
management facilities be allowed across firewall implementations. The most secure way is to locally install the MLM on the server from a CD-ROM, and ensure that the MLM starts up at boot time (which is default). Configuration can then take place by SNMP and, if necessary, via SSH if it is deployed. Different network environments will enforce different management priorities, so we need some flexibility when architecting a solution for management. The key issue is that one can be aware of the concerns and implications for both network management and security. We will discuss some more secure ways of handling network management traffic in the next few chapters.
99
100
Chapter 4. Management in distributed environments

In this chapter, we will describe, in greater depth, the network management scenarios of today s service providers (SP). We will discuss the different requirements and problematic situations that can arise in network management implementations in the context of firewalled environments. We may not cover all types of situations that can occur, but we will try to introduce concepts using different scenarios. This information can serve as a starting point for network management projects in these kinds of situations. Our principle service provider scenario is shown in Figure 46.
Figure 46. Network management in SP networks
The structure shown embodies a typical service provider environment. The provider wants to manage separate customer networks that are connected to the providers network infrastructure over a firewall implementation. He wants to receive and control the traps and events which will be generated from the network devices. After using filters and rules to process severe and relevant traps, these will be sent to the Tivoli Enterprise Console (TEC). The events
101
will be processed by responsible operators and provide information to the TDS system for further analysis. Furthermore, there is the requirement to document and report on the network performance and the utilization of network components using SNMP data collected from the relevant MIB object entries. The SNMP data and trap information is then stored in a central database system, such as Oracle. The Tivoli Decision Support system can query the archived data for further analysis and documentation of Service Level Agreements (SLAs) for the different customer networks. The provider must carefully consider where he has to place his network management systems for the effective management of customer networks. Different distributed management concepts are applicable: How should the provider implement the data communications for the required system management functions of TEC and TDS? The provider also needs to understand the issues of integrating Tivoli framework and network management and what is recommended with respect to network security. Which communication ports have to open for secure data connections between the secure and unsecure network.
Note
For relatively small networks behind the firewall, it is possible to open the firewall for SNMP management from NetView out of the service provider network into the customer networks. For large discovered networks and from a security standpoint, we have shown in Chapter 3, Management across a single firewall on page 41 that it is advisable to implement a distributed network management solution using MLMs or separate network management servers in the customers network, which we will discuss in following sections.
4.1 Test environment

Figure 47 on page 104 shows the basic network and systems that we have used to provide the necessary environment for testing and analyzing the different tasks and requests. The following systems and software components were used:
102
The TMR server is installed on a RS/6000 server that has AIX Version 4.3.3 installed on it. It is based on Tivoli Management Framework Version 3.6.3. It also includes the TEC Server Version 3.6.3 application and Oracle Database Version 8.1.5 for hosting the required TEC and NetView databases. The network management servers itso8 and fwnv1 with NetView for UNIX Version 6.0.1 are installed on a RS/6000 server that has AIX Version 4.3.3 installed on it. NetView NT Version 6.0.1 is installed on the Windows NT 4.0 SP 5 workstations itso18 and fwnv2. Tivoli Decision Support Version 2.1 is installed on the Windows NT 4.0 SP 5 workstation itso18. For the firewall system FW1, we used IBM SecureWay Version 4.1 Firewall and Check Point FireWall-1 Version 4.1 with service pack 2 installed on a Windows NT 4.0 SP 5 server. See Appendix A, IBM SecureWay Firewall installation on page 301 and Appendix B, Check Point 2000 enterprise suite with Firewall-1 4.1 on page 311 for a basic firewall installation and configuration process.
103
Figure 47. Test environment
4.2 Distributed management with MLMs

For completeness sake, we will also describe a solution for the above described service provider demands with distributed MLMs. We have already discussed the MLM implementation and configuration in detail in Section 3.5, Phase 3: Distributed network management across firewalls on page 80, so we will only describe the basic concepts. Figure 48 on page 105 shows a distributed network management solution designed with MLMs in the customer network. One NetView network management server is installed in the SP network. The server uses SNMP to communicate with the MLM agents.
104
Figure 48. Distributed management with MLMs
The MLM agents perform device polling. MLM agents also collect the required network SNMP data from the controlled devices. The only required communication through the firewall is the SNMP-communication between NetView in SP-Network and the subordinate MLM-agents. This would also include ICMP, unless you defined the MLM as an SNMP status polled node in NetView. Table 13 shows a summary of required communication rules for the firewall configuration.
Table 13. Communication rules for distributed management with MLMs
Function SNMPRequest SNMP-Re ply SNMPTrap
Source NetView in SP Network MLM-Agent in Network A+B MLM-Agent in Network A+B
Destination MLM-Agent in Network A+B NetView in SP Network NetView in SP Network
Protocol UDP UDP UDP
SrcPort >1023 161 >1023
DestPort 161 >1023 162
When building solutions using MLMs, you must consider the following: MLMs do not do configuration polling of subnets. So this solution will be implemented for the operation of static network situations that control reachability and SNMP polling of static resources. MLMs can only discover one subnet. In large customer networks with different subnets, many MLMs would be needed to distribute discovery. The communication rules would expand with the increased numbers.
105
Distributing large amounts of polling activities to the MLM agents is costly to the NetView netmon process. netmon is more efficient than it was four years ago. It now makes sense to leave the polling to NetView unless a slow or overused link is restricting ping traffic. The arguments show that, in most situations, the described MLM solution does not fit to the required network management solution in comprehensive SP environments.
4.3 Distributed management using NetView in unsecure networks

In this section, we describe a network management solution (for the service provider scenario described in Section 4.1, Test environment on page 102 and Section 4.2, Distributed management with MLMs on page 104) where the NetView management servers are placed in the customer s network, as shown in Figure 49.
Figure 49. NetView in SP subnetworks
106
The above network management system can implemented in either of the following ways: 1. NetView in a firewall encompassing the TMR zone to SP providers network. 2. NetView in its own separate TMR zone in the customers network.
Note
The following descriptions are especially relevant for the NetView for UNIX platform. NetView for UNIX needs to be integrated in a Tivoli framework environment, whereas NetView for NT does not (although integration is possible). If you do not want to integrate your NetView for NT in the TMR environment, then you can skip to Section 4.3.2, NetView in its own TMR regions on page 114. We need to discuss the different communication requirements between NetView and the TMR sever. Also, there are differences in communications from NetView with the implemented TEC event processing and database system for TDS integration, which we will analyze. What does this imply for the implementation and configuration of these systems? Where are the differences of these concepts? How does each solution affect the integration with TDS and TEC? What are the advantages and disadvantages for each solution?
4.3.1 NetView in service provider TMR

Figure 50 on page 108 shows the discussed service provider solution with separate network management servers for the management of the customer networks A and B.
107
Figure 50. Distributed management with NetView in one TMR
The NetView servers manage and control the subordinated networks. The servers are implemented as managed nodes to the service provider Tivoli Management Region. The TMR server is implemented in the SP network. The installation and configuration of the NetView servers is based on the managed node connection over the firewall to the TMR server in the SP network. Over the central TMR server in SP, you can manage and configure the remote network management servers in the customer networks. The following sections show the basic communication requirements and the required firewall rules. 4.3.1.1 Installation of managed nodes The basis for NetView for UNIX installation is the implementation of the NetView servers as managed nodes of an available TMR in the customers network.
108
Note
In this book, we only describe the basic Tivoli framework communication that is necessary for our network management topic. For more detailed discussion of system management issues and internal Tivoli communication requirements in firewall environments, please refer to the redbook Tivoli Enterprise Management Across Firewalls, SG24-5510. The detailed installation procedure of Tivoli framework components are explained in the TME 10 Framework 3.6 Planning and Installation Guide, SC31-8432.
The installation of the network management server is based on Tivoli Management Framework, as described in Section 2.4, NetView as part of a Tivoli system management platform on page 30. The installation will be started from the Tivoli graphical user console of the TMR server in the SP network. The data source (CD-ROM and the file server for NetView binaries) in our tests are located on the TMR server. The installation commands and data transfer is based on rexec (port 512/TCP) communications initiated from TMR server to NetView for UNIX server, as shown in the communication flow diagram in Figure 51 on page 110.
109
Figure 51. Installation managed node from TMR server
The server communicates with the rexec server port 512 by default from a random high (>1023) port. You can restrict this random source port to a defined port range by using the following command on the TMR server:
odadmin set_port_range range
You can test the configuration of the TMR server and its port ranges by using the commands shown in following screen:
110
>odadmin set_port_range 1200-1400 #set port range >odadmin odinfo #show port infos Region = 1929225022 Dispatcher = 1 Interpreter type = aix4-r1 Database directory = /Tivoli/spool/itso7.db Install directory = /Tivoli/bin Inter-dispatcher encryption level = simple Kerberos in use = FALSE Remote client login allowed = TRUE Install library path = /Tivoli/lib/aix4-r1:/usr/lib:/Tivoli/temp/iblib/aix4-r1:/usr/lib:/Tivoli/lib/aix4-r1: /usr/lib:/Tivoli/lib/aix4-r1:/usr/lib Force socket bind to a single address = FALSE Perform local hostname lookup for IOM connections = FALSE TME 10 Framework (mntbuild) #1 Fri Mar 8 11:17:43 CST 2000 Copyright Tivoli Systems, 1997. All Rights Reserved. Port range = 1200 - 1400 State flags in use = TRUE State checking in use = TRUE State checking every 180 seconds Dynamic IP addressing allowed = FALSE Transaction manager will retry messages 4 times.
For further discussion of port ranges, their administration (how many are required is dependent on the tasks and size of the TMR) for Tivoli framework, and more detailed communication documentation, see the redbook Tivoli Enterprise Management Across Firewalls, SG24-5510. In the following descriptions we assume that a port range from 1200 to 1400 is defined on TMR server. The TCP communication service at port 94 is known by Tivoli as the objcall (Tivoli Object Dispatcher Service). The rexec commands on port 512 will process several inspection scripts at the target system (1). Every time a connection is made to the remote system using rexec, another port will be opened for the stderr rexec (3) output. The basic installation packets will be transferred over this connection. After successful installation of the basic packets the oserv will be started on the target system, which is connected to the TMR server through the oserv listening port 94 (2). After successfully starting and registering the target system to the TMR dispatcher service, all other required packets will be distributed and installed at the managed node.
111
Table 14 shows the basic firewall configuration rules for the managed node configuration in the unsecure network.
Table 14. Firewall rule for installation of management node
Function rexec commands
Source TMR-Server in SP network NetView in Network A+B NetView in Network A+B
Destination NetView in Network A+B TMR-Server in SP network TMR-Server in SP network
Protocol exec/ TCP objcall/ TCP TCP
SrcPort rangea
DestPort 512
Connection to TMR server Stderr output from rexec commands
rangeb
94
>1023
rangec
a. Without port restriction, a random port would be used instead of range. b. See Footnote a. c. See Footnote a.
4.3.1.2 Installation of NetView for UNIX over TMR server After successful installation of managed node binaries, the server is registered as a managed node at the TMR server. Now NetView can be installed in the subordinate networks A and B. Figure 52 on page 113 shows the communication requirements for the installation of NetView binaries from TMR server to the network management server. The communication for the required patches in connection to NetView is the same. The detailed installation procedure is explained in the redbook Tivoli NetView 6.01 and Friends, SG24-6019.
112
Figure 52. Installation NetView from TMR server
Table 15 shows the basic firewall configuration rules for the managed node configuration in the unsecure network.
Table 15. Firewall rule for NetView installation on managed node
Function Installation and update packet transfer objcall connection to TMR server
Source TMR-Server in SP network NetView in Network A+B
Destination NetView in Network A+B NetView in Network A+B
Protocol TCP
SrcPort rangea
DestPort rangeb
objcall/ TCP
rangec
94
a. Without port restriction, a random port would be used instead of range. b. See Footnote a. c. See Footnote a.
The installation of actual NetView updates and further framework patches require the same rules!
113
4.3.1.3 Conclusions The above descriptions have shown that the communication requirements for installation and configuration from TMR to NetView servers through a firewall are very complex. You have to open wide port ranges for the communication of the customers NetView with the service providers management TMR server. Also, the opening of rexec for initial managed node binaries installation at the network management stations will not normally be allowed in firewall configurations. Of course, there are advantages for using this solution. You have the possibility for the central management of the NetView servers from the Tivoli management region with Tivolis comprehensive tools. Furthermore, database handling for TDS integration is fully generated through the TMR server. No new communication requirements are required when using the RIM object of the TMR server. However, from a security standpoint, you will need to consider the implications. The management of the servers can be implemented much more securely using secure shell to allow SSH tunnelled X-Windows access to the network management servers, as described in Section 4.6.2, Secure Shell (SSH) access to network management system on page 146.
4.3.2 NetView in its own TMR regions

This section discusses a solution where the NetView servers in the unsecure networks are installed in separate TMR regions outside of the service providers management region. Figure 53 on page 115 describes the solution. The NetView servers in the unsecure network are installed as separate TMR servers. Each NetView server manages and controls the network components of one customers network.
114
Figure 53. NetView in unsecure networks with separate TMR
The installation and configuration of the NetView server is independent from the service providers TMR server. You do not need to open any ports through the firewall for Tivoli management communication. The following points show a short summary for the installation procedure of NetView as a TMR server (see Tivoli NetView 6.01 and Friends, SG24-6019 for more details): 1. Install the Tivoli management framework. Install the TMR servers so that each NetView will exist in its own Tivoli Management Region. 2. Install all required framework patches for the NetView implementation. 3. Install NetView binaries for NetView server and database support. 4. Install actual NetView patches for NetView server and database support. The communication to the TEC server and TDS server is implemented through the provided NetView applications and independent to Tivoli management communication. See Section 4.4, TDS cooperation on
115
page 116 and Section 4.5, TEC connection on page 124 for a detailed discussion of this topic.
Note
In the eventuality that future management projects require Tivoli region communication, you have the possibility to interconnect the service providers TMR server with the TMR servers in the customer s NetView. This allows the transfer of regional data, for example, inventory data, from the NetView region to the service provider s Tivoli management region. See the redbook Tivoli Enterprise Management Across Firewalls , SG24-5510 for a detailed discussion of the communication requirements.
4.3.3 NetView installation recommendation

The installation of network management systems in unsecure networks without the Tivoli framework connection to the service providers network is the preferred way for network management through firewalls. With the Tivoli Desktop available over SSH, management of the server can be done in a secure remote place. Events and historical data can be securely sent to the Service Provider network.
4.4 TDS cooperation

The Tivoli Decision Support application provides comprehensive functions and tools for the analysis of performance and status network management data. The NetView network management server in the subordinate network collects all required performance and status data via SNMP requests to the appropriate MIB-entries of the controlled network devices. The collected SNMP data can be stored in relational database management systems, (RDBMS) such as DB2, Oracle, or Sybase, as shown in Figure 54 on page 117. NetView s trap daemon can also store all detected network traps, messages, and events in the database systems for analysis with the TDS system.
116
Figure 54. NetView database integration in TDS analysis
The TDS system queries the database system for the needed performance and event data. The database transfers the requested data to the TDS server for further processing and generating of comprehensive network performance and status analysis. Furthermore, the utilization and performance data and analysis are used for the documentation of service level agreements. As shown in Figure 53 on page 115, there is an efficient central database server in the service provider network for managing all the customers performance and service level management data. All NetView performance and event data of the different customers will be stored, for further processing, on this database server. Different database sessions will handled on this server.
Note
The database connection of NetView for UNIX is based on the Tivoli Framework functions. NetView uses a RIM object for communication with the database. The RIM object will be created on the TMR server. If the NetView management server is integrated in a Tivoli Management Region that spans across the firewall (an example is shown in Section 4.3.1, NetView in service provider TMR on page 107), you do not need to open database communication ports. The database communication will be handled from the TMR server, which is, in this case, also located in the same secure network as the database server. In this case, NetView will be installed on managed nodes. For a more in-depth introduction to database handling and configuration of RIM objects, see the Tivoli Management Framework Planning for Deployment Guide Version 3.7.1, found on the IBM Redbooks CD-ROM collection LK3T-5826.
117
In the firewall configuration we need to implement a rule (shown in Table 16) for permitting the data communication from NetView in the unsecure network to the database server in the secure network. This includes opening the required database TCP ports for necessary communication between the network management server NetView and database server.
Table 16. Firewall rule for NetView connection to database server
Function Database query and transfer
Source NetView in Network A+B
Destination Database server in SP network
Protocol TCP
SrcPort >1023
DestPort rangea
a. Port or port range depend on the database system used. See Section 4.4.1, Sample firewall configuration rule - Oracle database connection on page 118 for an example database configuration with Oracle.
The following section shows a sample implementation with an Oracle database server and shows (in detail) which configuration conditions through the firewall are to be implemented for the servers. The basic configuration and security concepts of the other possible database systems are similar and will not further described. See the appropriate database administration guides for the required information.
4.4.1 Sample firewall configuration rule - Oracle database connection

For our test environment, we used Oracle Database Version 8.1.5 installed on a server running AIX Version 4.3.3. The database server is located in the secure network. It is implemented as the database server for the TEC application as well as for the different NetView servers processing events, trap data, and SNMP collected data. Figure 55 on page 119 describes our test lab.
118
Figure 55. NetView database connection through firewall
We configured three different databases as shown in Table 17. We used the Oracle database assistant (dbassist) as the default method for the creation of the different databases.
Table 17. Oracle databases
Database TEC NETVIEW1 NETVIEW2
Description TEC Database (secure network) Database for NetView Server in secure network 10.69.14.0 Database for NetView Server in unsecure network 192.168.104.0
Database server itso7 itso7 itso7
The SQL network database interface of Oracle 8.x will be implemented through the Oracle Net8 application. Net8 performs complex network manipulations that depend on the server and client configuration. By default, Oracle provides the database network access with its TNS (Transparent Network Substrate) listener server, as part of the Net8 concept. The server is started by default and listens on port 1521 for network connections to database. The database client tries to establish a database connection by default to this port. The TNS listener service requires the firewall to be open
119
to allow the Oracle database access from unsecure network in secure network. Table 18 shows the required firewall communication rule.
Table 18. Firewall rule for NetView connection to Oracle database
Function Database query and transfer
Destination Database server in SP network
Protocol TCP
SrcPort >1023
DestPort 1521a
a. This is the default port configuration for TNS listener. You can set it to any port number that suits your requirements.
Figure 56 on page 121 shows our SecureWay firewall configuration rule for the database connection from NetView of unsecure network to the database server in the secure network.
120
Figure 56. Oracle database connection rule
You can test the connection with the database client program sqlplus from the required Oracle client installation. The following screen is an example.
$ sqlplus netview/netview@NETVIEW1 SQL*Plus: Release 8.1.5.0.0 - Production on Tue Feb 6 19:07:09 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production SQL>
121
The Oracle listener daemon will be administered in the configuration file $ORACLE_HOME/network/admin/listener.ora. You can chose a different port configuration, if required.
Note
To prevent communication port redirection between the Oracle server and the database client, configure the same listener port for all defined database instances. This makes the firewall rule configuration more specific, as shown in Table 18 on page 120. See the following screen for our default TNS listener configuration, which was generated through the database creation with the Oracle database assistant.
122
>more $ORACLE_HOME/network/admin/listener.ora # LISTENER.ORA Configuration File:/u01/app/oracle/product/8.1.5/network/admin/listener.ora # Generated by Oracle Net8 Assistant LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = loopback)(PORT = 1521)) ) ) (DESCRIPTION = (PROTOCOL_STACK = (PRESENTATION = GIOP) (SESSION = RAW) ) (ADDRESS = (PROTOCOL = TCP)(HOST = loopback)(PORT = 2481)) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /u01/app/oracle/product/8.1.5) (PROGRAM = extproc) ) (SID_DESC = (GLOBAL_DBNAME = TEC) (ORACLE_HOME = /u01/app/oracle/product/8.1.5) (SID_NAME = TEC) ) (SID_DESC = (GLOBAL_DBNAME = NETVIEW2) (ORACLE_HOME = /u01/app/oracle/product/8.1.5) (SID_NAME = NETVIEW2) ) (SID_DESC = (GLOBAL_DBNAME = NETVIEW1) (ORACLE_HOME = /u01/app/oracle/product/8.1.5) (SID_NAME = NETVIEW1) )
In the listener field, you can configure different listener ports for connecting clients to the Oracle database server. After configuration of the TNS listener file, you have to restart the listener daemon with following command:
lsnrctl reload
123
After administrating the listener files, you need to configure the Oracle names service $ORACLE_HOME/network/admin/tnsnames.ora to adapt for the new connection ports. Then you have to reconfigure all database client configuration files that will connect to the appropriate database instance. The configuration is implemented in the $ORACLE_HOME/network/admin/tnsnames.ora file of the database clients. The following screen shows the file.
>more $ORACLE_HOME/network/admin/tnsnames.ora # TNSNAMES.ORA Configuration File:/usr/oracle/OraHome1/network/admin/tnsnames.ora # Generated by Oracle Net8 Assistant NETVIEW1 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = itso7)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = NETVIEW1) ) )
Edit the listener port field for the new database connection port and test the database connection with the Oracle SQL*Plus program. The book Building Internet Firewalls by Elizabeth Zwicky et al describes different security implications of Oracle database implementation. Additional database communication security can be implemented with SSH tunneling (see Section 4.6.2, Secure Shell (SSH) access to network management system on page 146) and VPN connections (see Chapter 5, Network management through the VPN on page 163). See http://technet.oracle.com for further discussions on Oracle database connections in firewall environments. There are discussions on other security aspects for Oracle database configurations and Oracle databases in security environments.
4.5 TEC connection

The NetView integration into the central event management and processing function of a service providers Tivoli Enterprise Console can be implemented in different ways: Forwarding events to TEC with NetView nvserverd daemon Forwarding events to TEC with SNMP trap forwarding function
124
Forwarding events to TEC with tecad_nv6k application In the following sections, we want to discuss the different solutions with their pros and cons in the context of our firewalled environment.
4.5.1 Forwarding events to TEC with NetView nvserverd daemon

This is the recommended solution for NetView for UNIX. In Section 4.5.1.1, TEC reception port restriction on page 130, the configuration to limit the configuration to a single port is described. NetView for UNIX provides a very easy application for integrating event forwarding to a central TEC server. This function is integrated in the NetView nvserverd daemon. It allows rule base correlating of specific events for forwarding. Figure 57 explains how NetView forwards events with nvserverd. Every event that is not blocked in the ruleset will be forwarded to TEC.
Figure 57. Forward events with nvserverd
Note
NetView NT does not have the nvserverd daemon. It provides another default application tecad_nv6k for event forwarding to TEC. In NetView for UNIX, it is also possible to use the tecad_nv6k application but, by default, the nvserverd method is recommended. See Section 4.5.3, Forwarding events to TEC with tecad_nv6k application on page 139 for more details. The communication of NetView with TEC based on the nvserverd event forwarding method is independent from the general Tivoli Framework communication, as described in Section 4.3.1, NetView in service provider TMR on page 107. The event forwarding process is independent from the integration in a Tivoli Management Region. It is the same for NetView servers that are not integrated in the same TMR as the TEC server belongs to. It does not use the general objcall communication for event sending from NetView to
125
TEC server. NetView can be implemented in a non associated independent TMR zone outside of the TEC server s Tivoli Management Region. The standard TEC communication for event transfer of NetView with the TEC server is based, by default, on the Remote Procedure Call Protocol (RPC). RPC is a standard TCP protocol that was developed by Sun for remote access of network servers. The protocol allows the server to provide a defined count of services that can accessed from the clients over the network. The RPC protocol is defined in the RFCs 1057 and 1831. There are different other network protocols, such as NFS (Network File Systems) or NIS (Network Information Service), which are based on the RPC Protocol. The exported functions are implemented as procedures of a server program and are accessed by server address, program number, and procedure number. The default TEC event forwarding from NetView with nvserverd can be configured in the NetView server setup application, which is accessible from the NetView graphical user interface in the administration menu Administer->Server Setup. Selecting this option opens up the dialog box seen in Figure 58.
Figure 58. Event forwarding administration from NetView to TEC
Selecting Configure event forwarding to T/EC opens up the dialog box shown in Figure 59 on page 127. You set the hostname or IP address of the TEC server and the NetView rule that will correlate the events. The events which pass the rule will be forwarded to the configured TEC server.
126
Figure 59. TEC server configuration in NetView for UNIX
Figure 60 on page 128 shows the basic RPC communication for event processing between NetView and the TEC server.
Note
On UNIX systems in particular, the remote procedure call protocol (normally known as RPC) was developed by Sun and later standardized as Open Network Computing (ONC) RPC. On Microsoft systems, the protocol normally known as RPC is compatible with a descendent of Suns RPC that was standardized by the Open Systems Foundation (OSF). Sun RPC and Microsoft RPC are quite similar and related, but they do not interoperate. Also, the Microsoft RPC uses different ports for its communication. When we use RPC in our document, we refer to the Sun RPC.
127
Figure 60. Communications between NetView and TEC
The portmapper daemon is the global RPC daemon on the RPC server (TEC). It manages the RPC requests of the network clients.The TEC application registers its exported functions with the portmapper daemon (RPC-port is 100033057). The TEC server uses a port number out of the defined Tivoli odadmin port range and registers to the portmapper daemon. The portmapper daemon listens on UDP port 111 for RPC requests of network clients. When NetView wants to forward an event to TEC, it requests, on UDP port 111, the port number of the appropriate TEC RPC event function (1). The portmapper sends back, per UDP, the requested port number (out of the odadmin range) of the TEC event function(2). NetView connects to this port and sends the event information to the TEC server(3).
128
Table 19 shows the appropriate firewall configuration rules for the NetView nvserverd event forwarding function from the unsecure network to the TEC server in the secure network.
Table 19. Firewall rule for RPC communication
Function RPC request from RPC client to portmapper daemon RPC reply from RPC server to clients RPC communication for event data
Source NetView in Network A+B TEC-Server in SP network NetView in Network A+B
Destination TEC-Server in SP network NetView in Network A+B TEC-Server in SP network
Protocol sunrpc/ UDP sunrpc/ UDP TCP
SrcPort >1023
DestPort 111
111
>1023
>1023
rangea
a. Without port restriction, a random port would be used instead of range.
The RPC portmapper UDP port is fixed for rule configuration. If the Tivoli port range in the Tivoli Management region is not restricted, as described in Section 4.3.1, NetView in service provider TMR on page 107, than the TEC communication port is random. In this case, you cannot say which remote procedure call port will be used for the event forwarding process. For standard packet filter firewalls, you have to open a wide port range in the firewall rule to allow this communication process. State of the art firewalls, such as Check Point FireWall-1 4.1, which we have tested in our lab, allow the definition of dynamic firewall rules, which listen on the RPC communication to port 111 and detect the provided port number from the portmapper. With the provided port number, the firewall dynamically permits the RPC request to the requested RPC function. This allows the secure communication from the defined client and servers through the firewall without opening a wide port range, as shown in Table 19. See the configuration dialog in Figure 61 on page 130 for RPC protocols of the Check Point FireWall-1 4.1 SP2. You can administer your specific RPC communication protocol and add this function as an allowed service from NetView servers in unsecure networks to the TEC server in secure networks.
129
Figure 61. Dynamic rule configuration for RPC communication
Security experts see the opening of RPC protocols and the RPC communication in general problematic. For example, the book Building Internet Firewalls by Elizabeth Zwicky et al recommends that you Do not allow RPC-based protocols through firewall when possible. The RPC-protocol has, in general, some security and authentication problems. The configuration of dynamic firewall rules for RPC communication does not solve all of these aspects. 4.5.1.1 TEC reception port restriction This is the recommended configuration for NetView to TEC event forwarding for NetView for UNIX. The TEC server allows you to restrict the event reception to one specific port without using RPC communication. You can customize the TEC event reception port in the configuration file $BINDIR/TME/TEC/.tec_config. The following screen shows an example configuration with a specified TEC reception port to 5529.
130
#more $BINDIR/TME/TEC/.tec_config # on NT, there is no portmapper, so reception runs at a fixed # port. Use port numbers > 5000 so that we do not conflict with # ports automatically assigned (1024-5000) by `bind'. # tec_recv_agent_port=5529 # tec_disp_rule_port=5530 # tec_recv_rule_port=5531
After restarting the TEC server (for example, by using the commands
wstopesvr and wstartesvr), it listens on the specified port (in this example, it is
5529) for event receptions. All installed TEC adapters have to be modified for using the specified TEC server listening port in the TEC adapter configuration files by the parameter ServerPort. On a NetView UNIX server, you can configure the specific TEC server listening port in the configuration file /usr/OV/conf/tecint.conf. Add an entry for ServerPort, as shown in following screen.
#more /usr/OV/conf/tecint.conf ServerLocation=itso7 TecRuleName=tec.rs ServerPort=5529
On a NetView NT server, you can configure the specific TEC server listening port in the TEC Adapter for NT configuration file, tecad_nv6k. After restarting the NetView server (for example, by using the commands ovstop and ovstart) it sends the events without using RPC communication to the specified TEC reception port (5529) by TCP connection. See Figure 62 on page 132.
Note
The NetView configuration file for TEC forwarding, /usr/OV/conf/tecint.conf, will be generated through the NetView server administration program, as shown in Figure 59 on page 127. It only allows the definition of receiving TEC servers and the used NetView correlation rule. After every reconfiguration or stopping and starting, the TEC configuration file /usr/OV/conf/tecint.conf will be overwritten and you have to add the ServerPort parameter manually.
131
Figure 62. Sending events from NetView to a restricted TEC port
Table 20 shows the required firewall rule for the communication of the NM-servers to the TEC server with the restricted reception port.
Table 20. Firewall rule with restricted TEC reception port
Function Send event data
Destination TEC-Server in SP network
Protocol TCP
SrcPort >1023
DestPort 5529a
a. Free configurable in TEC and NetView server
The following sections show other opportunities for integrating TEC into network management event processing.
4.5.2 Forwarding events to TEC with SNMP trap forwarding function

When your TEC configuration does not allow you to restrict the port range for event reception or your firewall configuration does not allow the configuration of a secure dynamic RPC firewall rule (which was previously described), you
132
have the following possibilities for NetView and TEC communication without the RPC protocol passing through the firewall: Forward all detected events by SNMP traps to the TEC server. Forward specific detected events by SNMP traps to the TEC server. Forward only NetView rule passed events to the TEC server. The advantage for these solutions is that you do not need to open RPC connections over the firewall. You only have to open a SNMP trap rule in the firewall configuration. The assumption is that you have installed an SNMP adapter on the TEC server or another Tivoli managed node in the Tivoli managed region. The following sections show the basic concept in context of these TEC communication issues. 4.5.2.1 Forward all events by SNMP traps to TEC server NetView provides the ability to automatically forward all detected events to any network host. The events will forwarded as SNMP traps to the desired host. The receiving host has to be able to receive and process these SNMP traps. Figure 63 shows the NetView server that is forwarding all detected events as SNMP traps to the central TEC server.
Figure 63. Forward all events to TEC
The SNMP event forwarding from NetView to other network hosts will be configured in the NetView server setup application. It can be started from the administration menu ( Administer->Server Setup) of the NetView graphical user interface (see Figure 58 on page 126). Figure 64 on page 134 shows the selected function for setting the event receiver in the server setup application.
133
Figure 64. Configuration of trap forwarding
After selecting the Set options for trapd daemon function, the NetView trapd configuration dialog will be started as shown in Figure 66 on page 136. In the field Forward ALL traps to (host):, you have to enter the hostname or the IP address of the TEC server that the TEC SNMP adapter is installed.
Note
The TEC SNMP-adapter does not need to be installed on the TEC server. It can be installed on another managed node in the same TMR as the TEC server is installed. The TEC SNMP-adapter processes the forwarded events internally for TEC operation. After the event forwarding function has been activated, the NetView server sends all detected events to the TEC server.
134
Figure 65. NetView trapd configuration dialog box
Table 21 shows the required firewall rule configuration for SNMP trap forwarding from NetView server in customer networks to the TEC server in the SP network.
Table 21. Firewall rule for NetView connection to Oracle database
Function Send SNMP trap
Destination TEC SNMP adapter in SP network
Protocol UDP
SrcPort >1023
DestPort 162
4.5.2.2 Forward specific events by SNMP traps to TEC server Large networks will generate many different kinds of events. Mostly there are only specific events groups that we are interested in for further event management using TEC. Furthermore, you have to pay attention so that the TEC server will not be flooded from many unimportant network events. In the
135
NetView server configuration, you have the opportunity to chose specific events for forwarding to the TEC server. Figure 66 shows that concept.
Figure 66. Forward specific events to TEC
In the NetView trapd configuration dialog box shown in Figure 65 on page 135, you can configure a host for forwarding only specific events, such as Node Down or Node Up. Enter the IP address of your TEC server in the field Forward specific traps to (host):. After applying these entries, only the specific events will be forwarded as SNMP traps to the TEC server. The configuration of the events that are defined as specific events are set in the SNMP trap configuration dialog. The dialog will be started in the menu Options->Event Configuration->Trap Customization: SNMP... . Figure 67 on page 137 shows the started event configuration dialog box. You have to modify your desired event and select the Forward Trap option. This procedure can be repeated for every kind of event you want to forward an SNMP trap to another host.
136
Figure 67. Definition of specific events
See Table 21 on page 135 for the required firewall configuration rule. 4.5.2.3 Forward only NetView rule passed events to TEC server Using nvserverd with a ruleset is the preferred method. However, if your firewall administrator will not open a TCP port for you but does allow SNMP traps, then this method will work. A further method for forwarding only important events per SNMP trap to the TEC server is described in Figure 68 on page 138. This method is based on the rule processing function of NetView. The previously described methods
137
for SNMP trap forwarding do not have the ability to determine specific events of important network devices and services for TEC; they only note the kind of event, such as Node Down or Node Up.
Figure 68. Forward only rule passed events to TEC
The rule processing function gives you the opportunity to filter your events by the criteria you defined on network devices and so on. You have to construct the specific rule for passing only these events you are interested in for TEC processing in the rule editor of NetView. NetView correlates the detected events with the constructed TEC ruleset with its correlation daemon nvcorrd. This rule will start an SNMP trap script, which sends all passed events via SNMP-Traps to the TEC server. The following script is an example of customized trap processing. It would need to be in an Action box in your ruleset.
138
#!/bin/sh # Filename: sendEventToTEC.sh # Function: Forward traps from NetView to TEC server per SNMP trap # Start: Start from TEC ruleset # # Environment variables for trap data # $NVE specifies the enterprise ID # $NVA specifies the agent address # $NVG specifies the generic trap number # $NVS specifies the specific trap number # $NVT specifies the time stamp # $NVC specifies the community name # NVATTR_<1-50> specifies the MIB attribute where 1-50 is the variable binding number # NVATTR_2 hostname or IP address # NVATTR_3 trap description # NVATTR_4 object number # NVATTR_5 netview database #Hostname or IP-Address of trap receiver TRAPRECEIVER=132.17.254.10 #Lofile LOGFILE="/tmp/sendEventToTEC.log" #Send trap to TRAPRECEIVER per snmptarp echo "Send trap to $TRAPRECEIVER $NVE $NVA $NVG $NVS $NVT $NVC">>$LOGFILE /usr/OV/bin/snmptrap $TRAPRECEIVER ".$NVE" $NVA $NVG "${NVS}0" 0 system.sysDescr integer 2 system.sysDescr octetstring "$NVA" system.sysDescr octetstring "$NVATTR_3 $NVATTR_4 $NVATTR_5">>$LOGFILE
See Table 21 on page 135 for the required firewall configuration rule.
4.5.3 Forwarding events to TEC with tecad_nv6k application

The tecad_nv6k application is another application for integrating NetView detected events and traps in the TEC event management process. In NetView NT, the tecad_nv6k application is used, by default, for forwarding events to the Tivoli Enterprise Console.
Note
In NetView NT, the tecad_nv6k application is installed by default. In NetView for UNIX, you have to install the application. It is located on the installation CD-ROMs of the TEC server. The installation procedure is described in the Tivoli administration guide Tivoli TEC 3.7 Adapter s Guide, GC32-0668. After registering the tecad_nv6k application in the NetView startup process, it will started automatically with the NetView daemons startup. You can control its status with the following command:
139
ovstart tecad_nv6k
The configuration of tecad_nv6k is done in the configuration file /usr/OV/conf/tecad_nv6k.conf. See the Tivoli TEC 3.7 Adapter s Guide, GC32-0668 for further instructions. There are different communication requirements for NetView for UNIX and NetView for NT within the TEC server. The following sections show the basic differences. 4.5.3.1 NetView for UNIX The event forwarding process of NetView for UNIX to TEC with the application tecad_nv6k is based on the Tivoli Framework communication, which is already described in Section 4.3.1, NetView in service provider TMR on page 107. It uses the Tivoli framework object call processes. The network management server has to be in the same Tivoli Management Region as the TEC server. You can see the communication process in Figure 51 on page 110. The required firewall configuration rule is documented in Table 14 on page 112. 4.5.3.2 NetView for NT NetView for NT provides different configuration options for the communication of the tecad_nv6k program with the TEC server: NetView NT is integrated into the same TMR as the TEC server. The communication is based on the Tivoli framework object calls and uses the same communication rules shown in Table 14 on page 112. NetView NT is outside of the TEC server s TMR. It forwards events to a UNIX-based TEC server. The communication of NetView NT and TEC on UNIX is based on the RPC protocol. The RPC port number is 100033057. The communication requirements are the same as described in Figure 60 on page 128 and Table 19 on page 129. This is the recommended configuration for NetView NT. NetView NT is outside of the TEC server s TMR. It forwards events to an NT-based TEC server. The TEC NT server listens by default on port 5529 for event forwarding connections. The TEC reception port is configurable, as described in Section 4.5.1.1, TEC reception port restriction on page 130. NetView for NT connects to the specific TEC reception port and sends the event information to the server. Figure 69 on page 141 shows the communication between NetView NT and TEC on NT.
140
Figure 69. Communication NetView NT and TEC Server on NT
Table 22 documents the required firewall rule for NetView NT in the unsecure Network and the TEC server in the secure network.
Table 22. Firewall rule for NetView NT communication with TEC NT
Function Event data
Source NetView NT in Network A+B
Destination TEC-Server NT in SP network
Protocol TCP
SrcPort >1023
DestPort 5529a
a. Freely configurable in the TEC and NetView server
4.6 Remote access to network management system

An important aspect for our analysis is to discuss how one should implement remote access to network management over firewalls safely. Figure 70 on page 142 shows the remote access communications to network management servers through the firewall.
141
Figure 70. Remote access to network management servers
You have to implement a secure access function for network management tasks from the service provider network behind the firewall to the customer s network management servers. In this section, we discuss what opportunities there are for fulfilling these demands using remote access through the NetView Java Web client and secure X-Windows access.
4.6.1 Remote access with the Java Web client

The network management system NetView has a comprehensive Java Web client for the remote access to the core network management functions for topology, event, and configuration management: Graphical access to network management topology maps Real-time status activation of network devices Access to NetView MIB browser functions Event browser for remote event management tasks
142
We believe that the Java Web access functions and opportunities will be more secure and more extensive in future NetView releases. The NetView Web function is based on the Web server Jetty. Jetty is an Open Source HTTP Servlet Server written in 100 percent Java. See
http://jetty.mortbay.com/
for more information. The NetView Web client is written in 100 percent Java. Therefore, the client is independent from the operating system and is runable on every operating system that supports the Java Runtime Environment Version 1.1.4. The communication of the Java Web client to the NetView Web server is very complex. There are a number of different communication steps. Figure 71 on page 144 shows the basic communications between a Java Web client and a NetView server.
143
Figure 71. Communication between Java Web client and NetView server
The Web console uses a HTTP GET/POST communication for registration and authorization to the Web server (1). The Web server is listening on the default TCP port 8080. The access port is configurable in the Web server configuration file /usr/OV/www/conf/JettyServer.prp. See following screen for more details.
144
more /usr/OV/www/conf/JettyServer.prp # ======================================================================== # Configuration file for com.mortbay.Jetty.Server # # ======================================================================== # Define the server instances to be configured by this file: # SERVERS - list if defined server names # PROPERTY.* - Definition of global properties # PROPERTIES - File of globl properties # servername.* - PropertyTree describing server "servername". # # Defined global properties are: # DefaultPageType - The class name of the default com.mortbay.HTML.Page # type. # -----------------------------------------------------------------------SERVERS : main #PROPERTY.DefaultPageType : com.mortbay.Jetty.JettyLaF # ======================================================================== # Define the server instance named "main" # CLASS - The class name of the server. Must either be # com.mortbay.HTTP.HttpServer or a decendant. # LISTENER.name.CLASS - HttpListener classname or decendant # LISTENER.name.ADDRS - List of addresses and ports to listen on # STACKS - List of handler stack names. # EXCEPTIONS - List of exception handler stack names. # PROPERTY.* - Properties for this server # PROPERTIES - File of properties for this server. # # Defined server properties are: # SessionMaxInactiveInterval - Max idle time Ms before session death # MinListenerThreads - Min listener threads per listener # MaxListenerThreads - Max listener threads per listener # MaxListenerThreadIdleMs - Max idle time Ms before listen thread death # MimeMap - Property file of MIME mappings # # -----------------------------------------------------------------------main.CLASS : com.mortbay.HTTP.HttpServer main.STACKS : root main.EXCEPTIONS : defaultEx main.PROPERTY.SessionMaxInactiveInterval : 3600 #main.PROPERTY.MinListenerThreads : 1 #main.PROPERTY.MaxListenerThreads : 20 #main.PROPERTY.MaxListenerThreadIdleMs : 60000 main.PROPERTY.MinListenerThreads : 10 main.PROPERTY.MaxListenerThreads : 0 main.PROPERTY.MaxListenerThreadIdleMs : 0 main.PROPERTY.MimeMap : ./conf/Mime.prp main.LISTENER.all.CLASS : com.mortbay.HTTP.HttpListener main.LISTENER.all.ADDRS : 0.0.0.0:8080 ..... main.root.Servlet.PROPERTY.SERVLET.Util.PROPERTY.mibserverport : 8892 .....
For map opening and topology data exchange, the Web server uses two TCP connections to the Web client. The communication ports are random and are shown in the communication process.
145
Furthermore, the NetView MIB server listens on TCP port 8892 for MIB browsing connections of the Java Web clients. The Web clients connect via RMI (Java Remote Method Invocation) calls to the MIB server for MIB data access (4). The MIB server socket 8892 is also configurable in the Jetty server configuration file /usr/OV/www/conf/JettyServer.prp. Table 23 shows the appropriate firewall rules for Web client connections to the NetView server over firewalls.
Table 23. Communication rules for Web client to NetView server
Function HTTP access to NetView Web server Map opening and status exchange MIB server access
Source Java Web client in SP network Java Web client in SP network Java Web client in SP network
Destination NetView in Network A+B NetView in Network A+B NetView in Network A+B
Protocol HTTP/ TCP TCP
SrcPort >1023
DestPort 8080
>1023
>1023
RMI/ TCP
>1023
>8892
You see that this is a very complex communication process with a wide port range that will be used from the Web client and the network management system NetView. Because of the random port usage and wide-open firewall port ranges, we cannot recommend allowing remote Java Web access to the network management server over firewalls. It is very unsecure to open this large number of ports in a firewall connection. We believe the communication of NetView Web Client with the Web server will be simplified in future releases, so that the Web server uses a single Web port number for the client map access. Today, a possible solution could be to put a VPN client outside of the firewall, which will open a secure channel to a VPN server that can be located at the firewall or behind the customers network. Over this tunnel, the Web connection can be securely handled without opening a wide range in the firewall configuration. Chapter 5, Network management through the VPN on page 163 discusses different solutions for this problem.
4.6.2 Secure Shell (SSH) access to network management system

The network management administrators in the service providers network require the ability to get access into the network management servers in the
146
customer s network for system administration tasks, and remote access to the graphical user interface of the network management server. A very popular remote access method is X-Windows (X11) access connected with a telnet session to an UNIX-based network management system. The X-Windows protocol is a possible solution for gaining remote access to an UNIX-based network management system. But the problem is that X-Windows access is normally unsecure, as shown in Figure 72.
Figure 72. Telnet connection with subsequent export of X11 GUI
The X-Windows system poses a number of problems for a firewall system: The client/server relationship is in the reverse direction from most other protocols. The X11 server is the display/mouse/keyboard unit and the client is the application program (in our example, the network management program) driving panels or interacting with the mouse and keyboard on that server (Figure 72). The X-Windows connection is unencrypted. There are different tools that can listen on the X-Windows connection and detect the session with its data. The X-Windows session normally will be started through a telnet or rlogin connection. These protocols are unsecure because the passwords for starting the connections are sent in unencrypted form. The different X11 authentication mechanisms with xhost and magic cookie security mechanisms do not allow secure authentication of client and server. See the book Building Internet Firewalls by Elizabeth Zwicky et al for a more intensive discussion of X-Windows security aspects.
147
The firewall administrators normally do not allow X-Windows and additional needed communications in their firewall configuration. The remote X-Windows, telnet, or ftp access to the network management server communicate in a secure way over a secure shell (SSH) connection from authorized management clients to the management server. In this chapter, we describe a secure remote access tunnel using an SSH connection from outside of the secure network to the network management system. SSH is a protocol that can be used to provide a secure channel between two hosts. It uses encryption and authentication while ensuring data integrity. Encryption, authentication, and data integrity are all required to ensure security and will be discussed first. After this, we will show a simple configuration example for the secure remote X-Windows connection from a network management client to the management server. 4.6.2.1 Introduction to SSH communication SSH is designed to provide strong authentication and secure communications over what are normally insecure channels. SSH can be used as a secure replacement for the BSD r commands ( rlogin, rsh, rcp) and telnet communication because it provides all of their functionality. SSH provides secure proxy mechanism for realizing secure X-Windows connections to X11 servers (Figure 73). It can also perform port forwarding, routing traffic received on one port on one machine to another port on another machine. The encrypted port forwarding mechanism can be used as a very limited VPN capability.
Figure 73. X11 Forwarding through encrypted tunnel
The SSH connection has two main components: the client and the server. SSH servers are provided for UNIX and Windows NT. The SSH client is installed on all workstations needing to make secure connections to a UNIX server within the network. The SSH client runs on several operating systems, including Windows/NT and most UNIX-based operating systems. Currently, two different versions of the SSH protocol exist. SSH Version 1 (SSH1) and SSH Version 2 (SSH2). SSH1 is the original version. SSH2 is an
148
extended version with better security, performance and portability than SSH1 and a number of new features and functions. There are also different SSH implementations: the original SSH implementation from SSH Communications Security and an open source implementation, OpenSSH, developed by the OpenBSD project. The original SSH is distributed and supported commercially from SSH Communications Security and is accessible at:
http://www.ssh.com/
The open SSH implementation is free and you can download the source files from:
http://www.openssh.org/
The AIX installp version of OpenSSH is downloadable from:

http://freeware.bull.net
SSH and OpenSSH implementation support both SSH versions. The implementations are compatible and interoperable. The security of SSH is based on authentication, encryption, and data integrity algorithms and functions. The following points show the basic concepts of the secure data exchange over SSH: The client and the server negotiate encryption algorithms (DES) for secure data exchange. The identity of the server to which the a client is connecting is always verified. The identity is checked before any client authentication information is sent. Public key cryptography is used to prove the identity of a server. The key exchange algorithms that are used prevent man-in-the-middle attacks. The server checks the client identity in a different client authentication mechanism. For example, rhosts, RSA, Kerberos, passwords, and other authentications. At the end of the key exchange, a checksum exchange will detect any data fakeness with algorithm negotiation. All data packets exchanged include message integrity checks. An integrity check failure causes a connection to be closed. An SSH server uses temporary authentication parameters that are discarded after a configurable time period to prevent recorded sessions from being decrypted at a later time.
149
Table 24 shows the firewall configuration for allowing SSH access to firewalls from the service providers network to the customers network. SSH servers are listening on TCP port 22. SSH clients need to use a port below 1024 when using rhost-based authentication methods, but need to use a port above 1023 when they are not.
Table 24. Communication rule for SSH connections
Function SSH connection client to server SSH connection server to client
Source SSH client in SP network SSH server NetView in Network A+B
Destination SSH server NetView in Network A+B SSH client in SP network
Protocol SSH/ TCP TCP
SrcPort >1023a
DestPort 22
22
>1023b
a. SSH clients use a port below 1024 when using rhost-based authentication methods and a port above otherwise. b. See Footnote a.
See the redbook Additional AIX Security Tools on IBM ~ pSeries, IBM RS/6000 and SP Cluster, SG24-5971 for further information on the topic of SSH communication. 4.6.2.2 A sample SSH configuration In the following sections, we describe an installation and configuration example of an SSH connection for a client in the service providers network, to the SSH server, which will be installed on network management server in the customers network. Figure 74 on page 151 shows an example.
150
Figure 74. SSH test environment
For our test configuration, we are using the freeware implementation of SSH protocol known as OpenSSH. Besides the OpenSSH binaries, the program requires the following packets: freeware.perl.rte freeware.egd.rte freeware.openssl.rte freeware.perl.md5.rte freeware.zip.exe freeware.zlib.exe The required packets and the OpenSSH installation packet can be downloaded from the AIX freeware/shareware server:
http://freeware.bull.net
Transfer the downloaded files to your network management server. Inflate the downloaded packets to obtain the installp-format *.bff of these packets. The following screen shows the inflation process.
151
# ls -ali total 18528 8211 drwxr-xr-x 2 root system 512 Feb 20 10:29 . 2 drwxr-xr-x 23 bin bin 1024 Feb 20 10:28 .. 8218 -rw-r--r-- 1 root system 86296 Feb 20 10:29 egd-0.8.0.0.exe 8219 -rw-r--r-- 1 root system 671914 Feb 20 10:29 openssh-2.3.0.101.exe 8220 -rw-r--r-- 1 root system 1620889 Feb 20 10:29 openssl-0.9.6.0.exe 8221 -rw-r--r-- 1 root system 6561822 Feb 20 10:29 perl-5.6.0.1.exe 8222 -rw-r--r-- 1 root system 138972 Feb 20 10:29 perl.md5-2.12.0.0.exe 8223 -rw-r--r-- 1 root system 241718 Feb 20 10:29 zip-2.3.0.0.exe 8224 -rw-r--r-- 1 root system 137279 Feb 20 10:29 zlib-1.1.3.2.exe # chmod 700 *.exe # egd-0.8.0.0.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: egd-0.8.0.0.bff inflating: egd-0.8.0.0.bff.asc # openssh-2.3.0.101.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: openssh-2.3.0.101.bff inflating: openssh-2.3.0.101.bff.asc #openssl-0.9.6.0.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: openssl-0.9.6.0.bff inflating: openssl-0.9.6.0.bff.asc # perl-5.6.0.1.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: perl-5.6.0.1.bff inflating: perl-5.6.0.1.bff.asc # perl.md5-2.12.0.0.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: perl.md5-2.12.0.0.bff inflating: perl.md5-2.12.0.0.bff.asc # zip-2.3.0.0.exe UnZipSFX 5.41 of 16 April 2000, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: zip-2.3.0.0.bff inflating: zip-2.3.0.0.bff.asc # zlib-1.1.3.2.exe UnZipSFX 5.32 of 3 November 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu). inflating: zlib-1.1.3.2.bff inflating: zlib-1.1.3.2.bff.asc
After inflating the packages, you can install them with the AIX software installation command installp for the freeware.openssh.rte packet. Because of the -g flag, installp also installs the required filesets automatically (see the installp man page for further information on the installation process). The following screen shows the installp command with the message for the successful installation of the software package.
152
# installp -acgX -d . freeware.openssh.rte .... .... Starting OpenSSH daemon on port 22 Finished processing all filesets. (Total time: 1 mins 4 secs). +-----------------------------------------------------------------------------+ Summaries: +-----------------------------------------------------------------------------+ Installation Summary -------------------Name Level Part Event Result ------------------------------------------------------------------------------freeware.zlib.rte 1.1.3.2 USR APPLY SUCCESS freeware.perl.md5.rte 2.12.0.0 USR APPLY SUCCESS freeware.openssl.rte 0.9.6.0 USR APPLY SUCCESS freeware.openssl.rte 0.9.6.0 ROOT APPLY SUCCESS freeware.egd.rte 0.8.0.0 USR APPLY SUCCESS freeware.egd.rte 0.8.0.0 ROOT APPLY SUCCESS freeware.openssh.rte 2.3.0.101 USR APPLY SUCCESS freeware.openssh.rte 2.3.0.101 ROOT APPLY SUCCESS
Verify that all modules are successfully installed. The OpenSSH daemon will be automatically started after installation.
# ps -ef|grep opensshd root 24832 23074 0 11:21:09 pts/4 0:00 grep opensshd root 26200 1 0 11:00:25 - 0:01 /usr/local/bin/opensshd -f /etc/openssh/sshd_config -h /etc/openssh/ssh_host_key
The configuration of the OpenSSH daemon is contained in the file /usr/local/bin/opensshd. By default, the OpenSSH daemon sets the SSH protocol to SSH Version 1. You can set the protocol to SSH Version 2 in the configuration file by uncommenting the protocol line. We will use SSH Version 1. The described configuration points are similar to SSH version 2. See the following screen.
153
more /etc/openssh/sshd_config # This is ssh server systemwide configuration file. Port 22 #Protocol 2,1 ListenAddress 0.0.0.0 #ListenAddress :: HostKey /etc/openssh/ssh_host_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes # # Don't read ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes StrictModes yes X11Forwarding yes X11DisplayOffset 10 PrintMotd yes KeepAlive yes # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging RhostsAuthentication no # # For this to work you will also need host keys in /etc/openssh/ssh_known_hosts RhostsRSAAuthentication yes # RSAAuthentication yes ....
To enable port forwarding of X11 sessions over this secure SSH tunnel, comment the line X11Forwarding (in the previous screen) with the yes value. By default, the SSH server daemon listens on port 22. This port is configurable to another port number for security reasons. After the reconfiguration of SSH server port has been done, you have to reconfigure the SSH client port. This is done in the SSH client configuration file. See SSH server access with AIX SSH client on page 156 for the configuration of the SSH clients. To automatically start the SSH daemon, this SSH installation adds /etc/rc.openssh to /etc/inittab and makes an entry in the /etc/rc.tcpip configuration file.
154
To manually start the OpenSSH daemon using /etc/openssh/shhd_config as the config file and /etc/openssh/ssh_host_key as the RSA host key file, use the following command:
#/usr/local/bin/opensshd -f /etc/openssh/sshd_config -h /etc/openssh/ssh_host_key
To manually stop the SSH daemon, use the following command:

#kill `cat /var/openssh/sshd.pid
To restart the daemon, use the following command:

#kill -1 `cat /var/openssh/sshd.pid
The SSH authentication is set by default in the configuration file /etc/openssh/sshd_config to RSA authentication (RSAAuthentification yes). This is the recommended authentication method, which we will describe in our redbook.
Note
The other authentication methods, such as rhosts, rhosts combined with RSA, and password authentication, are also possible, but will not be further discussed in this redbook. See the OpenSSH man pages for more information. The RSA authentication is based on public/private key pair exchange between the SSH server and the client. To generate a public/private key for user authentication, use the OpenSSH program command:
#ssh-keygen
By default, this program generates an SSH RSA key pair with a key length of 1024 bit for every key. With the command flag -b 2048, you can generate keys with a length of 2048 bits. We generated a 2048 bit key pair in our test lab with the following command:
#ssh-keygen -b 2048
During the installation, you will be asked to enter a passphrase. A good passphrase is one that is 10-30 characters long. This is almost impossible to guess and has a hidden meaning only to the person generating it.
155
$ /usr/local/bin/ssh-keygen -b 2048 Generating RSA keys: Key generation complete. Enter file in which to save the key (/home/netview/.ssh/identity): Created directory '/home/netview/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/netview/.ssh/identity. Your public key has been saved in /home/netview/.ssh/identity.pub. The key fingerprint is: 25:15:21:f0:79:02:33:6c:2e:3e:14:e1:46:ed:24:b0 netview@netview2
By default, the generated public key will be stored in the $HOME/.ssh/identity.pub file. Your private identification key will be stored in the $HOME/.ssh/identity file. During key generation, you can enter different locations for key storage. The generated public key has to be sent to the SSH server location. It also needs to be added in the appropriate user file $HOME/.ssh/authorized_keys. When these files do not exist, generate them and add your authorized public key.
$ more $HOME/.ssh/authorized_keys 2048 35 23244990418288751280251897604091034434539205895236075554854747237660346245579243008823 37072194123485249472137918221279442435459012553185812640944351635275824163987130610873 87317198087203844347586620288357029670270344845774865069147845102363935760694352284191 66554825462568718024952218128264674651080665055949252202864701130322440334233396196858 11595331680321928120768294610945037587010943799416208170151663263834564836707307369326 89141907591813317144508110180731093973176752587966464126212342883140134677237383212342 51884590894376187201570863947764325728785179221286154595059572539875766991049259701225 243875351259049 netview@netview2
The generated private key is stored on the SSH client. The following sections show the SSH client access with an AIX client and Windows client to the configured SSH server on the network management system. SSH server access with AIX SSH client The SSH client is integrated in the OpenSSH software package. The easiest way to install this client is to install the OpenSSH package on the client machine in the same way we described. You have to store your private key in the $HOME/.ssh/identity when generating the public/private key pair and storing the public key on the SSH server, as described previously. The client configuration is done in the file /etc/openssh/.
156
# # # # # # # # # # #
more /etc/openssh/ssh_config This is ssh client systemwide configuration file. This file provides defaults for users, and the values can be changed in per-user configuration files or on the command line. Configuration data is parsed as follows: 1. command line options 2. user-specific file 3. system-wide file Any configuration value is only changed the first time it is set. Thus, host-specific definitions should be at the beginning of the configuration file, and defaults at the end.
# Site-wide defaults for various options # Host * ForwardAgent yes ForwardX11 yes # RhostsAuthentication yes # RhostsRSAAuthentication yes RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # Port 22 # Protocol 2,1 # Cipher blowfish # EscapeChar ~
In the configuration file, you can configure, for example, which default port will be used for SSH connection or configure permission for X-Windows forwarding for the client). Start the SSH client on your AIX console with following command:
ssh -X hostname
The command flag -X allows secure X-Windows forwarding over the ssh clients connection.
157
netview@itso8 > /usr/local/bin/ssh mlm2 Enter passphrase for RSA key 'netview@itso8': Last unsuccessful login: Tue Feb 6 11:00:56 2001 on /dev/pts/1 from itso7 Last login: Tue Feb 20 17:10:25 2001 on ssh from itso8 ******************************************************************************* * * * * * Welcome to AIX Version 4.3! * * * * * * Please see the README file in /usr/lpp/bos for information pertinent to * * this release of the AIX Operating System. * * * * * ******************************************************************************* # nv6000
After establishing the connection, you can work with this SSH session as usual with telnet or a xterm session. Now you can start a secure remote session of your network management graphical user interface. The handling of the $DISPLAY variable is done by the ssh server on NetView and the ssh client on your remote AIX system. SSH server access with the Windows SSH client The are different SSH clients for Windows NT available. We used the SSH client of the well known freeware Tera Term, a very comfortable terminal emulation program for telnet, ssh and serial connections. Tera Term is available at:
http://www.download.com/
The SSH function is an add on program for Tera Term, which you can download from:
http://www.zip.com.au/~roca/ttssh.html/
Install the Tera Term program with the installation program. After finishing the installation, extract the SSH client binaries in the Tera Term directory. Start the Tera Term SSH client ttsh.exe. The configuration of SSH authentication in done in the menu Setup->SSH Authentication (Figure 75 on page 159).
158
Figure 75. SSH authentication setup
Store the generated private key on your Windows NT client and select the filename in the RSA key field. Chose the connection username and apply the configuration. Configure your X-Windows forwarding option in the menu Setup->Forwarding Setup (Figure 76).
Figure 76. SSH port forwarding setup
159
The SSH port forwarding dialog allows (besides X-Windows forwarding) other port forwarding configurations. For example, you can allow the configuration of secure connections for tftp, database connections, or other unsecure protocols from secure network in the unsecure network. The SSH session can be started from the Tera Term menu File>-New Connection. See Figure 77 for details.
Figure 77. SSH session startup
Enter the hostname of the SSH server and select the SSH service. In the dialog box, you can choose your SSH server port when it is different from the default SSH port 22. After a successful authentication on the SSH server, you will see the secure shell dialog on your Windows NT client. Now you have a secure channel to communicate with the network management server. See Figure 78 for details.
Figure 78. Running SSH session
160
Note
The transport of X-Windows applications over the SSH tunnel requires an active X-Server (Exceed or Windows NT XFree porting) on your Windows NT server. Then you can direct your NetView graphical user interface over the secure SSH connection.
Firewall configuration Table 25 shows the required firewall configuration for the secure SSH connection from the secure network to the unsecure network. Now you only have to open the SSH port between unsecure and secure network and can transfer all required network protocols, such as X-Windows, telnet, and database protocols, through this tunnel.
Table 25. Firewall rule for SSH test lab
Function SSH connection itso8 to NetView SSH connection server netview to itso8
Source SSH client itso8 SSH server NetView i netview2
Destination SSH server NetView i netview2 SSH client itso8
Protocol SSH/ TCP TCP
SrcPort >1023
DestPort 22
22
>1023
161
162
Chapter 5. Network management through the VPN

This chapter describes an overview of the VPN, the steps required to set up a VPN using IBM SecureWay Firewall, and the steps required to perform network management through the VPN. This chapter also describes the client to site VPN concept and deploying client to site VPNs through the Check Point VPN-1 products.
5.1 VPN overview

The Internet has become a popular, low-cost backbone infrastructure. Its universal reach has led many companies to consider constructing a secure virtual private network (VPN) over it. The challenge in designing a VPN for today s global business environment will be to exploit the public Internet backbone for both intra-company and inter-company communication while still providing the security of the traditional private, self-administered corporate network. With the explosive growth of the Internet, companies are beginning to ask, How can we best exploit the Internet for our business? Initially, companies were using the Internet to promote their company s image, products, and services by providing World Wide Web access to corporate Web sites. Today, however, the Internet potential is limitless, and the focus has shifted to e-business, using the global reach of the Internet for easy access to key business applications and data that reside in traditional IT systems. Companies can now securely and cost-effectively extend the reach of their applications and data across the world through the implementation of secure virtual private network (VPN) solutions. A virtual private network (VPN) is an extension of an enterprises private intranet across a public network, such as the Internet, creating a secure private connection through what is essentially a private tunnel. VPNs securely convey information across the Internet, connecting remote users, branch offices, and business partners into an extended corporate network. Internet Service Providers (ISPs) offer cost-effective access to the Internet (via direct lines or local telephone numbers), enabling companies to eliminate their current, expensive leased lines, long-distance calls, and toll-free telephone numbers. A 1997 VPN Research Report, by Infonetics Research, Inc., estimates savings from 20 percent to 47 percent in wide area network (WAN) costs by replacing leased lines to remote sites with VPNs. And, for remote access
163
VPNs, savings can be 60 percent to 80 percent of corporate remote access dial-up costs. Additionally, Internet access is available worldwide where other connectivity alternatives may not be available. The technology to implement these virtual private networks, however, is just becoming standardized. Some networking vendors today are offering non-standards-based VPN solutions that make it difficult for a company to incorporate all its employees and/or business partners/suppliers into an extended corporate network. However, VPN solutions based on Internet Engineering Task Force (IETF) standards will provide support for the full range of VPN scenarios with more interoperability and expansion capabilities. The key to maximizing the value of a VPN is the ability for companies to upgrade their VPNs as their business needs change and to easily upgrade to future TCP/IP technology. Vendors who support a broad range of hardware and software VPN products provide the flexibility to meet these requirements. VPN solutions today run mainly in the IPv4 environment, but it is important that they have the capability of being upgraded to IPv6 to remain interoperable with your business partner s and/or supplier s VPN solutions. Perhaps equally critical is the ability to work with a vendor who understands the issues of deploying a VPN. The implementation of a successful VPN involves more than technology. The vendor s networking experience plays heavily into this equation.
5.2 VPN solutions in the market

A vendor s VPN offerings can be categorized in a number of ways. In our opinion, the most important differentiator is the protocol layer on which the VPN is realized. In this context, these are the following different approaches to VPN implementation: Network layer-based (IPSec-based) Data link layer-based (layer 2-based) There are other methods that operate on upper layers and complement a VPN solution, such as SOCKS, Secure Sockets Layer (SSL), or Secure Multipurpose Internet Mail Extension (S-MIME). Some vendor s solutions use only the upper layer protocols to construct a VPN, usually a combination of SOCKS V5 and SSL. Most of the discussion in this redbook will be centered on the IPSec-based VPN, as we believe this is most popular solution today.
164
5.2.1 IPSec-based solutions

Within the layered communications protocol stack model, the network layer (IP, in the case of the TCP/IP stack) is the lowest layer that can provide end-to-end security. Network-layer security protocols provide blanket protection for all upper-layer application data carried in the payload of an IP datagram without requiring a user to modify the applications. The solutions are based on the IP Security Architecture (IPSec) open framework, defined by the IPSec Working Group of the IETF. IPSec is called a framework because it provides a stable, long lasting base for providing network layer security. It can accommodate todays cryptographic algorithms, and can also accommodate newer, more powerful algorithms as they become available. IPv6 implementations are required to support IPSec, and IPv4 implementations are strongly recommended to do so. In addition to providing the base security functions for the Internet, IPSec furnishes flexible building blocks from which robust, secure virtual private networks can be constructed. The IPSec Working Group has concentrated on defining protocols to address several major areas: Data origin authentication verifies that each datagram was originated by the claimed sender. Data integrity verifies that the contents of the datagram were not changed in transit, either deliberately or due to random errors. Data confidentiality conceals the clear text of a message, typically by using encryption. Replay protection assures that an attacker cannot intercept a datagram and play it back at some later time without being detected. Automated management of cryptographic keys and security associations assures that a company s VPN policy can be conveniently and accurately implemented throughout the extended network with little or no manual configuration. These functions make it possible for a VPNs size to be scaled to whatever size a business requires. The principal IPSec protocols are: The IP Authentication Header (AH) provides data origin authentication, data integrity, and replay protection. The IP Encapsulating Security Payload (ESP) provides data confidentiality, data origin authentication, data integrity, and replay protection. The Internet Security Association and Key Management Protocol (ISAKMP) provides a method for automatically setting up security associations and managing their cryptographic keys.
165
5.2.1.1 Authentication Header (AH) The IP Authentication Header provides connectionless (that is, per-packet) integrity and data origin authentication for IP datagrams, and also offers protection against replay. Data integrity is assured by the checksum generated by a message authentication code (for example, MD5); data origin authentication is assured by including a secret shared key in the data to be authenticated; and replay protection is provided by use of a sequence number field within the AH header. In the IPSec vocabulary, these three distinct functions are lumped together and simply referred to by the name authentication. 5.2.1.2 Encapsulation Security Payload (ESP) The IP Encapsulating Security Payload provides data confidentiality (encryption), connectionless (that is, per-packet) integrity, data origin authentication, and protection against replay. ESP always provides data confidentiality, and can optionally provide data origin authentication, data integrity checking, and replay protection. Comparing ESP to AH, one sees that only ESP provides encryption, while either can provide authentication, integrity checking, and replay protection. When ESP is used to provide authentication functions, it uses the same algorithms used by the AH protocol. However, the coverage is different. Either ESP or AH may be applied alone, in combination with the other, or even nested within another instance of itself. With these combinations, authentication and/or encryption can be provided between a pair of communicating hosts, between a pair of communicating firewalls, or between a host and a firewall. 5.2.1.3 Internet Key Exchange Protocol (IKE/ISAKMP) A security association (SA) contains all the relevant information that communicating systems need in order to execute the IPSec protocols, such as AH or ESP. For example, a security association will identify the cryptographic algorithm to be used, the keying information, the identities of the participating parties, etc. ISAKMP defines a standardized framework to support negotiation of security associations (SA), initial generation of all cryptographic keys, and subsequent refresh of these keys. Oakley is the mandatory key management protocol that is required to be used within the ISAKMP framework. ISAKMP supports automated negotiation of security associations, and automated generation and refresh of cryptographic keys. The ability to perform these functions with little or no manual configuration of machines will be a critical element as a VPN grows in size. Secure exchange of keys is the most critical factor in establishing a secure communications
166
environment no matter how strong your authentication and encryption are, they are worthless if your key is compromised. Since the ISAKMP procedures deal with initializing the keys, they must be capable of running over links where no security can be assumed to exist. That is, they are used to bootstrap the IPSec protocols. Hence, the ISAKMP protocols use the most complex and processor-intensive operations in the IPSec protocol suite. ISAKMP requires that all information exchanges must be both encrypted and authenticated. No one can eavesdrop on the keying material, and the keying material will be exchanged only among authenticated parties.
5.2.2 Layer 2 based VPN solutions (data link layer)

The following is the list of protocols that are used to implement the Layer 2 based VPN solution: Point to Point Tunnelling Protocol (PPTP) by Microsoft Layer 2 Tunnelling protocol (L2TP) by Cisco and Microsoft Layer 2 forwarding (L2F) by Cisco A remote access dial-up solution for mobile users is a very simple form of a virtual private network, typically used to support dial-in access to a corporate network whose users are all company employees. To eliminate the long-distance charges that would occur if a remote user were to dial-in directly to a gateway on the home network, the IETF developed a tunneling protocol, Layer 2 Tunnel Protocol (L2TP). This protocol extends the span of a PPP connection: instead of beginning at the remote host and ending at a local ISPs point of presence (PoP), the virtual PPP link now extends from the remote host all the way back to the corporate gateway. In effect, the remote host appears to be on the same subnet as the corporate gateway. Since the host and the gateway share the same PPP connection, they can take advantage of PPPs ability to transport protocols other than just IP. For example, L2TP tunnels can be used to support remote LAN access as well as remote IP access. Although L2TP provides cost-effective access, multiprotocol transport, and remote LAN access, it does not provide cryptographically robust security features. For example: Authentication is provided only for the identity of tunnel endpoints, but not for each individual packet that flows inside the tunnel. This can expose the tunnel to man-in-the-middle and spoofing attacks.
167
Without per-packet integrity, it is possible to mount denial-of-service attacks by generating bogus control messages that can terminate either the L2TP tunnel or the underlying PPP connection. L2TP itself provides no facility to encrypt user data traffic. This can lead to embarrassing exposures when data confidentiality is an issue. While the payload of the PPP packets can be encrypted, the PPP protocol suite does not provide mechanisms for automatic key generation or for automatic key refresh. This can lead to someone listening in on the wire to finally break that key and gain access to the data being transmitted. Realizing these shortcomings, the PPP Extensions Working Group of the IETF considered how to remedy these shortfalls. Some members proposed to develop new IPSec-like protocols for use with PPP and L2TP. But since this work would have substantially duplicated the more mature work of the IPSec Working Group, the IETF took the position instead to support the use of the existing IPSec protocols to protect the data that flows through an L2TP tunnel. L2TP is actually another variation of an IP encapsulation protocol. An L2TP tunnel is created by encapsulating an L2TP frame inside a UDP packet, which in turn is encapsulated inside an IP packet whose source and destination addresses define the tunnel s endpoints. Since the outer encapsulating protocol is IP, clearly IPSec protocols can be applied to this composite IP packet, thus protecting the data that flows within the L2TP tunnel. AH, ESP, and ISAKMP/Oakley protocols can all be applied in a straightforward way. In summary, layer 2 tunnel protocols are an excellent way of providing cost-effective remote access. And when used in conjunction with IPSec, they are an excellent technique for providing secure remote access. However, without complementary use of IPSec, an L2TP tunnel alone does not furnish adequate security for the solutions that we discuss later in this redbook. L2TP is a consensus standard that came from the merging of two earlier tunneling protocols: Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Forwarding (L2F; described in RFC 2341). These earlier protocols did not provide as complete a solution as the L2TP protocol; one addresses tunnels created by ISPs and the other addresses tunnels created by remote hosts. L2TP supports both host-created and ISP-created tunnels. As far as vendors are considered, Microsoft incorporates its proprietary PPTP protocol into its Windows NT and Windows 95 operating systems. Microsoft also incorporates IPSec into Windows 2000. Cisco offers L2F and L2TP capabilities in its midrange and high-end router product line.
168
5.3 VPN and network management

The network management requirements are categorized into disciplines. A discipline is a broad category of systems/network management tasks and the functions that address those tasks. Network management is typically divided into six categories, which are listed below. Business management The business management discipline focuses on managing the tasks that support a wide range of enterprise-wide business and administrative functions to improve control of information system assets and provide efficient and effective administrative processes. This typically includes the budgeting, evaluation, and rollout planning exercises for an enterprise management tool. Additionally, this would also cover the hiring policies for the network management personnel and the cost attached. The total network management cost would include both the network management tool cost plus the cost of hiring and maintaining the network management personnel. The change management discipline focuses on managing the introduction of change into an information system environment.
Change management
Configuration management The configuration management discipline focuses on managing the set of resources (hardware and software) and connectivity that provide the exchange of business information within an enterprise and with external customers. This typically includes upgrading to a newer version of the network management tool as well as configuring the network management tool for the new/upgraded hardware/software. Operations management The operations management discipline focuses on managing the use of systems and resources to support the workloads of the enterprise s information systems. This along with the problem management form the most frequently used category and the most
169
important phases of network management where you implement and perform day to day tasks as well as troubleshoot the network management tool. Problem management The problem management discipline focuses on managing problems and potential problems from their detection to their resolution. Problem management focuses on removing the errors from any system. The performance management discipline focuses on managing the effectiveness with which information systems deliver services to their users. This phase involves study of the base line patterns with the help of performance analyzing tools to create a benchmark for your network and fine tune the network for performance enhancement.
Performance management
In general, from the network management viewpoint, the above six disciplines can be applied to the Internet VPN management as well. The following points give an overview of the VPN specific points to be considered: For change management, the gateways (for example, routers) are physically connected through the Internet and the VPNs are logically controlled by tunnel definition on the gateways. The management of changes in VPN is logical rather than physical. For configuration management, the topology, tunnel definition, and applied security policy are maintained centrally in addition to traditional network configuration. The remote access user information must be maintained. The secure key distribution, including certification and directory-based policy management, will be the critical part of the configuration management. For problem management, there are two aspects of connectivity problems in VPN. One is the IP connectivity to the Internet and another is the secure VPN tunnel connectivity over IP connectivity. The VPN tunnel establishment and status monitoring, in addition to IP connectivity monitoring, must be done to identify the problem. For performance management, the normal IP traffic and secure VPN traffic through a tunnel is transferred using one physical line. Normally,
170
performance degradation will occur to VPN traffic. The performance for each tunnel may also be measured as physical line traffic.
5.3.1 SNMP and VPN

The general design consideration for Internet VPN is limiting the automatic network discovery function using a seed file when NMS discovers a network. For a normal IP network, NMS can discover as many network nodes as the network has. But in case of Internet VPN, specific IP addresses for each node must be defined before discovery. Sometimes, intermediate routers cannot provide IP address and interface information at the NMSs request. The network management system can also use a data tunnel between the center gateway and the remote gateway to transfer management traffic between NMS and managed gateways. In this case, no special design considerations exist. The VPN provides a way to use the Java Web client with two ports open instead of the usual thousands of open ports. All the traffic will be encapsulated in a tunnel and the number of ports to be open will be few. As described in Chapter 4, Management in distributed environments on page 101, SSH can also be an alternative to some extent (in case you are just looking for X-windows access through the firewall, as described in Section 4.6.2.2, A sample SSH configuration on page 150). The VPN implementations, however, are not without their pitfalls, as a lot of them face compatibility issues from the client to the VPN gateway. The IBM SecureWay firewall for Windows NT does not come with an IPSec client, so establishing a VPN tunnel between a IPSec client and the IBM SecureWay firewall is very tricky, and often involves hours of analyzing. We had a problem with a Windows 2000 IPSec client and the SecureWay firewall VPN gateway, as the key negotiation between the two have a problem: the SecureWay firewall for Windows NT 4.1 does not support dial-up IPsec clients.
5.4 Implementing VPN using IBM SecureWay FW for Windows NT V4.1

The following section describes the process to implement a secure IPSec firewall between two SecureWay firewalls for Windows NT. IBM SecureWay Firewall for Windows NT supports two modes of tunnels: Static Tunnels Dynamic Tunnels
171
5.4.1 Static tunnel

In this process, the firewall administrator himself defines the tunnel definitions, as well as the protocols to be allowed inside the tunnel. The tunnel activation has to be done manually.
5.4.2 Dynamic tunnels

In this process, the tunnel definitions are made at one point and then exported, and then the definitions are imported at the destination firewall; thus, the whole process of determining the objects of the tunnel is automatic. In the case of dynamic tunnels, the tunnels are automatically activated, while in the case of static tunnels, they have to be manually activated. In the case of dynamic tunnel, the firewall administrator does not have any control over the protocols that can be allowed in the tunnel, that is, all the protocols are allowed inside the tunnel. In our discussion, we will demonstrate the implementation of dynamic tunnels. The implementation of the dynamic tunnel is comprised of the following steps: 1. Define tunnel. 2. Export tunnel. 3. Import tunnel (at the destination firewall). 4. Activate the tunnel. As discussed earlier, dynamic tunnels will allow all the protocols inside the tunnel by default. The first step is to create a tunnel definition. To create a tunnel definition, choose the Virtual Private Networks option on the SecureWay Firewall GUI (Figure 16 on page 57). It will open the dialog box shown in Figure 79 on page 173.
172
Figure 79. VPN main menu
Now we need to define the tunnel. To define the tunnel, click <New>, and the dialog in Figure 80 on page 174 should appear.
173
Figure 80. Tunnel definition
In the tunnel's definition, the following fields have special importance: Tunnel Name: Enter the name of the tunnel. Filter Type: This can be either static or dynamic. When we select Dynamic, the firewall will generate dynamic filter rules each time the tunnel is activated. This means that all the traffic between the specified users will be accepted in the tunnel. When we select Static, we must create the filter rules for the tunnel. We have the possibility to create multiple tunnels; we can decide which protocol will
174
use each tunnel. These filter rules may be more selective, for example, allow specific protocols traffic through the tunnel. Local Tunnel Address: IP address of the nonsecure interface of the loca| firewall. Clicking Select gives us the list with the interfaces. Remote Tunnel Address: IP address of the remote partner's nonsecure interface. Clicking Select gives us the list of the network objects. Local User Address: IP address of the secure network or secure host who will use the tunnel. Clicking Select gives us the list with the network objects (only dynamic tunnels). Remote User Address: IP address of the remote network or host to which we will connect through the tunnel. Clicking Select gives us the list with the network objects (only used for Dynamic Filter type). Remote SPI: Specifies the security parameter index (SPI) value the tunnel partner will use. The value entered must be greater than 255. The definition of SPI is described in RFC 2401. Basically, the SPI in conjunction with the target address will uniquely identify the set of security information (such as encryption key(s), key lifetime, and so on) for your tunnel partner. You should check with the tunnel partner and obtain an unassigned SPI from it. Local SPI: Specifies the security parameter index (SPI) value the tunnel owner will use. The value is entered automatically. Policy: Defines which policy we will use; we can select Authentication (AH), Encryption (ESP), or both (ESP/AH). Authentication Algorithm (AH): The type of authentication algorithm we will use; the types available are HMAC_MD5 and HMAC_SHA. Encryption Algorithm (ESP): The type of authentication algorithm and encryption algorithm we will use. The encryption types are CDMF, DES_CBC, 3DES_CBC, or none, depending on the country version of the firewall. For authentication, we can select HMAC-MD5, HMAC-SHA, or none. We cannot select None for both authentication and encryption with ESP. Once we have defined the tunnel parameters, we need to export this tunnel to the partner firewall. To do this, you need to highlight the tunnel you have just defined and click on Export. You will be able to see the panel shown in Figure 81 on page 176.
175
Figure 81. Exporting the tunnel definitions
Typically, you would export the tunnel definition onto a floppy. You would also have to find a secure way to send these tunnel definition parameters to the partner firewall. One of the methods could be to send the definition in a encrypted manner to the partner firewall. At the partner firewall: Once you have got the tunnel definition parameters to the partner firewall, you need to import them into your firewall. To do this, you need to select Virtual Private Networks from the firewall main menu and then select import in the VPN panel. Once you do this, you will be able see the panel shown in Figure 82.
Figure 82. Importing a tunnel definition at the partner firewall
You will need to input the tunnel file location into a directory (for example, a:\vpn\), and when you click on the Select option in the tunnel list, you will be able to see the tunnel definition and that the secureway firewall automatically picks up the tunnel ID from it. Once the import process is over, you would
176
notice the local tunnel address and the remote tunnel address have been interchanged to reflect the correct configuration on the partner firewall side.You can view the tunnel configuration parameters on the partner side firewall by selecting the tunnel which you have just imported. You would be able to view all the details of the tunnel, as shown in Figure 83.
Figure 83. View of the imported tunnel
You should be ready with all the required network object definitions so that the tunnel creation process is made simpler. If for some reason, you wish to deactivate a tunnel manually, you could do so by selecting the tunnel and selecting Deactivate. You could also reactivate the tunnel, as shown in Figure 84 on page 178.
177
Figure 84. Activating the tunnel
5.5 Client to site VPN

This section describes the need and the steps required to build a client-to-site VPN. This will be demonstrated by using the Check Point VPN-1 Gateway running on the firewall and the Check Point VPN-1 SecuRemote client. In a service provider scenario, the technical staff of the service provider feel there is always a need to manage a remote network and troubleshoot it, when required, while sitting either in the office or in their homes. The tech staff would be concerned with the security of such a transaction when they are out of the office and accessing the customers network. To make this transaction secure, one of the solutions we recommend is that this communication be secured using the VPN technology. The lab setup for this scenario involves a client who has the Windows 2000 operating system and has the secure remote client (FWZ/IPSec) client designed for the Check Point firewall. This client can be downloaded from the Check Point site at:
(http://www.checkpoint.com)
We will be describing both the client as well as the VPN gateway setup in the following section. We have tested the configuration with SecuRemote client for Windows 2000 and Check Point FireWall V4.1 SP2 as the VPN gateway.
178
The next section describes the process of establishing a secure tunnel between a remote client and the customer network. In this method, the remote client will be communicating with the corporate network. The communication will be initiated by an IPSec compliant client that will be installed on the remote client. We would also be using the VPN feature built into the firewall to achieve this tunnel. Figure 85 shows the implementation of a client to site VPN solution.
Figure 85. Client to site VPN
5.5.1 Implementing a client - site VPN using the Check Point VPN-1
This section discusses the various steps required to create a client to site VPN using the Check Point VPN-1 Gateway product as the VPN gateway and the Check Point VPN-1 SecuRemote as the client. We will be describing the FWZ encryption for the Check Point based solution. The IPSec based solution is described in Section 5.5, Client to site VPN on page 178. 5.5.1.1 Configuration on the Check Point VPN-1 Gateway The Check Point VPN-1 installation is described in Appendix B.2, Installation on page 311. Start the Check Point FireWall-1/VPN-1 policy editor from the Windows Programs menu and you will be able to see the Check Point initial authentication panel, as shown in Figure 86 on page 180.You need to recall the password that you gave while installing the Check Point FW-1/VPN-1. This will allow you to get access to the Check Point policy editor.
179
Figure 86. Check Point FireWall-1/VPN-1 login panel
Once you have access to the policy editor, you need to define a default Deny All rule that will drop all the packets which do not match any of the rules that you will define later. The next step would be to create the network objects that will help us design our rules later. To define the network object, choose Manage->Network Object . You will able to see the panel shown in Figure 87; select New... . .
Figure 87. Create new network object
You need to create a network object that will identify our secure network (132.17.254.0) so that it can be effectively used in our rules definition later. To accomplish this task, you need to select New and Network as the type of the object you want to create. Once you do this, you will be able to see the
180
panel shown in Figure 88. You could choose any name for the name option, but a meaningful name would help later identification. In the IP address field, you need to input the network ID of your internal network. You could also put in descriptive comments. The concept of network objects is similar to both the SecureWay firewall and the Check Point firewall. You may recall creating the network objects on the SecureWay firewall earlier in this redbook.
Figure 88. Defining network object of type network
After filling in the Secure Network and clicking on OK, you need to choose New for the second network object and choose Workstation from the list of options given. This allows you to define the firewall as an object and define the characteristics of the firewall. Once you choose Workstation , you will be able to see the panel shown in Figure 89 on page 182.
181
Figure 89. Workstation properties of the network object
Please remember to choose the workstation type as gateway instead of host so that this gateway will be a one point encryption object for the rest of the secure network. In the name field, enter the host name of the firewall system and then select Get address from the IP Address option. The FireWall-1 and VPN-1 can also be managed from any other system; you need to select the Check Point modules installed as VPN-1 and FireWall-1 in case you have installed the VPN-1 product on this system. Now you need to define the other parameters of this workstation by choosing various tabs on the properties. Next, you need to define the network interfaces of the firewall. You need to choose Interfaces tab from the Workstation Properties panel and select Get from the options available, and the firewall will recognize the interfaces that are present in the system. The firewall that we tested had two interfaces, as shown in Figure 90 on page 183. However, you can change the name of the interface to make it more meaningful, for example, secure interface and the non secure interface. In our example, 132 interface is the secure interface and 192 interface is the non secure interface.
182
Figure 90. Defining network interfaces
Next, you define the authentication option in the workstation properties. This will help us define what authentication options this firewall supports. To configure this option, choose the Authentication tab in the Workstation Properties dialog box. You should be able to see the panel shown in Figure 91.
Figure 91. Authentication option for the workstation
As you notice, the workstation can support up to seven different authentication options. Since we would be using the firewall password as our key, we have selected two options, as shown in Figure 91. In case your environment has additional authentication options, you can choose from the
183
above list so that clients using those options can be successfully authenticated. The next step would be to define the VPN parameters of the workstation properties. We define the encryption parameters as well as the VPN related parameters. To do this, select the VPN tab from the Workstation Properties dialog box. You should see the panel shown in Figure 92.
Figure 92. VPN parameters definition
The Domain option in the panel allows the definition of an encryption domain, that is, the list of systems/interfaces that this gateway will encrypt. We want the remote client that comes through the VPN be given access to the entire secure network, so we choose the other option and then select Secure Network. In case you choose only valid addresses (the second option), the encryption will be limited to the interfaces defined in the Interfaces tab earlier. You also need to select the check box Exportable for SecuRemote, as this will allow SecuRemote clients to connect to this firewall and download the configuration keys, which will be demonstrated later in Section 5.5.1.2, SecuRemote client configuration on page 194. The next option would be to choose the encryption schemes for the workstation. We chose the FWZ option (In this redbook, we are demonstrating the VPN encryption through FWZ encryption. However, the process remains the same for IKE, except that the IKE parameters have to be
184
defined). Once you choose the FWZ option and select the Edit option, you will be able to see the panel shown in Figure 93.
Note
The key parameters (exponent and the modulus) will not be initially filled.
Figure 93. FWZ encryption properties
You need to select the generate option to generate the key for yourself and to export to the SecuRemote client later. Additionally, you should also create the DH (Diffie-Hellman) key in the DH tab of the properties. The next option you need to select is the Encapsulation tab, as shown in Figure 94. This will allow us to encapsulate the traffic between the client and the VPN-1 gateway.
Figure 94. Encapsulate the traffic
185
This will complete the configuration on the VPN tab of the workstation properties. In summary, on the VPN tab, we created the VPN-1 gateway, defined the interfaces, defined the authentication schemes, and defined the VPN parameters, which included the encryption domain definition, encryption scheme configuration, and the key generation. We also ensured that the traffic was encapsulated. Please remember to check the Export to SecuRemote option; otherwise you would have to create a configuration file (userC.c) at the client. Now that we have created the VPN gateway and configured it, we need to now define who will be using this service, that is, we need to create the user who will be using this VPN service. Please note that although you can create an IP address to the firewall VPN, we recommend that you create a VPN based on user names, so that anybody who has the access to the IP address does not have VPN access. To create a new user in VPN-1 you need to select users from the Manage menu. Once you do that, you will see the panel shown in Figure 95.
Figure 95. User creation menu
Note that there is a default user, which is created by the VPN-1 by default. You need to create an additional user who can access the VPN services that
186
we defined. To do that, select New and then select Template User. Once you do that, you will see the panel shown in Figure 96.
Figure 96. User creation and configuration
Note
The expiration date option is set, by default, to 31-Dec-2000. You need to change it to suit your requirements; otherwise, this user will never will be able to access the VPN or any other service. If you want a group of users to be able to access the VPN service, you can create user groups by selecting the Group tab in the menu; you will then be able to assign the user to a group. You should select what type of authentication this user will be subjected to.You can select the authentication method you require. We have selected the VPN-1 and Firewall-1 password, and as soon as you select this option, you will be asked for the password, as shown in Figure 97 on page 188. You can enter the required password and this will be used for your initial authentication for the SecuRemote clients.
187
Figure 97. User authentication definition
Next, you should configure the user encryption properties. This option will let you define the encryption properties for this particular user (Ram). To configure this option, you need to select the Encryption tab in the User Properties dialog box. The panel in Figure 98 should appear. In this option, you can select the type of encryption scheme this user uses. As we are using the Check Point FWZ encryption, you need to select the FWZ option to further configure the encryption settings.
Figure 98. User encryption properties
188
Once we select the Edit option in the Client Encryption Methods, you will see the panel shown in Figure 99.
Figure 99. FWZ properties configuration
Now we have created the VPN-1 Gateway configuration and its user.
189
The next step is to create a rule that allows this VPN connection. To do this, you need to select Edit->Add a Rule; The panels shown in Figure 100 and Figure 101 will appear.
Figure 100. Creating the VPN rule (left half of the panel)
Figure 101. Creating the VPN rule (right half of the panel)
Observe the rules currently defined. You can see there are two rules defined; the bottom one is a Deny All rule. This allows the firewall administrator to drop all the packets that do not match any of the rules above it. The top rule is the VPN rule. The components of this rule are:
190
Source:
This will indicate who will be the source for this rule. As our objective is to allow the user Ram to create a VPN and use an encrypted communication, we need to right-click on the source and choose Add with the User option. Since Ram is the only user created, we have configured the source to be All Users. In other cases, you may want to create users and then put them as a source. As we have to allow the user access to the entire network you need to right click on destination and choose the secure network as the option. As this communication will be fully secure and the traffic encrypted we are allowing the remote user all the services available in the firewall. However if you wish you could restrict the services to your requirement. We should choose client encrypt because the traffic should be encrypted and the encryption should start from the client.Other options include accept, deny etc. This field is basically for logging. Setting this field to long will enable a detailed log description this rule. This field indicates where rule should be installed. You need to choose either the firewall (host name: FW2) or the Gateway. In case you want this connection to be operational at certain time frames. For any description
Destination :
Service:
Action :
Track: Install on:
Timing: Comment :
Now that we have completed the rule definition, make this policy active (remember, regenerate in the SecureWay firewall). To do this task, you need to Policy->Install. Once you choose Install , you should see the panel shown in Figure 102 on page 192.
191
Figure 102. Policy install
You now need to select FW2 (the workstation object you had created earlier) and then choose OK. Once you do this, the installation of policy begins and once the generation is completed, you will see the panel shown in Figure 103.
Figure 103. Policy installation
Now we need to accept unauthenticated FWZ traffic into the firewall because the client connection from a SecuRemote client starts with FWZ traffic. You will allow the remote user to be authenticated as per the user policies defined earlier. This is achieved by selecting Policy->Properties->Desktop Security, as shown in Figure 104 on page 193.
192
Figure 104. Accepting unauthorized FWZ traffic
You also need to apply the rules for all inbound traffic, that is, traffic that hits the firewall (either from the nonsecure or from the secure network; both are inbound traffic). In case you apply these rules on either (both in and outbound), then you need to create additional rules for outbound also. This can be done by selecting Policy->Properties and then selecting the Security Policy panel, as shown in Figure 105 on page 194. After this, you need to install the policy once again.
193
Figure 105. Policy properties
Now you have completed the server side of the configuration. 5.5.1.2 SecuRemote client configuration The installation of the SecuRemote client is described in the Appendix C, Installing Check Point SecuRemote VPN client on page 329. The first step is to create a site for the client to connect to. To do this, open the SecuRemote client at bottom right corner of your Windows 2000 main panel and then choose the Create from the Site menu, as shown in Figure 106 on page 195.
194
Figure 106. Create a site on the SecuRemote client
You need to create the site by entering the unsecure interface of FW1, which in our case is 192.168.104.253. Once you enter the address and select OK, the client sends a key retrieve request to the FW1. Recall that we set our Desktop Policy properties to accept unauthenticated FWZ/IKE requests; because of this setting, the client will be able to download the key details from the FW1. Once the client downloads the keys, you will see the panel shown in Figure 106. Now you have created the site, the next step is to be authenticated by that site through the user we created. To do this, select the site you have created and right-click on it. Choose the Set Password option. You will see the panel shown in Figure 107 on page 196.
195
Figure 107. SecuRemote client authentication
Enter the user name we created earlier on the server, enter the password, and select OK. Select FWZ from the Tools and Encryption option. You are now successfully authenticated. You can start any encrypted communication between the client and the VPN-1 gateway.
Note
Please note that there is no message stating that you can start the session. If you do not receive any messages, you are through with the authentication and ready to go. Now to demonstrate that you can reach the secure network, we will try and ping one of the hosts in the secure network. Open a command prompt and issue a ping command to one of your hosts on the secure network. In our case, the secure network is represented by 132.17.254.0. You should be able to ping this host. To verify if this traffic actually encrypts and encapsulates and is doing what it is supposed to do, issue a tracert command and you will be able to see only the last packet, which has reached the destination, not the intermediate hops. See Figure 108 on page 197 for details.
196
Figure 108. Tracer Route example of encryption and encapsulation
To demonstrate one more protocol, telnet from the SecuRemote client to one of hosts in the secure network. Open a telnet session, as shown in Figure 109
Figure 109. Telnet to a secure host
You will get the login prompt from the remote host (which in our case is a AIX host). You can now log in to the host by giving the username and password, as shown in Figure 110 on page 198.
197
Figure 110. Telnet to secure host
To verify if the traffic is really secure, we used the Ethereal packet sniffer and captured this communication. As you can see, the entire session comes in the sniffer as unknown. This means that the traffic is very secure. The Ethereal description says unknown because the sniffer is not able to determine the type of the packet. We have included a sample of the Ethereal capture, as shown in Figure 111 on page 199. Notice the highlighted packet (and some of the rest) that says unknown; because the sniffer cannot read the packet completely, the unknown output is given.
198
Figure 111. VPN traffic - sniffer output
5.5.1.3 Network management through VPN The Java Web client allows us to access the NetView servers that are inside the secure network. A brief explanation of the NetView Java Web client is given in Section 4.6.1, Remote access with the Java Web client on page 142. The next example we have chosen is the NetView Java Web client communication between the VPN client and the NetView server, which is located inside the secure network. The Java Web client is important because in a normal firewall environment, you had to open up a lot of ports on the firewall that were not secure. Because this communication is tunneled into the VPN-1 gateway on the firewall, you do not have to open any additional ports, thus making the communication secure as well as giving the client ability to reach and manage the NetView servers behind the firewall. Figure 112 on page 200 show the sniffer output of the Java Web client without the tunnel.
199
Figure 112. Java Web client (normal communication, non-VPN)
With the VPN configured, we used the Java Web client to reach the NetView server. This will bring up the dialog box shown in Figure 113 on page 201.
200
Figure 113. NetView Java Web client authentication
Once you key in the user name and password, this information will be sent to the NetView server and you will be able to see the main menu in the client. Select File->Open , and you will have the option of viewing the maps, as shown in Figure 114
Figure 114. Java Web client map options
Once you select the correct map, you will be able to see the NetView map. Figure 115 on page 202 shows the sniffer output of the NetView Java client through the VPN. All packets for the session are unknown, because they are encrypted.
201
Figure 115. Sniffer output of the Java Web client after VPN implementation
You can compare the communications with and without the VPN client active for further understanding. In this section, we demonstrated the client to site VPN configuration, which included: Definitions on the server Definitions on the client Encryption parameters Examples of applications (ping, telnet, and the Java Web client)
202
5.5.1.4 Implementing a VPN client behind a firewall This section discusses the process and configuration for when the SecuRemote client itself is behind a firewall, as shown in Figure 116.
Figure 116. SecuRemote client behind a firewall
The basic assumption for this scenario is that a technical support person from the ISP side is trying to troubleshoot a NetView problem in the customer s network. The NetView server exists within the encryption domain that is configured as part of the VPN definition. In order to ensure that this communication is secure, he/she is using a SecuRemote client. The ISP also has a firewall, which in our case is an IBM SecureWay firewall, and the customers firewall is the Check Point FireWall-1/VPN-1 gateway. The SecuRemote client points to the SecureWay firewall as the default gateway. Because there are no rules or definitions to allow traffic for the SecuRemote client, the packets will be dropped. There are essentially two things to be done on the SecureWay firewall. You will need to define couple of rules on the SecureWay firewall. The first step is to allow ipip traffic from the SecuRemote client to the partner firewall (Check Point firewall). To do this, select Rules from Connection Templates in the main menu and define the rule, as shown in Figure 117 on page 204.
203
Figure 117. Rule definition to allow ipip
The next step is to create another rule that allows traffic on UDP port 259. This port is used by the SecuRemote client to communicate to the Check Point VPN-1 gateway. You can create this rule as shown in Figure 118 on page 205.
204
Figure 118. Rule definition to allow port 259 on the firewall
Once you define these rules you need to add these rules into a service and associate the service with a connection. To add these rules in a service, select Connection Templates->Services and select New. Give the service an appropriate name and in the panel where you can add the rules, click on Select and add the rules, as shown in Figure 119 on page 206.
205
Notice the third rule, which is essential to allow the traffic from the Check Point side. Basically, both the SecuRemote client and the VPN-1 Gateway communicate on port 259.
Figure 119. Defining the service
Now you have to create two connections to reflect one originating from the SecuRemote client and one originating from the Check Point firewall.
206
To do this, select Connection Setup->New and create the two connections, as shown in Figure 120 and Figure 121 on page 208.
Figure 120. SecuRemote Connection 1
207
Figure 121. SecuRemote Connection 2
Once you define these connections, you have to regenerate these rules. To do this, select Connection Control and select Execute, as shown in Figure 122 on page 209.
208
Figure 122. Regenerate the rules
Now you can access the SecuRemote client and use all the applications that you require to and from the client to the secure network. In case you do a tracert route from the SecuRemote client, you will still only be able to see the final destination, and the sniffer output says unknown, which indicates that the packets are encrypted.
5.6 VPN client/server configuration

In todays networked world, with huge networks spanning geographical boundaries, it is imperative that an organization manages its network efficiently with minimal downtime. Even when there is downtime, service must be restored at the earliest moment. This brings us to the discussion of how we allow expert network management specialists from anywhere in the world to have access to the corporate network and troubleshoot. This task was pretty easy to accomplish five years ago when the realization of security implications in the network was in its early stages. Today, the challenge is to achieve the fine line of balance between flexibility and security. For that to happen, all the security aspects must be figured in before anybody is given
209
access to the corporate network. This kind of dilemma for the corporation is addressed by the concept of client to VPN solutions, where any authorized person could access the network management station with minimal opening of ports on the firewall. This scenario is highlighted in Figure 123. In a NetView environment, there is always a need for the network specialist, who is outside the secure network, to be given access (typically through the Java Web client) to the NetView server inside the secure network. The problems of Java Web client in a normal firewall environment was discussed in Section 4.6.1, Remote access with the Java Web client on page 142. The following section describes the various methods by which we can achieve the client to site VPN by which we can ensure secure access to the NetView.
Figure 123. VPN client/server configuration
5.6.1 Windows 2000 VPN configuration

The following section describes the process to set up a VPN with Windows 2000 as both the client and the server. The lab for this setup included a Windows 2000 server with NetView Version 6.0.1 installed. The client was a Windows 2000 client with the IPSec client and the NetView Java client. 5.6.1.1 IPSec server configuration This section describes the various steps to be performed on a Windows 2000 server (it is also the IPSec server).We will be creating a custom console for the VPN connection so that the focus is on VPN. To do this:
210
1. Select Start->Run from the main panel and enter mmc and click OK. 2. On the console menu, click on Add/Remove Snap-in and select Add. 3. In the Add Standalone Snap-in dialog box, add Computer Management (verify that the local computer is selected). 4. Repeat steps 1 to 3 to add the snap-in group policy and select Finish. We now have a custom console. Next, we need to define the IPSecurity policy on the IPSec server. To do this, right-click on IPSecurity policies on the local system and select Add, as shown in Figure 124.
Figure 124. Creating a new security policy
Once you select Create IP Security Policy, you will be able to see the panel shown in Figure 125 on page 212.
211
Figure 125. Security Policy creation wizard
Click Next and the following panel will guide you through the policy definition. Once you click Next, you will be able to see the panel shown in Figure 126.
Figure 126. Define the security policy
212
You need to name your security policy and, optionally, give a brief description about the policy. Once you complete this task and click Next, you will see the panel as shown in Figure 127. .
Figure 127. Request for secure communication
Through this panel, you will able to choose the default response option. This will be applicable if any policies defined on your system does not match the incoming packet. Because we will be communicating only with trusted clients, unselect this box and click Next. Once you do this, you see the panel shown in Figure 128.
Figure 128. Policy Wizard - Edit panel
213
Select the Edit Properties check box, which will enable you to proceed with the configuration. Select Finish, and you will see the panel shown in Figure 129. .
Figure 129. Policy properties
As you can see, this action lists the default policies, but we have to configure our own policy that will cater to the specific requirement. To do this, select Add from the options; you will see the panel shown in Figure 130.
Figure 130. Tunnel end point definition
214
In this panel, you will be asked to choose the tunnel endpoints. In case you need to configure IPSec tunnel mode, you need to give the VPN gateway address. In our case, as we are demonstrating the transport mode (end to end host encryption), we will choose the first option. Once we select the first option and click Next, you will see the panel shown in Figure 131.
Figure 131. Policy network type
This will allow us the option of enabling the policy on selected network types. You can select whichever type meets your requirement. We have chosen all network types as our selection. Once you click Next, you will see the panel shown in Figure 132.
Figure 132. Policy authentication methods
215
This panel will allow you to choose the authentication method you want. The default is the Windows 2000 Kerebros. The other options are certificates or the pre-shared keys. We choose the pre-shared secret. The pre-shared secret is not hidden, which means anybody having administrator or equivalent rights can see this pre-shared secret. Once you select the secret and click Next, you will see the panel shown in Figure 133.
Figure 133. IP filter list addition
This panel will allow you to create the filters that are required for this policy. We have to create a new filter for our policy. To do this, select Add from the options. You should see the panel shown in Figure 134 on page 217.
216
Figure 134. IP filter addition
Input a filter name and description that will meet your requirements and select Add from the options. You will see the panel shown in Figure 135.
Figure 135. Filter wizard
217
Click Next in the Wizard, and you will see the panel shown in Figure 136.
Figure 136. IP traffic source definition
This panel will allow us to define the source of the traffic. This also gives us the option of defining the local IP address, a specific address, or a subnet, because this definition involves only the local computer we chose (My IP Address). Once you click Next, you will see the panel shown in Figure 137.
Figure 137. Traffic destination
In this panel, you will be able to define the destination of the traffic. Once again, it could be a specific host or a subnet. In our lab case, we have a one to one communication, so we will choose the specific IP address and input our partner s IP address. Once you click Next, you will see the panel shown in Figure 138 on page 219.
218
Figure 138. IP protocol type
This panel will allow us to define the protocols that will be allowed in this filter. We have selected all the protocols, as this connection will be an encrypted connection. Once you click Next, you will see the panel shown in Figure 139.
Figure 139. IP filter wizard
Click Next in this panel, and you will see the panel shown in Figure 140 on page 220.
219
Figure 140. Complete filter rule creation
You should be able to see the filter rule you have created in the filters section in the panel. Select Close to come out of the filter definition. You see the panel shown in Figure 141 on page 221.
220
Figure 141. IP filter list
This panel will allow us to associate the rule we just defined to our overall security policy. Scroll down the filters and select the filter you just created. Once you click Next, you will see the panel shown in Figure 142 on page 222.
221
Figure 142. Filter action
In this panel, you will required to define the filter action that your policy is supposed to take. To create a new filter action, select Add from the options, and you will see the panel shown in Figure 143.
Figure 143. Filter action wizard
222
Click Next in this panel for the wizard to guide you through the filter action creation. You will see the panel shown in Figure 144.
Figure 144. Filter action name
Create a filter action name and the required description and click Next. You will see the panel shown in Figure 145.
Figure 145. Filter action general options
In this panel, you can permit the packets, block the packets, or allow the traffic securely. Since we want to establish a secure communication, we will select Negotiate security. Click Next, and you see the panel shown in Figure 146 on page 224.
223
Figure 146. Communication with non-IPSec computers
In this panel, you have the option of communication either only with an IPSec enabled computer or, optionally, fallback to unsecure communication when the client does not support IPSec. Because we want to establish a secure communication, we will choose the Do not communicate option and click Next. You will see the panel shown in Figure 147.
Figure 147. IP traffic security
In this panel, you are allowed to choose from the various options in authentication and encryption. The second option will cater to only
224
authentication and the third option (custom) is for advanced settings, where you would want to change the authentication or the encryption algorithm. We will choose the highest level of security that is authenticated as well as encrypted and click Next. You will see the panel shown in Figure 148.
Figure 148. Filter action wizard
Click Finish and you will see the panel shown in Figure 149 on page 226.
225
Figure 149. Filter action selection
Now you need to associate the filter action that you just created to the security policy. To do that, scroll down the filter actions and select the one which you just created. Click Next, and you will see the panel shown in Figure 150 on page 227.
226
Figure 150. Security rule wizard
Click Next, and you will see the panel shown in Figure 151.
Figure 151. IP security rules
227
With this panel, you have defined the rule that allows your system to interact with another host (192.168.104.77). Now select the rule that you have just finished creating. Once you select Close, you will see the panel shown in Figure 152.
Figure 152. Assign the rule to the system
In this panel, you have to assign the rule which you have just created. To do this, right-click on the rule you have just created and select Assign. You will see the Assign change from No to Yes. This completes the configuration at the server end. 5.6.1.2 IPSec client configuration The Windows 2000 client configuration is exactly the same as all the above steps. However, there is one change at the Client where you need to choose the partner IP address, as shown in Figure 153 on page 229.
228
Figure 153. Filter properties of the client
5.6.1.3 Activation and testing of VPN connection Now we will test the VPN by pinging from the IPSec client to the IPSec server. We used Ethereal to sniff the packet to verify the security of the packets. Figure 154 on page 230 shows that the entire communication is secured. In the sniffer output (Figure 154 on page 230), you can view the first part where IKE negotiation happens and then ESP does the encryption of all the packets; that is the reason we will not be able see either the protocol or the port number in the sniffer. In Section 5.6.3, Firewall configuration rule on page 255, we will discuss the ports to be opened on the firewall if the IPSec server is behind a firewall and client in the unsecure network.
229
Figure 154. Sniffer output of the ping packet from the client to the server
5.6.2 AIX VPN connection

AIX Version 4.3.2 and AIX Version 4.3.3 provide an IPSEC client, as well as the gateway functions for building comprehensive VPN networks. In this section, we describe a solution that will address the issues discussed in Section 4.6, Remote access to network management system on page 141. We will build a solution where a Windows 2000 IPSEC client, with a NetView Java console, builds a secure IPSEC connection to the IPSec gateway on the AIX server that is running NetView for UNIX. The following steps are required for building a VPN connection between the AIX server and the Windows 2000 workstation: 1. Configuration of IPSEC sever on AIX Version 4.3.3 2. Configuration of IPSEC client on Windows 2000 3. Activation and Testing of VPN connection
230
This section describes a very specific VPN solution for the AIX server with a IPSEC compatible client. For more detailed descriptions of the different VPN features for client/server configuration of AIX-based servers, see the redbook A Comprehensive Guide to Virtual Private Networks, Volume III: Cross-Platform Key and Policy Management , SG24-5309. 5.6.2.1 Configuration of IPSEC server on AIX 4.3.3 The IP security functions have to separately installed and started on an AIX server. The following filesets have to be installed from AIX Version 4.3.3 installation CD-ROMs: bos.net.ipsec.rte - The run-time environment for the kernel IP Security environment and commands bos.net.ipsec.keymgt - The tunnel manager and IKE daemons that perform key management bos.net.ipsec.websm - The IP Security configuration GUI These filesets have to be installed from the AIX bonus CD-ROM: bos.crypto for CDMF support (40-bit key Commercial Data Masking Facility - available on the World Trade Accessory Pack) and either bos.crypto-wt for DES (56-bit Data Encryption Standard - available on the U.S. Accessory Pack) or bos.crypto-priv for Triple DES support (available in U.S. and Canada only) After installation (by using the AIX administration program smitty), IPSEC can be configured and activated through the Web-based System Manager. You can start the network system manager by using following command:
/usr/websm/bin/wsm
On the Web-based System Manager, double-click the Network icon and the Network Configuration panel is shown, as in Figure 155 on page 232. You can also start the network system manager by using the following command:
/usr/websm/bin/wsm network
231
Figure 155. VPN configuration panel
Right-click on the entry Internet Key Exchange (IKE) Tunnels and select Start IP Security to start the IPSEC stack. The Start options panel will be displayed, as shown in Figure 156 on page 233.
232
Figure 156. IP security start options dialog
Select the option Start IP security immediately and on every subsequent system startup. You can deny or permit all non-secure packets. Once the IP Security kernel extension has been loaded, the IPSEC tunnels are ready to be configured. To define the IPSEC tunnel, you have to define two management tunnels: Key management tunnel: This will be used for key negotiation (IKE) between the IPSEC server and client. Data management tunnel: This will be used for data exchange between the IPSEC server and the client. Open the Internet Key Management configuration application by double-clicking on the Internet Key Exchange (IKE) Tunnels in the Network Configuration panel, as shown in Figure 155 on page 232. This will open up the dialog box shown in Figure 157.
Figure 157. Internet key management application
233
Define a Key management tunnel by clicking on the menu Tunnel -> New Key Management Tunnel . It will open the Key Management Tunnel properties panel, as shown in Figure 158.
Figure 158. Key management tunnel properties panel
On the Identification panel, enter the key management tunnel name. In this example, it is aix_win2000. Select IP address as Host Identity type for the local and remote endpoints of the tunnel and enter the IP addresses of the local (AIX server) and remote hosts (Windows 2000 client). In this example, they are: Local Host Identity: 132.17.254.10 Remote Host Identity: 10.69.14.18 Select the Key (Phase 1) Policy tab. The Key Management (Phase 1) Tunnel Properties panel is displayed (see Figure 159 on page 235).
234
Figure 159. Key management policy panel
Define your Key management policy by clicking on the New button. The Key policy property panel will be opened, as shown in Figure 160 on page 236.
235
Figure 160. Key policy property panel
Insert a policy name. In this example, it is aix_windows2000Pol. Select the Proposals tab. The proposals will be displayed, as shown in Figure 161 on page 237.
236
Figure 161. Key management proposals
Now you have to define a proposal for the key management. Define a new proposal for your tunnel by clicking on the New button. The Key management proposal properties panel, will be opened, as shown in Figure 162 on page 238.
237
Figure 162. Key management proposals properties
Define your proposal name. In this example, it is aix_windows2000prop. Select the protected (Oakley Main mode) for identity protection of key exchange. Define your IP security transformation method by clicking on the New Button. The transform properties panel will be opened, as shown in Figure 163 on page 239.
238
Figure 163. Transform properties panel
Select the Pre-shared key authentication method: For hash algorithm, chose HMAC MD5 For encryption algorithm, chose DES For the Diffie-Helmann group for key exchange, use Group 1 For key lifetime, use the default values After defining of your transform properties parameters, click OK , and you come back to your Key management proposal properties panel, as shown in Figure 164 on page 240.
239
Figure 164. Key management proposals properties after transform definition
Now you can see a new entry in the IP security transforms field. Click the OK button for finishing the definition. In the Proposal Property dialog box, the newly defined proposal, aix_windows2000prop, is now shown (see Figure 165 on page 241).
240
Figure 165. Key management policy panel after proposal definition
Select the newly defined proposal and associate it with your key management policy aix_windows2000. Click OK and you have finished the Key management policy definition. Now you have a new entry for your defined key management policy in the tunnel property dialog box, as shown in Figure 166 on page 242.
241
Figure 166. Key management policy panel after policy definition
Select aix_windows2000 and associate it with your tunnel definition. Then select the Authentication Method/Key tab to bring up the panel shown in Figure 167 on page 243.
242
Figure 167. Key management authentication method
Input your pre-shared key in hexadecimal or ASCII form in the key fields. In this example, it is 12345678. This key is also defined on the IPSEC client. After clicking the OK button, you have finished the Key management tunnel definition. In the Key management dialog box, a new entry is created, as shown in Figure 168.
Figure 168. Internet Key Management Application after key tunnel definition
Define the data management tunnel through the menu New Tunnel->New Data Management Tunnel.... The Data Management Tunnel dialog box will be opened, as shown in Figure 169 on page 244.
243
Figure 169. Data management tunnel dialog
Define the data tunnel name. In this example, it is aix_win2000. Associate the defined key management tunnel with the data tunnel. Select the Endpoints tab to open the dialog box, as shown in Figure 170 on page 245.
244
Figure 170. Data management tunnel endpoint definition
Define the data tunnel endpoints by selecting the endpoint type as host and entering the IP-addresses for local host (AIX server) and remote host (Windows 2000 client) in the HOST ID fields. In this example, they are: Local Host Identity: 132.17.254.10 Remote Host Identity: 10.69.14.18 Select the Data (Phase 2) Policy tab, as shown in Figure 171 on page 246.
245
Figure 171. Data management policies
Define a new data management policy by clicking on the New button. The data management policy property panel will be opened, as shown in Figure 172 on page 247.
246
Figure 172. Data management policy property panel
Enter the new policy name. In this example, it is aix_windows2000Pol. Chose No PFS for the responder role and select the Proposals tab to bring up the panel shown in Figure 173 on page 248.
247
Figure 173. Data management proposals panel
Define a new data management proposal by clicking on the New button. The proposal definition dialog box will open, as shown in Figure 174 on page 249.
248
Figure 174. Data management proposal definition
Enter a new proposal name. In this example, it is aix_Windows2000Prop. Select the Encapsulation Security Payload (ESP) protocol and define a new transform algorithm by clicking on the New button. The Transforms Properties definition dialog box will be opened, as shown in Figure 175 on page 250.
249
Figure 175. Transforms properties definition dialog
Select DES for the ESP encryption algorithm and HMAC MD5 for the ESP authentication algorithm. The Encapsulation mode is Transport and takes the Key lifetime default values. Finish the transform properties definition by clicking on the OK button. A new entry for ESP transform is made in the proposal definition dialog box, as shown in Figure 176 on page 251.
250
Figure 176. Data management proposal panel after proposal definition
Finish the data management proposal definition by clicking on the OK button. A new proposal entry (aix_windows2000Prop) is made in the data management policy dialog box, as shown in Figure 177 on page 252.
251
Figure 177. Data management proposals panel after new proposal definition
Select the new proposal definition and associate your policy definition with this proposal by clicking on the <-- button. By clicking on the OK button, you finish the Data management policy definition. A new data management policy entry (aix_windows2000Pol) is made in the Data management tunnel definition dialog box, as shown in Figure 178 on page 253.
252
Figure 178. Data management policies after new policy definition
Select the new data management policy and associate it with your data management tunnel definition by clicking on the Associate button. Open the Options panel and do not check the Automatic data management, because the AIX server is the responder of the IPSEC tunnel and the IPSEc client opens the secure channel to the IPSEC server (Figure 179 on page 254).
253
Figure 179. Data management options
Clicking on the OK button finishes the data management tunnel definition. The complete IP security tunnel is configured on the AIX server. In the Key management dialog box, you can see an entry for the defined key management tunnel and the data management tunnel, as shown in Figure 180.
Figure 180. Internet Key Management Application after key tunnel definition
5.6.2.2 Configuration of IPSEC client on Windows 2000 The configuration steps for the IP security functions of the Windows 2000 client are similar to the descriptions in Section 5.6.1.1, IPSec server configuration on page 210 and Section 5.6.1.2, IPSec client configuration on page 228. Insert the AIX server IP-Address for the tunnel endpoint. 5.6.2.3 Activation and testing of the VPN connection The VPN connection will be automatically activated through any IP traffic from Windows 2000 IPSEC client to the AIX IPSEC server. You can test it by
254
pinging from client to server. We used the Ethereal Sniffer to sniff the packets to verify the security of the packets. With the Windows 2000 ipsecmon program, you can view the user-established VPN connection, as well as the related statistics.
5.6.3 Firewall configuration rule

In this section, we will demonstrate the firewall configuration for the previously mentioned scenario to work. We will be demonstrating through the SecureWay firewall, but it could be implemented on practically any firewall available in the market. As we can observe from Figure 154 on page 230, the first process to be initiated by the IPSec client is the key negotiation using Internet Key Exchange (IKE) protocol. IKE operates on UDP port 500. After the key negotiation, traffic from the client to the server is transmitted using the ESP. There are two rules that have to be built on the firewall for the VPN to function through the firewall. The first rule would be to allow IKE negotiation (IKE on UDP 500). To achieve this, select rules from the SecureWay firewall main menu and select New from the Rules panel, Now you need to define a rule, as shown in Figure 181 on page 256.
255
Figure 181. Define the rule for IKE communication
Now you select OK to come back to the rules panel. We have achieved the first objective of allowing key negotiation through the firewall. ESP is the protocol which we will be using to encrypt the data between the client and NetView (AIX) server. Thus, we will achieve a transport mode VPN. For this communication, the next step would be to create a rule to allow traffic
256
on ESP protocol. To do this task, select New from the Rules panel and create another rule, as shown in Figure 182.
Figure 182. Define the rule for ESP communication
Now we have created the rules required for the VPN communication.
257
The next step would be to create a service which will include the rules just defined. To do this task, select Connection Templates->Services. Select New to create a new service and define it, as shown in Figure 183.
Figure 183. Define the service for VPN rules
Now select OK to come back to the services menu. Select Close to come back to the main menu.
258
The next step would to create a connection with the rules and the service just created. To do this task, select Connection Setup from the main menu and select New to create a new connection. Define the connection, as shown in the Figure 184.
Figure 184. Define the connection for the VPN
The source object is the remote client identification. In our case, we have named it DMZ, but it could be anything, according to the requirement.
259
Now we have created all the required rules, service, and connection required for the VPN. You will need to regenerate the rules. Now you can observe that you can communicate from the remote client securely through the firewall. In our case, we now have a NetView Java client on our Windows 2000 machine connected to an AIX NetView server with a firewall between them. Table 26 gives a brief summary of the connections, services, and rules required for the VPN.
Table 26. Firewall rule for VPN client/server connection
Function IKE negotiation
Source Remote Client Remote Client Remote Client
Destination NetView in Secure Network NetView in Secure Network NetView in Secure Network
Protocol UDP
SrcPort 500
DestPort 500
ESP
ESP
Connection for the VPN
UDP & ESP
500 & 0
500 & 0
260
Chapter 6. Network management in the DMZ

In the last three chapters, we explored the various technologies and challenges that arise when managing networks across a firewall. In this chapter, we will take a closer look at some of the major issues and concerns that corporations today have in managing their enterprise. Specifically, we need to understand the requirements that businesses today demand from their network and external Internet Service Providers (ISP). This is of particular importance when a fundamental component of their business is their e-business. We will look at the most typical form of an enterprises e-business high level architecture in respect to their internal corporate network, discuss a solution that manages the whole network environment, and compare other potential solutions. Inevitably, we will encompass many of the areas we have discussed in previous chapters and apply them to the corporate network environment.
6.1 The eBusiness architecture

The eBusiness environment that we are discussing involves an architecture that includes at least one DMZ, where some or all Internet related services are located, as well as multiple ISP connections. We will use the following basic model shown in Figure 185 on page 262 as a basis for our discussions on network management solutions in eBusiness environments. We will define our most preferred model (best practice) for NM as the Prime Network Management Model or PNM for reference purposes. This is shown in Figure 186 on page 265. The Prime Model in Figure 185 on page 262 shows basically three zones that we need to manage. Let us define these different areas before describing the different management solutions.
6.1.1 The corporate network

The corporate network, as the name suggests, encompasses all corporate network resources. These include all client workstations, servers, routers, and switches. The corporate network is managed by the network and systems management systems that have been described in Chapter 4, Management in distributed environments on page 101. From the Prime Model, we can see the Corporate NetView server, Tivoli Enterprise Console receiving events from corporate devices, the Tivoli Management Region, and Tivoli Decision Support servers.
261
Figure 185. The Prime Model
6.1.2 DMZ
The Demilitarized Zone (DMZ), as we have previously discussed, is located between the corporate internal firewall and the external Internet firewall. It is essentially a quarantine area for network traffic, often from both the Internet and the corporate network. In the eBusiness environment, traffic such as
262
HTTP and FTP can pose harmful security holes to the corporate network, the Internet firewall is used as the first perimeter of protection and control. The Internet firewall is the most vulnerable to security attacks, as it needs to allow enough access to the Internet so the eBusiness can provide its services. At the same time, it should be the first point of traffic control and barrier to malicious attacks. The Internet firewall is typically connected to an exterior multi-interface router that connects to single or multiple ISPs. Large eBusinesses today use multiple ISPs for redundancy purposes, and the exterior router can be configured to fail over to a possible n-number of backup ISPs links (see Figure 185 on page 262). Should one ISP fail to provide a service, the router automatically activates the next backup link. A redundant exterior router could also be deployed for failover purposes; however, while the possibility for router attacks exist, they have not posed major threat to eBusiness environments. Most IT funds would most likely be better spent on internal technologies, such as firewalls, proxy servers, and good security management.
Note
The Internet firewall is a single point of failure for the eBusiness, so new solutions are now available to create a redundant firewall infrastructure. IBM WebSphere Edge Server (previously known as eNetwork Dispatcher) allows you to load balance incoming network traffic to multiple firewalls, as well as giving you the ability to failover to a standby Edge Server. This not only allows redundancy in the firewall structure, but also greatly increases the performance of eBusiness. For more information, see:
http://www-4.ibm.com/software/network/dispatcher/
The DMZ will contain all of your eService servers (labelled eServers in Figure 185 on page 262) that provide a service to the Internet. This will include services such as: HTTP Web servers Proxy servers Socks servers SMTP mail servers Database servers Component Object Request Broker or Merchant servers
263
The importance of effectively managing these services within the DMZ and the availability of these services to the Internet without compromising on corporate security poses a major challenge to network management architects. We will explore potential solutions in Section 6.2, eBusiness network management architecture on page 264.
6.1.3 The Internet

The Internet, in this context, includes the ISPs that connect us to the Internet. As we mentioned, a number of ISPs may be contracted to provide Internet access services. Normally, these links are pooled together to form a combined pipe to the Internet (configured at the exterior router). From the users in the corporation, access to the Internet is transparent, as traffic is load-shared across the whole pool of Internet bandwidth. From the viewpoint of managing Service Delivery Agreements (SLAs), the exterior router should be configured to log or send alarms to the DMZ NM systems whenever a link or circuit to an ISP becomes dysfunctional and SLA reporting can be performed. A primary concern when managing access to the Internet is end-to-end connectivity to the Internet. A total loss of connectivity would have a crippling impact on the eBusiness. We will look at a method of managing this aspect of the DMZ.
6.2 eBusiness network management architecture

We have considered the basic components of the eBusiness infrastructure. In this section, we discuss what we earlier defined as the PNM. The model has been designed to meet the requirements of both effective network management and corporate security policies. Figure 186 on page 265 shows the PNM. One of our main assumptions with the eBusiness network is that it is a dynamic network environment that will grow into a substantially larger network of servers and devices. Other variations to this architecture are possible, and we will compare some of the main advantages and disadvantages of these architectures. Another assumption we make here is that the highest possible security is a priority in the network infrastructure, which influences the decisions we make in regards to our primary solution.
264
Figure 186. The Primary Network Management model (PNM)
The solution shown in Figure 186 shows the DMZ NetView as the manager of the DMZ components and Internet access. DMZ NetView is used to perform the following functions.
265
6.2.1 Discovery and configuration polling

The DMZ NetView will only auto-discover the DMZ network. When new devices, servers, and infrastructure devices are added to the DMZ, these will be automatically added to the NetView object database and managed accordingly. By using the Agent Policy Manager, we can even create self-managed Smartsets that group specific types of devices together, in which policies, such as data collecting, can be performed. The discovery process of NetView uses SNMP to obtain ARP cache information from known nodes. It then adds nodes from newly discovered ARP entries, as shown in Figure 187.
Figure 187. DMZ discovery and configuration polling
It is assumed that, in some cases, both the internal and Internet firewalls do not allow SNMP or ICMP requests and responses from the DMZ, no automatic discovery is possible outside of the DMZ.
266
Can we manage Internet devices?
While automatic discovery will not be permitted outside the DMZ, ICMP is usually permitted from the DMZ to the Internet. This is often the case, as IT departments need to monitor their connectivity to the Internet or other various servers abroad. Nodes on the Internet, such as routers, can be manually added to the DMZ NetView, and their status can be monitored this way. We will discuss more Internet management scenarios later.
Configuration polling can be configured to check and update NetViews object database for any changes in the network devices. As it is assumed that the DMZ environment in a growing eBusiness would change often, configuration polls allow us to keep up to date with each of the servers, and device (especially when they are upgraded or replaced). Once again, the configuration poll period can be reduced in order to frequently update the object database. While the default configuration poll period is every 24 hours, this can be reduced to 12 or 6 hours, depending upon how many devices are in the DMZ. Server farms, for example, would host substantially larger numbers of network devices, so status and configuration polls need to be adjusted accordingly. 6.2.1.1 Status polling The DMZ NetView is expected to perform status polling on all eServers and network devices. In general, ICMP is allowed on selected DMZ devices such as NetView, so NetView would also be used to test the availability of the exterior router and its interfaces, and even the routers connecting the eBusiness to the various ISPs. You can also afford to increase the polling frequency of the network devices (such as every two minutes) to get quicker alerts on inoperative devices. This is because all the traffic is local to the DMZ NetView. Only the Internet firewalls would be managed by the DMZ NetView. This is due to our priority on security which implies that no SNMP or ping is allowed from the DMZ to the internal firewall. Even allowing the DMZ NetView to ping or SNMP to the internal firewall could potentially open a security hole for hackers to manipulate. If the DMZ NetView is hijacked in any way, then a connection that can be established to the internal firewall is highly undesirable. Besides, there is no benefit for the internal firewall to be managed by the DMZ NetView in this scenario, as it would have no passage to notify the internal corporate NetView management system. It suffices to say that the corporate NetView will manage the internal firewall.
267
6.2.2 Internet connectivity

Another function that can be implemented on the DMZ NetView is to monitor end-to-end network connectivity to the Internet. This could be achieved by adding a separate Location icon group at the top level of NetView s Map, such as the Internet Access, and polling known Web sites for real Internet connectivity status. Here are the steps that can be taken to achieve this task on Windows NT NetView (the procedure is essentially the same for AIX). The approach is to force NetView to associate a number of IP addresses as interfaces to one hostname. 1. Find three or four Internet IP address relating to known Web sites and add hostname entries for each IP address with hostname internet_access. A sample host file follows. Many Web servers will not be pingable, but you should be able to find three if you ping the servers of well-known companies.
#Sample Host File for Internet Access Management 216.140.178.15 internet_access # www.tivoli.com 203.199.70.40 internet_access # in.yahoo.com 198.3.103.205 internet_access # www.excite.co.uk
2. Navigate to the IP Network submap, as shown in Figure 188 on page 269.
268
Figure 188. NetView IP Internet submap
3. Select Object->New to create a new object (see Figure 189). 4. Select Location from the Type drop-down box.
Figure 189. Object creation
5. Select the City icon and click Next. The dialog box shown in Figure 190 on page 270 will appear.
269
Figure 190. Internet Access object group properties
6. Enter the Object Name Internet Access and Description. 7. Click OK and the Internet Access Location will be created on the IP Internet submap, as shown in Figure 191 on page 271.
270
Figure 191. Internet Access group
8. We will now use the NetView loadhosts command to add the interfaces associated with the internet_access host that we entered in the /etc/hosts file. (Follow the command listing in the next screen). We will use this command to add all associated interfaces. NetView will automatically place a node and associate the interfaces to the same node because of the host file entries. The command loadhosts accepts the ipaddress and hostname as stdin. The format we use for loadhosts is:
echo IPaddress hostname | loadhosts -v -m mask
271
C:\>echo 203.199.70.40 internet_access |loadhosts -v -m 255.255.255.0 Created host internet_access(401) Added interface 203.199.70.40(402) to internet_access 1 nodes added to database 1 interfaces added C:\>echo 216.140.178.15 internet_access |loadhosts -v -m 255.255.255.0 Added interface 216.140.178.15(413) to internet_access 0 nodes added to database 1 interfaces added C:\>echo 192.3.103.205 internet_access |loadhosts -v -m 255.255.255.0 Added interface 192.3.103.205(416) to internet_access 0 nodes added to database 1 interfaces added
Note
The IP addresses and hostnames match what was previously entered in the hosts file (\winnt\system32\drivers\etc\hosts for Windows NT and \etc\hosts for AIX). For AIX, the command is the same, but the loadhosts command allows you to enter multiple addresses at one time, as shown in the next screen.
root@itso8 > loadhosts -m 255.255.255.0 << EOF > 203.199.40.70 internet_access > 204.198.40.60 internet_access > 202.192.50.39 internet_access > EOF 1 nodes added to database 3 interfaces added root@itso8 >
The NetView map should like the one shown in Figure 192 on page 273.
272
Figure 192. Internet map after loadhosts command executed
Select the internet_access object and all surrounding network icons (by drawing a selection box around all these icons), select Edit->Cut , and click OK. 9. Double-click on the Internet Access location and select Edit->Paste to paste the object. See Figure 193 on page 274.
273
Figure 193. Relocating Internet networks to the Internet Access submap
10. The attached networks would initially be unmanaged. Select the networks and select Object->Manage. 11. The Internet host is now managed and you will now receive appropriate node down and interface down alerts corresponding to the different Internet hosts. However, all alerts will be associated with the internet_access hostname, so we can create scripts or rules to take action upon these events. If necessary, you may wish to relabel each of the networks appropriately. To do this, right-click on a network and select Object Properties. Click on the General tab, as shown in Figure 194 on page 275.
274
Figure 194. Changing symbol properties
12. Change the Object and label fields to the appropriate Internet host and click OK. 13. Repeat steps 10 through 12 for all networks. The Internet Access map will now reflect more information about the Internet connections we are actually monitoring. This will aid in troubleshooting, as you can visually see which hosts are down, as shown in Figure 195 on page 276.
275
Figure 195. Internet management submap
We have now forced NetView to create an Internet node with multiple interfaces, each representing a different Internet location. NetView will treat this host as a normal node with multiple interfaces. Logically, however, when an interface is uncontactable, the corresponding NetView Interface Down event received for the internet_access host would reflect the loss in connectivity to the corresponding network associated with that interface. If one or more interfaces become uncontactable, the internet_access node will turn yellow, indicating that either one or more Internet hosts are uncontactable. However, if all interfaces become uncontactable, then the corresponding NetView Node Down event will indicate that total access to the Internet is disabled. In addition to this event being triggered, the internet_access node will turn red in color, as shown in Figure 196 on page 277. Sample event traps are shown in an event browser in Figure 197 on page 277.
276
Figure 196. Internet Access disabled
Figure 197. Sample Internet connectivity events
277
As certain specified events are forwarded to the corporate enterprise console (such as TEC), a rule can be implemented to signal a major alarm in response to this event (see Figure 199 on page 281). This concept can also be used to monitor the corporations Internet Service Level Agreements (SLAs) from their service providers. For example, a node containing interfaces for each of the ISPs routers could be created inside an ISP submap. Depending upon the propagation configuration for that node or the ISP submap, you could see the different levels of Internet access service being provided to the eBusiness.
6.2.3 Forwarding traps

To forward traps to the corporate NetView from the DMZ NetView, you would need to use the following procedures. 6.2.3.1 Windows NT NetView for Windows NT uses a daemon to forward traps to other management stations. The daemon trapfrwd is not started by default and needs to be registered. Here are the main steps to start and configure trapfrwd. 1. At the command line, change the directory to \usr\OV\lrf and run ovaddobj trapfwrd.lrf, as shown below. This registers the daemon to start automatically.
C:\usr\ov\lrf>ovaddobj trapfrwd.lrf Static Registration Utility Successful Completion C:\usr\ov\lrf>
2. Next, you need to find out which traps you wish to forward. The trapfrwd daemon can be configured to forward all traps from a particular enterprise OID. By default, it forwards all NetView traps. To find out the enterprise for Cisco traps, for example, select Options->Trap Settings . The dialog box shown in Figure 198 on page 279 shows all traps that are configured for NetView to interpret. Scroll down the top window and select the required enterprise. The OID is shown in the second column (Cisco is, for example 1.3.6.1.4.1.9).
278
Figure 198. Trap settings for NetView NT
3. Once you know which OIDs you want to forward traps from, open the file \usr\OV\conf\trapfwrd.conf. Enter the destination host name and port number to send traps to in the [Hosts] section, and the OID to trap number pairs in the [Traps] section. An * implies all traps for that OID. Here is a sample below that includes all traps for Cisco devices.
[Hosts] localhost 1662 #The corporate NetView server corp_NetView 162 [End Hosts] [Traps] #All NetView Traps 1.3.6.1.4.1.2.6.3 * #All Cisco traps 1.3.6.1.4.1.9 * [End Traps]
279
4. Save the file and run ovstart trapfwrd at the command line to start the daemon.
280
Figure 199. Internet Access management
281
6.2.3.2 AIX We have described the procedure for forwarding traps. Please refer to Section 4.5.1, Forwarding events to TEC with NetView nvserverd daemon on page 125. MLMs can also be used to forward traps to NetView and can be installed on the same machine as the NetView server. See the note in Section 6.3.1.2, Alternative 2 on page 293. 6.2.3.3 Exterior router performance management Performance management of network devices such as routers is a challenge in the DMZ environment, and is mostly restricted to the DMZ. Due to the security constraints that are a priority in such an environment, there is little room for the network administrator to allow protocols such as SNMP to manage the devices outside the Internet firewall directly. We may need to rely on more indirect methods of obtaining performance statistics. These can be in the form of threshold traps, which can be collected at the DMZ NetView and forwarded on to the corporate NetView. Obtaining real time graphs of the router traffic may not be possible by direct SNMP; however, we can poll the Internet Firewalls SNMP Daemon for MIB-II interface traffic variables, such as: ifInOctets/IfOutOctets ifInErrors/ifOutErrors ifInDiscards/ifOutDiscards See Figure 200 on page 283 for more details.
Note
Statistics from the Internet firewall will most likely not reflect the true traffic load on the exterior router(s), as this traffic only represents unblocked traffic coming in and out of the firewall. The firewall installation installs an extra layer in the TCP/IP stack that intercepts the packet before it even reaches the application layer where SNMP resides, and thus the packet will not register in the MIB-II statistics information. You may need to gather statistics on the number of firewall blocks on inbound and outbound traffic along with SNMP MIB-II statistics to produce a better understanding of the router load. Alternatively, you may allow SNMP access to the exterior router from an external trusted source, such as your ISP, who may be contracted to manage the router for you. Even better, you obtain management statistics from your ISP on their router that connects to your DMZ (which reduces the load on the exterior router).
282
Figure 200. Performance management of exterior router without SNMP access
Again, the balance between security and functionality needs to be addressed. In a large number of environments, the firewall security policy for the Internet firewall may be more flexible than the interior firewall, so such protocols as SNMP may in fact be permitted from the DMZ NetView to the exterior router. If this is the case, then the security policy should at least enforce that only the DMZ NetView is permitted to send SNMP requests, and only to the LAN
283
interface of the exterior router. This limits the possibility of any entities outside our managed environment (past the exterior router) from hijacking any packets back into the DMZ. The access control lists (ACL) on the router can be configured to allow this policy. If SNMP is allowed to the exterior router, then performance management of the Internet passageway can be more easily achieved while still maintaining a reasonable degree of security (see Figure 201 on page 285).
284
Figure 201. Performance management of exterior router with SNMP access
In fact, in the case where multiple ISPs are attached to the exterior router, the traffic performance can be gauged and reported upon, because the MIB-II table provides information on all interfaces (even though the serial interfaces are unreachable via SNMP). Figure 202 on page 286 shows a sample report that shows the serial interface throughput for two serial lines (each reflecting one ISP connection).
285
Figure 202. Sample router MIB-II report showing serial interface throughput
In NetView, the data collections themselves can also be configured to test if any link exceeds a certain threshold, and send a trap upon the occurrence of the event. These traps can be sent to the corporate TEC via the corporate NetView, as shown in Figure 201 on page 285. 6.2.3.4 Server network performance management Managing the network traffic of your servers (including the external firewall) will require the standard polling of MIB-II interface statistics that we have mentioned in the previous section. Data obtained can be used to establish a baseline for the amount of traffic that individual servers process and allow you to plan for future capacity requirements, such as increasing network card speeds, hubs and internal routers and switches.
6.2.4 Tivoli Decision Support

Tivoli Decision Support requires access to the data collection data from NetView servers. If you wish to deploy TDS to report on data from the whole environment (including the DMZ), then the challenge here is to allow the TDS server (which resides in the corporate network) to create a secure database connection to the DMZ NetView. Again, a secure connection is necessary,
286
because security is an absolute priority in the internal firewall. One possible solution would be create an encrypted tunnel in the form of a VPN or SSH, as we described in Chapter 4, Management in distributed environments on page 101, between the DMZ NetView and the TDS host. The TDS would act as the client in both cases and the DMZ NetView would be the server. By creating an encrypted tunnel, attacks from outside the DMZ NetView would require the client encryption key to decipher any transported data (see Figure 203).
Figure 203. Tivoli Decision Support for the enterprise
287
6.3 Consolidating enterprise network management

Ultimately, the network managers and support teams in the enterprise would want to manage the whole enterprise seamlessly from one location. Since most, if not all, these teams would be located on the corporate network, primarily using the corporate NetView, we need to integrate the two systems to allow us to get an end-to-end enterprise view of management. Our approach is to enable secure connections, such as VPN or SSH, as explained in Chapter 5, Network management through the VPN on page 163. See Figure 204 on page 289 for more details.
288
Figure 204. VPN for secure communications
This will allow us to use all the functionality of the DMZ NetView to manage the DMZ while not jeopardizing our security between the corporate network and the DMZ. SSH, however, as we have experienced, is limited in that it can only forward single ports at a time, and therefore cannot be used to tunnel protocols such as FTP or the NetView Java Client (which require ranges of ports). SSH could be used if you only required telnet from the corporate
289
NetView to the DMZ NetView, in which case you could open an X-Windows session to manage the DMZ NetView. The more practical solution would be to use an IPSec gateway solution similar to that described in Section 5.5, Client to site VPN on page 178. The IPSec client will reside on the DMZ NetView, and the IPSec gateways will reside on both the corporate NetView and the TDS Server. The tunnel will be between DMZ NetView and both corporate NetView and TDS. This way, all protocols can be tunnelled securely across only one single port, as we have described in the Section 5.5, Client to site VPN on page 178, with minimal administrative overhead. This would also include traps, FTP and Telnet. The NetView Java Client can also be used through the VPN tunnel, which provides better performance compared to SSH-tunnelled X-Windows graphics (see Figure 204 on page 289). The gateways should be placed in the corporate network so only specified DMZ clients can initiate the VPN tunnel. Note that the two VPN tunnels will still only require one port on the internal firewall for all VPN tunnel communications, even though they will each own a separate VPN Tunnel ID. We have provided VPN solutions for Windows 2000 to Windows 2000 and AIX to Windows 2000 starting in Section 5.6, VPN client/server configuration on page 209. Also, the redbook A Comprehensive Guide to Virtual Private Networks, Volume III: Cross-Platform Key and Policy Management, SG24-5309 includes information for AIX to AIX VPNs. As a majority of NetView implementations are deployed on AIX and Windows technology, this information can be used on any combination of these NetView operating system platforms that exist in the environment. Other VPN solutions (though not documented in this redbook) are also available for other flavors of UNIX, such as HP-UX and Sun Solaris.
290
Note
While we have shown (in this solution) that traps from the DMZ NetView can be forwarded securely to the corporate NetView, this process will depend upon your overall strategy for enterprise systems management. If different teams rely on the corporate NetView to view events coming from the DMZ and corporate network (while system management groups view overall enterprise events at the TEC), then this solution would be appropriate. However, if TEC is the main event management facility for both network- and system-wide events, then consider sending events from the DMZ NetView straight to TEC. NetView for UNIX would use the nvserverd daemon while NetView NT would use the NetView event adapter for TEC. Note also that if you are using the nvserverd daemon, you can specify which destination port that NetView will always use to communicate via TCP to TEC, and tunnel these events through SSH. This is a good option if you do not want to maintain a VPN, as shown in Figure 205 on page 292. Refer to Section 4.5.1.1, TEC reception port restriction on page 130 for further details. Without using VPN, other functions for remote access to the DMZ NetView, such as telnet and ftp, can also use SSH tunnelling.
291
Figure 205. Sending DMZ events directly to TEC
6.3.1 Alternative solutions

While there are no hard and fast rules in network management, we have chosen the PNM as our recommended solution because it allows the maximum amount of functionality while adhering to security management guidelines. However, as issues and concerns for network management in each environment will be different, a flexible approach to the architecture is essential. We will examine a number of alternative solutions and discuss the advantages and disadvantages of each when compared with the PNM. 6.3.1.1 Alternative 1 The first alternative is to use no additional network management components within the DMZ itself, and rely completely upon the corporate NetView to manage the DMZ, the Internet connection, and reception of all traps from the DMZ, as shown in Figure 185 on page 262. This is the simplest solution and has some advantages. It is simple in that you only need to open the internal firewall ports required for SNMP Trap reception, SNMP GET and SET requests, and ICMP polling. You
292
could also use SNMP Status polling instead of ICMP to increase security further (refer to Section 3.4.2, Polling using SNMP on page 70). Costs are kept to a minimum, as you do not need to spend additional resources for hardware and software on a new server, and administration would also be kept to a minimum, since the DMZ will only occupy another network submap on the corporate NetView. For small DMZ environments, where costs may be an issue and security may not be high on the list of priorities, this could be a possible solution to implement. However, from a security point of view, it certainly is not the ideal solution, as you will inevitably face a number of security policy issues with the corporation. Telnet, for example, would be a necessary protocol for managing routers and servers in the environment, and unless it is possible to implement secure shell connections with all servers and routers; this would be a major security violation in the DMZ and would not likely be permitted. Protocols such as ICMP, SNMP, and Telnet, as we have mentioned, are unsecure, and because there is no other means of transporting this type of traffic in this architecture, security would be greatly compromised. 6.3.1.2 Alternative 2 The second alternative is to place a NetView Mid-Level Manager to manage the DMZ. This MLM can be configured to discover and monitor all nodes within the DMZ and to perform all data collection duties that we have described for the PNM solution. The MLM can receive all traps from nodes within the DMZ and forward them to the corporate NetView, which in turn can forward them to TEC. See Figure 206 on page 295.
Note
As the default transport method for trap destinations is TCP, it would be advisable to change this to UDP, as this only requires port 162 (or configured otherwise) from the MLM to the corporate NetView. This would be good if using SSH, which supports a single port, but TCP guarantees delivery. MLMs will queue traps being delivered by TCP if the connection is broken. The advantage here is that we will get a single view of the network from one NetView server, as the MLM will be viewed as part of the corporate NetView s network. Costs are minimized, because the MLM software does not require a large amount of system resources. Remote configuration of the MLM, however, will be an issue, as the SNMP port 161 would need to be opened on the internal firewall (unless the remote port is changed) and hence security is compromised. Again, the secure shell or VPN solution can make the difference here. Using VPN, all network management protocols can easily
293
traverse between the corporate NetView and the MLM and vice versa. (Secure shell could be used to port forward X-Windows, and the local MLM configuration tool could be used, but this would restrict communications to only X-Windows). A script could also be written to duplicate the Internet connectivity management solution that was previously described in Section 6.2.2, Internet connectivity on page 268. This script can be periodically executed using a scheduler, such as cron on AIX or AT scheduler on Windows NT, and configured to send traps to the corporate NetView when, for example, total Internet connectivity ceases. The downside to this solution is that the MLM does not provide the configuration polling function. Due to this limitation, we would either need to open an SNMP UDP port on the internal firewall to allow the corporate NetView to poll all nodes in the DMZ, or not have the configuration polling function for the DMZ. Opening SNMP to all nodes could seriously compromise corporate network security. Depending on how fast your network grows, and how accurate the SNMP general information about network devices are, this may or may not pose a problem. If availability polling and performance management are the main concerns for network management, and your DMZ architecture is relatively simple, then the MLM solution could be a reasonable alternative.
294
Figure 206. Alternative Solution 2 - DMZ MLM
295
Note
MLMs are especially useful in filtering large amounts of trap data and forwarding only relevant traps to the Primary NetView server, as shown in Figure 206 on page 295. Consider using MLM on the same machine as the DMZ NetView and configuring it to filter out unwanted traps and forwarding relevant traps back to the DMZ NetView. This method can be used to improve the performance of the NetView application itself, as the MLM application is very efficient in trap filtration and can block unwanted trap storms from the environment. The DMZ NetView will still be used for all polling functions, and the DMZ MLM will only be configured to filter traps. No polling will be distributed to the MLM itself. See Figure 207.
Figure 207. Using MLM under NetView to filter traps
6.4 Conclusion
Network management in a secure network environment poses many challenges. Throughout this chapter, we have discussed the primary solution for managing a DMZ environment that we believe to be the most relevant and practical for managing eBusiness and DMZ environments today. We have focused upon a number of security areas that influence how we design our management solution and some of the network management and security concerns that need to be addressed. Alternative solutions were also presented and compared to show that network management solutions need
296
not be fixed to one architecture, but a more flexible and practical approach can achieve more effective management for the specific network environment at hand. Different corporations and different networks require different degrees of security and management, and only by understanding the overall network and business requirements can we hope to design a better solution for today s eBusiness.
297
298
Part 3. Additional information
299
Appendix A. IBM SecureWay Firewall installation

This appendix describes the process for installing IBM SecureWay Firewall on the Windows NT Platform.
A.1 Prerequisites
The installation server requires the following: 128 MB RAM. 300 MB disk space. A Pentium Processor. At least two network adapters, which are supported by the SecureWay product (refer to http://www.ibm.com/security for more information). The general guideline is to use IBM/Intel and NE2000 compatible network cards. Windows NT 4.0 Server version with SP3 or above. Refer to the SecureWay product manuals for further information.
A.2 Installation
The following steps describe the installation process. 1. Open the Control Panel->Networking configuration and double-click on TCP/IP Properties in the Protocols tab. 2. Click on the Routing Tab and select the Enable IP Forwarding option, as shown in Figure 208 on page 302. Click OK.
301
Figure 208. Enable IP forwarding
3. Install an additional driver for SecureWay. Select the Protocol Tab and click Add (see Figure 209).
Figure 209. Installing IBM Intermediate Support Driver
4. Select Have Disk, and you will see the panel shown in Figure 210 on page 303.
302
Figure 210. Insert disk for Support Driver
5. Enter the proper path, as shown in Figure 210. Click OK to see the dialog box shown in Figure 211.
Figure 211. Select IBM Intermediate Support Driver
6. Select the IBM Intermediate Support Driver, as shown in Figure 211. Click OK. The driver should be installed, as shown in Figure 212 on page 304.
303
Figure 212. IBM Intermediate Support Driver installed
7. Click Close and select Yes to reboot the server. 8. Run the CD-ROM:/nt40/en_US/setup.exe. Click Next in the dialog box shown in Figure 213.
Figure 213. SecureWay Welcome
9. Select IBM SecureWay Firewall only (unless you require Netscape) in the panel shown in Figure 214 on page 305. Click Next.
304
Figure 214. Select components
10. Read the License Agreement and click Accept, as shown in Figure 215.
Figure 215. License agreement
305
11. Select the components (all recommended), as shown in Figure 216. You may choose to install the firewall in a different location by clicking Browse and selecting the directory. Click Next.
Figure 216. Installation options
12. In the summary shown in Figure 217 on page 307, verify the settings and click Next. SecureWay will begin installing, as shown in Figure 218 on page 308.
306
Figure 217. Confirm settings
307
Figure 218. Setup in progress
13. When the system has finished the setup process, it will ask you to harden the system. Click Yes, as shown in Figure 219. Note that all existing network connections will be disabled.
Figure 219. Hardening the system
14. A summary of the installation is shown in Figure 220 on page 309. Click Next.
308
Figure 220. Installation summary
The basic firewall installation is now complete. You should verify that the seven IBM Firewall services are running by selecting Control Panel->Services or running net start at the command line.
309
310
Appendix B. Check Point 2000 enterprise suite with Firewall-1 4.1

This appendix describes the process for installing Check Point FireWall-1 Version 4.1
B.1 Prerequisites
The installation server requires the following: Intel Pentium II 300+ or equivalent 64 MB minimum, 128 MB RAM recommended 40 MB disk space At least two network adapters. All interfaces should be supported by the operating system. Windows NT 4.0 Server version with SP4 or above
B.2 Installation
The following steps describe the installation process: 1. Insert the installation CD-ROM of Check Point 2000 Enterprise Suite into your CD-ROM drive. The installation procedure will be started automatically. Click Next in the dialog box, as shown in Figure 221 on page 312.
311
Figure 221. Check Point 2000 welcome
2. Read the License Agreement and click Yes, as shown in Figure 222.
Figure 222. Check Point 2000 license agreement
312
3. Select the SERVER/GATEWAY COMPONENTS, as shown in Figure 223, to install the firewall server software. Click Next.
Figure 223. Check Point 2000 product menu
4. Select the Server/Gateway components you want to install, as shown in Figure 224 on page 314. In this case, we chose VPN-1/Firewall-1 and the reporting module.
313
Figure 224. Server/Gateway components selection
5. Select the firewall setup type, as shown in Figure 225 on page 315. We selected the stand alone installation. If you want to install a distributed firewall system on different machines, chose the distributed installation.
314
Figure 225. Setup type
6. Select the gateway/server module you want to install (see Figure 226).
Figure 226. Gateway/Server module
315
7. We installed without backward compatibility, as shown in Figure 227.
Figure 227. Backward compatibility screen
8. Chose the installation directory for firewall modules, as shown in Figure 228 on page 317. Click Next and the firewall modules will be installed.
316
Figure 228. Destination location for firewall modules
9. Chose the installation directory for the management clients, as shown in Figure 229.
Figure 229. Destination location for management client
317
10. Select the management clients you want to install, as shown in Figure 230. After clicking on Next, the installation of the management clients will be started.
Figure 230. Management client dialog
11. Chose the installation directory for the reporting server (Figure 231 on page 319).
318
Figure 231. Destination location for reporting server
12. Select the reporting server modules you want to install, as shown in Figure 232.
Figure 232. Reporting server modules
319
13. In the dialog box shown in Figure 233, you can configure your mail address for automatic message sending to your account.
Figure 233. Reporting server mail settings
14. Enter the Web server address where you want to store the reports, as shown in Figure 234 on page 321. After clicking on Next, the installation of the server will be started.
320
Figure 234. Web server settings of reporting server
15. Chose the installation directory for the reporting client, as shown in Figure 235.
Figure 235. Destination location for reporting client
321
16. Select the reporting client modules you want to install, as shown in Figure 236. After clicking on Next, the installation of the reporting client will be started.
Figure 236. Reporting client modules
17. Click Add to install the Check Point license key (Figure 237 on page 323).
322
Figure 237. Firewall license installation
18. Configure, at minimum, one administrator (user name and password) by clicking on Add, as shown in Figure 238 on page 324. After clicking on Next, the installation of the server will be started.
323
Figure 238. Administrators dialog
19. Enter your firewall IP-Address, as shown in Figure 239.
Figure 239. Firewall IP-Address
324
20. Now you can configure the remote GUI clients that are permitted to access to the firewall system by clicking on Add, as shown in Figure 240.
Figure 240. Configuration of GUI clients
21. Select the Control IP Forwarding option, as shown in Figure 241 on page 326.
325
Figure 241. IP Forwarding dialog
22. Enter a random key string for the firewall cryptographic processes, as shown in Figure 242 on page 327.
326
Figure 242. Key Hit session
23. The installation is finished after rebooting your firewall server. Select Yes for rebooting, as shown in Figure 243 on page 328.
327
Figure 243. Setup complete
328
Appendix C. Installing Check Point SecuRemote VPN client

This appendix discusses the steps required to install the SecuRemote client.
C.1 Prerequisites for SecuRemote client

The prerequisites for the SecuRemote client are: Pentium class processor At least 64 MB RAM (128 MB Recommended). 30 to 50 MB of hard disk space
C.2 Locating and installing the SecuRemote client

SecuRemote client is a IPSec based client software provided by Check Point to facilitate a secure communication to a VPN-1 gateway.You can locate and install it by following these steps: 1. Download the client from the Check Point Web site ( www.checkpoint.com) and choose the version you want. We set up the SecuRemote client on a Windows 2000 system. Once you download the client software, you need to execute the setup utility, which will bring up the panel shown in Figure 244 on page 330.
329
Figure 244. SecuRemote Installation Welcome panel
2. Select Next after reading the legal information and warnings. You will see the panel shown in Figure 245.
Figure 245. SecuRemote license agreement
330
3. Select Yes in the license panel, and you will see the panel shown in Figure 246 or Figure 247 on page 332. You will see the panel shown in Figure 246 if an existing version of SecuRemote is found; otherwise, this panel will not be displayed. If you choose to overwrite, the next panel will be as shown, as in Figure 247 on page 332.
Figure 246. Existing version dialog box
We chose to overwrite and then selected Next. The panel in Figure 247 on page 332 will appear.
331
Figure 247. SecuRemote installation directory
4. The next dialog box will ask you to choose the destination directory. Choose the appropriate directory for the installation. Once you do this, you will see the panel shown in Figure 248.
Figure 248. SecuRemote Desktop Security
332
5. The dialog box will give the user an option to enforce desktop security at the client end. This will also enable the client to obtain a policy from the Check Point Policy server. Once you choose to install desktop support and select Next, you will see the panel shown in Figure 249.
Figure 249. SecuRemote Network Bindings
6. The Network Bindings dialog box allows the user to install the client on dial-up or all network adapters. This will determine what communication will be encrypted by the SecuRemote Client. Choose Install on all network adapters and select Next. You will be asked to restart your computer, as shown in Figure 250 on page 334.
333
Figure 250. SecuRemote setup complete
7. Select Yes on the dialog box shown in Figure 250 to finish the installation. This will restart your system.
334
Appendix D. Scripts
This appendix contains scripts that were used in this redbook.
D.1 IBM SecureWay Log Reporter

This section documents the Perl script used in Section 3.4.3.2, Reporting from the log file on page 73.
335
#***********************************FWLOGFIL********************************************** #This script filters the resulting f_match.tbl file from converting #IBM SecureWay logs using the fwlogtbl tool. It is used to filter denied #packets based on destination, destination, or both destination and destination, and #create an output report. #Syntax: fwlogfil.pl [-s source host/IPaddress] [-d destination host/IPaddress] reportfile #***************************************************************************************** #Verify valid parameters #This specifies where to look for the f_match.tbl file for input. $tbl_log_dir = "D:\\firewall\\log"; $raw_log_file = "$tbl_log_dir\\local4.log"; #$tbl_log_file = "$tbl_log_dir\\f_match.tbl"; $tbl_log_file = "f_match.tbl"; #Process the raw log file using "fwlogtbl" command; `fwlogtbl -w -d $tbl_log_dir $raw_log_file`; if ($ARGV[0] =~ /\-s/i){ $source = $ARGV[1]; if (!($source =~ /\d+\.\d+\.\d+\.\d+/)){ print "Source is invalid. Please enter a valid IP address.\n"; exit; } } elsif ($ARGV[0] =~ /\-d/i){ $destination = $ARGV[1]; if (!($destination =~ /\d+\.\d+\.\d+\.\d+/)){ print "Destination is invalid. Please enter a valid IP address.\n"; exit; } } elsif (!($ARGV[0] =~ /\w+/i)){ print "Syntax: fwlogfil [-s source host/IPaddress] [-d destination host/IPaddress] reportfile\n"; exit; }
336
if ($ARGV[2] =~ /\-d/i){ $destination = $ARGV[3]; if (!($destination =~ /\d+\.\d+\.\d+\.\d+/)){ print "Destination is invalid. Please enter a valid IP address.\n"; exit; } $outputfile = $ARGV[4]; if (!($outputfile =~ /\w+/)){ print "Output file is not valid. Please us a valid output file name.\n"; exit; } } elsif ($ARGV[2] =~ /\w+/i){ $outputfile = $ARGV[2]; if (!($outputfile =~ /\w+/)){ print "Output file is not valid. Please us a valid output file name.\n"; exit; } } #************************************************************************************* #Open f_match.tbl file for input open(MATCH, "$tbl_log_file")||die "Can't open $tbl_log_file ! \n"; open(OUT, ">$outputfile")||die "Can't open $outputfile! \n"; print "Processing log file $inputfile..\n"; print OUT "IBM SecureWay Firewall Block Report\n\n"; #Start reading log file input while(<MATCH>){ ($date, $host, $tmp1, $tmp2, $tmp3, $action, $direction, $src_ip, $dest_ip, $protocol, $src_port, $dest_port, $the_rest) = split(/\;/,$_); #Filter on source if -s is used if ($source =~ /\d+/){ if (($src_ip =~ /$source/) && ($source =~ /$src_ip/)){ $source_match = "TRUE"; } else { $source_match = "FALSE"; } } else { $source_match = "IGNORE"; } #Filter on destination if -d is used if ($destination =~ /\d+/){ if (($dest_ip =~ /$destination/) && ($destination =~ /$dest_ip/)){ $destination_match = "TRUE"; } else { $destination_match = "FALSE"; } }
Appendix D. Scripts
337
else { $destination_match = "IGNORE"; } #Write to file if match if ( (($source_match eq "TRUE")||($source_match eq "IGNORE")) && (($destination_match eq "TRUE")||($destination_match eq "IGNORE")) ){ #Then something has matched - either the source or destination or both, depending on whether a source #or destination was specified. print OUT "Date: $date Protocol: $protocol Source/port: $src_ip\[$src_port\] --> Destination: $dest_ip\[$dest_port\] Status: $action Dir: $direction\n"; } } close(MATCH);close(OUT); print "Processing complete. Report written to $outputfile.\n"; #***********************************FWLOGFIL******************************************
D.2 Trap forwarding script

This section documents the shell script used in Section 4.5.2.3, Forward only NetView rule passed events to TEC server on page 137.
338
#!/bin/sh # Filename: sendEventToTEC.sh # Function: Forward traps from NetView to TEC server per SNMP trap # Start: Start from TEC ruleset # # Environment variables for trap data # $NVE specifies the enterprise ID # $NVA specifies the agent address # $NVG specifies the generic trap number # $NVS specifies the specific trap number # $NVT specifies the time stamp # $NVC specifies the community name # NVATTR_<1-50> specifies the MIB attribute where 1-50 is the variable binding number # NVATTR_2 hostname or IP address # NVATTR_3 trap description # NVATTR_4 object number # NVATTR_5 netview database #Hostname or IP-Address of trap receiver TRAPRECEIVER=132.17.254.10 #Lofile LOGFILE="/tmp/sendEventToTEC.log" #Send trap to TRAPRECEIVER per snmptarp echo "Send trap to $TRAPRECEIVER $NVE $NVA $NVG $NVS $NVT $NVC">>$LOGFILE /usr/OV/bin/snmptrap $TRAPRECEIVER ".$NVE" $NVA $NVG "${NVS}0" 0 system.sysDescr integer 2 system.sysDescr octetstring "$NVA" system.sysDescr octetstring "$NVATTR_3 $NVATTR_4 $NVATTR_5">>$LOGFILE
Appendix D. Scripts
339
340
Appendix E. Installing the Ethereal Sniffer

This appendix describes the basic installation steps for the Ethereal Sniffer used in the lab.
E.1 Prerequisites
Download the binary install file for your platform from:
http://www.ethereal.com
We installed the software on a Windows 2000 server in the lab. The binary download file we used is ethereal-0.8.15-capture.zip. The Windows NT packet capture architecture library WinPCAP also needed to be installed (as a prerequisite to installing Ethereal). It installs a set of packet capture libraries to allow packet capturing for Windows. You can download this package from the following site:
http://netgroup-serv.polito.it/winpcap/
Follow the downloads link and download the version of the library for your platform. It supports Windows 95/98, Windows NT 4.0, and Windows 2000.
E.2 Installation
We need to install WinCap device driver, reboot, then install the Ethereal software.
E.2.1 Installing WinCap

These are the steps we used to install WinCap on the Windows 2000 platform: 1. Run the Packet2k.exe (or similar file) to install the WinCap packet capture library. Install it into a folder that you will easily remember. 2. Open the Windows 2000 Control Panel, as shown in Figure 251 on page 342.
341
Figure 251. Control Panel
3. In Windows Control Panel, double-click on the Network and Dial-up Connections icon. Then double-click Local Area Connection, as shown in Figure 252.
Figure 252. Local Area Connection
4. In the new panel, click on the Properties button to bring up the panel shown in Figure 253 on page 343.
342
Figure 253. Local Area Connection properties
5. Click on the Install button in the panel shown in Figure 253 so you can install new network components. You should now see the panel shown in Figure 254 on page 344.
343
Figure 254. Installing Network Component
6. Choose the line labeled Protocol and click Add to see the panel shown in Figure 255.
Figure 255. Select Network Protocol
344
7. Click on the Have Disk button and in the following panel, choose the full path where you have uncompressed the network device driver (this folder must contain the files packet.inf and packet.sys). Click on the OK button. This will bring up the panel shown in Figure 256.
Figure 256. Select Driver for WinCap
8. Choose the voice BPF Packet capture Driver v X.XX (where X.XX is the number of the version you are installing). Follow the instructions displayed on your monitor (Note: This installation can ask you for the CD-ROM containing Windows 2000). In the list containing network components, you see a line labeled BPF Packet capture driver vX.XX. The driver creates the binding on all the network interfaces installed on your computer. If some interface must not be used to capture packets you can remove the binding for that specified interface. Select OK to see the panel shown in Figure 257 on page 346.
345
Figure 257. WinCap driver installed
9. At this point, select OK and reboot the machine.
E.2.2 Installing Ethereal software

The WinCap driver is now installed and the Ethereal Software can now be installed. 1. Unzip the ethereal-0.8.15-capture.zip into the /ethereal directory. 2. Create a shortcut to the ethereal.exe file. You can launch the program from this shortcut.
346
Appendix F. Using the additional material

This redbook also contains additional material in CD-ROM or diskette format, and/or Web material. See the appropriate section below for instructions on using or downloading each type of material.
F.1 Locating the additional material on the Internet

The CD-ROM, diskette, or Web material associated with this redbook is also available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246229
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the redbook form number.
F.2 Using the Web material

The additional Web material that accompanies this redbook includes the following: File name SG246229.zip Description Contains the sample scripts referenced in the book.
F.2.1 How to use the Web material

Create a subdirectory (folder) on your workstation and copy the contents of the Web material into this folder.
347
348
Appendix G. Special notices

This publication is intended to help network managers and firewall administrators create solutions that allow management of secure networks. The information in this publication is not intended as the specification of any programming interfaces that are provided by NetView, Tivoli Mid Level Manager, Tivoli Management Framework, Tivoli Enterprise Console, Tivoli Decision Support, or Tivoli SecureWay Firewall. See the PUBLICATIONS section of the IBM Programming Announcement for NetView, Tivoli Mid Level Manager, Tivoli Management Framework, Tivoli Enterprise Console, Tivoli Decision Support, or Tivoli Secureway Firewall for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and
349
depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
AS/400 IBM Notes Redbooks RS/6000 SecureWay SP2 WebSphere XT e (logo) Lotus PC 300 Redbooks Logo SAA SP System/390 Wizard
The following terms are trademarks of other companies: Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything. Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems Inc., an IBM company, in the United States, other countries, or both. In Denmark, Tivoli is a trademark licensed from Kj benhavns Sommer - Tivoli A/S. C-bus is a trademark of Corollary, Inc. in the United States and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license.
350
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Check Point, the Check Point logo, FireWall-1, FireWall-1 SecureServer, FloodGate-1, INSPECT, IQ Engine, Meta IP, MultiGate, Open Security Extension, OPSEC, Provider-1, SVN, User-to-Address Mapping, VPN-1, VPN-1 Accelerator Card, VPN-1 Appliance, VPN-1 Certificate Manager, VPN1 Gateway, VPN-1 SecuRemote, VPN-1 SecureServer, and ConnectControl are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. Oracle is a registered trademark, and Oracle Database and Oracle SQL*Plus are trademarks or registered trademarks of Oracle Corporation. Tera Term is a copyright of Takashi Teranishi. Ethereal is Open Source software released under the GNU General Public License. Sniffer is a registered trademark of Network Associates, Inc. Perl is a copyright of Tom Christiansen and Nathan Torkington. WinPCAP is a copyright of the Regents of the University of California. Sybase is a trademark of of Sybase, Inc. Other company, product, and service names may be trademarks or service marks of others.
Appendix G. Special notices
351
352
Appendix H. Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
H.1 IBM Redbooks

For information on ordering these publications see How to get IBM Redbooks on page 357. Tivoli NetView 6.01 and Friends, SG24-6019 Examples of Using TME 10 NetView for AIX V5 and TME 10 Netview for Windows NT, SG24-4898 Integrated Management Solutions Using NetView Version 5.1, SG24-5285 An Introduction to Tivoli Enterprise, SG24-5494 A Design and Implementation Guide for Tivoli Decision Support , SG245499 Using Tivoli Decision Support Guides, SG24-5506 Tivoli Decision Support V2.1: New Features and Performance Optimization, SG24-5491 TEC Implementation Examples, SG24-5216 Early Experiences with Tivoli Enterprise Console 3.7, SG24-6015 Tivoli Enterprise Management Across Firewalls, SG24-5510 Additional AIX Security Tools on IBM ~ pSeries, IBM RS/6000 and SP/Cluster, SG24-5971 A Comprehensive Guide to Virtual Private Networks, Volume III: CrossPlatform Key and Policy Management, SG24-5309
H.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs button at ibm.com/redbooks for information about all the CD-ROMs offered, updates and formats.
CD-ROM Title IBM System/390 Redbooks Collection IBM Networking Redbooks Collection Collection Kit Number SK2T-2177 SK2T-6022
353
CD-ROM Title
Collection Kit Number IBM Transaction Processing and Data Management Redbooks Collection SK2T-8038 IBM Lotus Redbooks Collection SK2T-8039 Tivoli Redbooks Collection SK2T-8044 IBM AS/400 Redbooks Collection SK2T-2849 IBM Netfinity Hardware and Software Redbooks Collection SK2T-8046 IBM RS/6000 Redbooks Collection SK2T-8043 IBM Application Development Redbooks Collection SK2T-8037 IBM Enterprise Storage and Systems Management Solutions SK3T-3694
H.3 Other resources

These publications are also relevant as further information sources: Elizabeth Zwicky, et al, Building Internet Firewalls, OReilly and Associates, 2000, ISBN 1565928717 Tivoli NetView Administrations Guide V6.0, SC31-8440 Tivoli NetView for UNIX Version 6.0 Installation and Configuration Guide, SC31-8442 Tivoli TEC 3.7 Adapter s Guide, GC32-0668 TME 10 NetView for AIX Version 5 Release 1 MLM Users Guide, GC318448 TME 10 Framework 3.6 Planning and Installation Guide, SC31-8432 The following publication can be found on the IBM Redbooks CD-ROM Collection LK3T-5826: Tivoli Management Framework Planning for Deployment Guide Version 3.7.1
H.4 Referenced Web sites

These Web sites are also relevant as further information sources: RFC documents Web site - http://www.rfc-editor.org RFC documents Web site- http://www.rfc.net Oracle documents Web site - http://technet.oracle.com NetView Web server Jetty Web site - http://jetty.mortbay.com/ SSH Web site - http://www.ssh.com/
354
OpenSSH Web site - http://www.openssh.com/ AIX freeware Web site - http://www.bull.com/ Download site for the Tera Term Windows NT terminal emulator - http://
www.download.com/
Download site for SSH client add-on of Tera Term - http://

www.zip.com.au/~roca/ttssh.html/
Download site for Ethereal Sniffer - http://www.ethereal.com Download site for WinCap packet capture library - http://netgroupserv.polito.it/winpcap/
IBM WebSphere Edge Server for eBusinesses Web site - http://www4.ibm.com/software/network/dispatcher/
Perl download site - http://www.activestate.com Perl download site - http://www.perl.org Port numbers reference Web site - http://www.iana.org/assignments/portnumbers
Check Point Web site - http://www.checkpoint.com/ IBM Security Web site - http://www-3.ibm.com/security/index.shtml
Appendix H. Related publications
355
356
How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks, redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided. Redbooks Web Site ibm.com/redbooks Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site. Also read redpieces and download additional materials (code samples or diskette/CD-ROM images) from this Redbooks site. Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows. E-mail Orders Send orders by e-mail including information from the IBM Redbooks fax order form to: In United States or Canada Outside North America Telephone Orders United States (toll free) Canada (toll free) Outside North America 1-800-879-2755 1-800-IBM-4YOU Country coordinator phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl e-mail address pubscan@us.ibm.com Contact information is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
Fax Orders United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 Fax phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
This information was current at the time of publication, but is continually subject to change. The latest information may be found at the Redbooks Web site. IBM Intranet for Employees IBM employees may register for information on workshops, residencies, and Redbooks by accessing the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
357
IBM Redbooks fax order form

Please send me the following: Title Order Number Quantity
First name Company Address City Telephone number Invoice to customer number Credit card number
Last name
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
358
Abbreviations and acronyms

ACL AH API APM ARP bps CDE CNAT Access Control List Authentication Header Application Programming Interface Agent Policy Manager Address Resolution Protocol Bits per second Common Desktop Environment Tivoli Comprehensive Network Address Translator Common Object Request Broker Architecture Dynamic Host Configuration Protocol Demilitarized Zone Domain Name Server Encapsulated Security Payload File Transfer Protocol Firewall Graphical User Interface Hyper Text Transport Protocol Internet Assigned Numbers Authority International Business Machines Corporation Internet Protocol IP Security Protocol MN NAT NFS NIS NM NMS NO ODBC MLM MTTR MTBSO ITSO ISDN ISO ISP JDBC LAN LDAP MIB IT ITIL ISO International Standardization Organization Information Technology Information Technology Infrastructure Library International Technical Support Organization Integrated Services Digital Network International Technical Organization Internet Services Provider Java Database Connectivity Local Area Networks Lightweight Directory Access Protocol Management Information Database Mid-Level Manager Mean Time To Repair Mean Time Between Service Outages Managed Node Network Address Translation Network File System Network Information System Network Management Network Management System Network Object Open Database Connectivity
CORBA
DHCP DMZ DNS ESP FTP FW GUI HTTP IANA IBM IP IPSEC
359
ORB OS OSPF PC
Object Request Broker Operating System Open Shortest Path First Personal Computer Relational Database Management System RDBMS Interface Module Routing Information Protocol Remote Procedure Call Request for Comment Service Level Agreement Secure Network Simple Network Management Protocol Service Provider Secure Shell Service Socket Layer SecureWay Firewall System Management Server Transmission Control Protocol Tivoli Enterprise Console Tivoli Decision Support Tivoli Management Agent Tivoli Management Environment Tivoli Management Region User Datagram Protocol Unsecure Interface
UN VPN WAN
Unsecure Network Virtual Private Network Wide Area Networks
RDBMS
RIM RIP RPC RFC SLA SN SNMP SP SSH SSL SWF SMS TCP TEC TDS TMA TME TMR UDP UI
360
Index Symbols
$ prefix in netmon.seed 70 $BINDIR/TME/TEC/.tec_config 130 $HOME/.ssh/authorized_keys 156 $HOME/.ssh/identity 156 $HOME/.ssh/identity.pub 156 $ORACLE_HOME/network/admin/listener.ora 122 $ORACLE_HOME/network/admin/tnsnames.ora 124 /etc/hosts 48 /etc/inittab 154 /etc/openssh/ 156 /etc/openssh/shhd_config 155 /etc/openssh/ssh_host_key 155 /etc/rc.openssh 154 /etc/rc.tcpip 154 /etc/snmpd.conf 52 /MLM/AIX/CFG-AIX5.0.1 82 /MLM/AIX/MLM-AIX.5.0.1 82 /MLM/AIX/MLM-AIX5.0.4 91 /usr/local/bin/opensshd 153 /usr/OV/conf/oid_to_type 70 /usr/OV/conf/ovsuf 51 /usr/OV/conf/tecad_nv6k.conf 140 /usr/OV/conf/tecint.conf 131 /usr/OV/lrf 83 /usr/OV/www/conf/JettyServer.prp 144, 146 /usr/websm/bin/wsm 231 IPSEC gateway with Windows 2000 client 230 IPSEC required filesets 231 starting IPSEC stack 232 starting System Manager 231 testing of VPN connection 254 AIX 4.3.3 43, 44, 48, 52 Alias Table 87 APM 50, 51 registration file 84 application layer 9 application level gateway 7 application proxy 5, 6 application services site 10 architecture network management 41 ARP 24, 77 , 266 ARP cache 20 arrow Flow 66 attack 3 active 3 passive 3 auditing 11 authentication 11 Authentication Header see AH 12 availability 36 improving 18
B
bastion 9, 10 disadvantages 9 best practice benefit of internet_access host 276 bos.crypto 231 bos.crypto-priv 231 bos.crypto-wt 231 bos.net.ipsec.keymgt 231 bos.net.ipsec.rte 231 bos.net.ipsec.websm 231 bos.net.tcp.server 82 building our environment 47 business requirements 41
A
access control lists see ACL 21 ACK 42 ACL 284 definition 21 ActiveX 11 Add a New Connection 66 Agent Policy Manager 83 see APM 50 AH 175 definition 12 definiton 165 details 166 AIX IPSEC client and gateway 230
C
C5d 51
361
checking status 51 C5d.lrf 84 cable modems 18 capture a trace steps taken 75 case study single firewall 41 CDP 24 central controlling 21 Check Point FireWall-1 xvii test environment 103 VPN-1 SecuRemote xviii Check Point FireWall-1 installing 311 prerequisites 311 RPC requests 129 Check Point SecuRemote installation 329 Check Point VPN-1 configuration steps 179 policy editor 179 Check Point VPN-1 Gateway 178, 179 Check Point VPN-1 SecuRemote 178, 179 circuit level gateway 6, 7 Cisco 98 Cisco devices 26 CiscoWorks 2000 25 client/server SNMP 20 technology 17 client/server communication protecting 22 CNAT 78 definition 77 placement 77 common object request broker architecture see CORBA 30 communication approach 54 community string 22 read 22 read-only 52 read-write 52 write 22 community strings defaults 22 Complex Main 95 Component Object Request Broker 263
Comprehensive Network Address Translator see CNAT 77 configuration data 21 configuration database 21 configuration element 41 configuration management 18 configuration polling 105, 266 Configure event forwarding to T/EC 126 connection 55, 66, 207 activating 68 configuration 66, 78 connections we defined 79 definition 42 definiton 66 destination 67 initiated 67 Ping FW 79 Ping out secure network 79 relationship with service 64 SNMP out secure network 79 steps to create 66 Telnet out secure 79 testing 69 traffic direction 64 Traps in secure 79 Connection Setup 66 Connection Templates 60, 64 connections 41, 54, 60 considerations for security 98 CORBA definition 30 corporate network 261 CPU performance 34
D
data link layer-based VPN 164 Data management tunnel 233 DATA packets 42 Database server 263 DB2 25, 116 Debug priority 73 demandpoll 29 Demilitarised Zone see DMZ 8 denied packets 73 reports 71 destination address 73 destination port 41
362
detecting network faults 18 device configuration 18 directional flow 65 discovery 266 distributing 28 protocol used 24 discovery polling 85, 266 distribute polling 84 Distributed management with NetView 106 distributed network management 26, 27, 46, 104, 106 advantages 27 design 28 distributed system management 32 distributing polling limitations 28 recommendation 28 DMZ 261, 262 definition 8 management system access 35 network management 35, 36 network management solution 265 reasons for it 11 status polling 267 DNS 48 domain name services see DNS 48 double identification 9 dual homed gateway 9 dual homed host 6 definition 8 duplicate addresses managing 77 dynamic firewall rules 129 dynamic tunnel process 172 protocol control 172
eBusiness xvii, 261, 264 echo 55 electronic data exchange 37 e-mail 25 Encapsulated security payload see ESP 12 encrypted tunnel 287 encryption 8, 11 encryption domain 184
encryption key generating 185 encryption types 3DES_CBC 175 CDMF 175 DES_CBC 175 enterprise-critical components 23 eServers 263 ESP 175, 256 definition 12, 165 details 166 ESP/AH 175 Ethereal 74, 75, 76, 91, 229 capture a trace 75 network protocol analyzer 45 prerequisite 45 sniffing a tunnel 198 sniffing remote MLM install 91 sniffing trap traffic 89 window panes 77 event correlating 35 event and fault management 18 event receiver 133 Event Viewer 89 events automation 26 evaluate network events 34 filters 25 forward all 133 forward specific events by SNMP 135 forwarding to TEC 132 forwarding with nvserverd 125 management 25 rules 25, 35 examples firewall rule building 60 fwlogfil.pl 74 fwlogtbl 73 exterior router 263, 282 extranets 36 network management 37
F
f_match.tbl 73 example 73 filter traps 81 firewall 46
363
administering 21 allowing network management 36 architecture 8, 22 auditing 11 concepts 4 configuration 21 definition 7, 42 deny traffic by default 11 installation main considerations 54 introduction 3, 5 logging 11 network management 36 objectives 10 plan the interfaces 54 rules 10, 53 simple anology 5 terminologies 7 tracking activity 11 firewall configuration allowing IPSEC VPN through firewall 255 firewall configuration rules installation of managed node 112 installation of NetView 113 Flow 66 flow of traffic 42 forwarding traps 261, 278 fragmentation 41 Framework xvii freeware network protocol analyzer 45 freeware.egd.rte 151 freeware.openssl.rte 151 freeware.perl.md5.rte 151 freeware.perl.rte 151 freeware.zip.exe 151 freeware.zlib.exe 151 FTP 6, 7, 42, 93, 95, 97, 263 ports 4 proxy support 6 rules 42 FW basic rule configuration 55 definition 7 fwlogfil.pl 73, 336 fwlogtbl 73 FWZ 184, 188, 192, 196
H
hacker 4, 5, 6, 9, 11 detecting 11 help desk system 25 hijacking 22 HMAC_MD5 175 HMAC_SHA 175 HTTP 6, 7, 263 proxy support 6 http //freeware.bull.net 149, 151 //jetty.mortbay.com/ 143 //netgroup-serv.polito.it/winpcap 45 //technet.oracle.com 124 //www.checkpoint.com 178 //www.ethereal.com 45 //www.isi.edu/in-notes/iana/assignments/portnumbers 4 //www.openssh.com/ 149 //www.ssh.com/ 149 www.activestate.com 74 www.perl.org 74 www.rfc.net 19 www.rfc-editor.org 19 HTTP Servlet server 143 HTTP Web server 263 hubs 20
I
IANA 4 track ports 4 IBM SecureWay implementing VPN 171 test environment 103 IBM SecureWay Firewall 10, 53, 203 functionality 78 installing 301 logging 71 objectives 10 prerequisites 301 proxy support 6 rule configuration 60 see SWF 41 socks server 7 VPN 163 ICMP 24, 25, 55, 70, 79 echo-reply 25 IETF 167
364
definition 164 IPSec Working Group 165 PPP Extensions Working Group 168 ifAdminStatus 70 ifOperStatus 70 IfOutOctets 282 IKE 184, 255 definition 12 explained 166 inbound 62, 73 initiator 65, 66 initiator of traffic 64 Interface Errors 282 interface status 21 interface throughput 34 Interface Traffic 282 internal security zones 36 International Standardization Organization see ISO 19 Internet access determining total loss 276 Internet Assigned Numbers Authority 4 Internet Connectivity 268 Internet Engineering Task Force see IETF 164 Internet firewall 263 Internet key exchange see IKE 12 Internet Security Association see ISA 165 Internet Service Provider xvii Inventory 18 inventory data 33 inventory management 32 IP Authentication Header see AH 165 IP Encapsulating Security Payload see ESP 165 IP forwarding 9, 47 IP Map topology 52 IP routing enabled 47 IP Security Architecture see IPSec 165 IPSec 12, 255 AIX configurations 230 client 179 definiton 165 modes of operation 12
protocols 12, 165 tunnel 215 Windows 2000 210 Working Group 165 IPSec-based VPN 164 IPv4 164 IPv6 164 ISA definition 165 explained 166 ISO 19 isolate your internal network 11 ISP 261, 263, 285 ITSO testing environment 42
J
Java 11 Java Remote Method Invocation see RMI 146 Java Runtime Environment 143 Java Web client communications 143, 146 example of use over a VPN 200 remote access 142 remote access using VPN 199, 290 usage 29 VPN recommendation 146 Jetty 143
K
Key Management Protocol see KMP 165 Key management tunnel 233 KMP definition 165 explained 166
L2F 12, 168 definition 167 L2TP 12 definition 167 explained 167 limitations 167 with IPSec 168 Layer 2 protocols 167
365
Layer 2 forwarding see L2F 167 Layer 2 Tunnelling Protocol see L2TP 167 layer 2-based VPN 164 layered security 8 loadhosts 271 Local SPI 175 Local Tunnel Address 175 Local User Address 175 logging 11, 71 conversion utility 73 importing into an RDBMS 73 priority 73 warning about Debug priority 73 lsnrctl 123
M
mail server 36 mail servers 8 managed node installation 48, 108 management information base see MIB 20 method 32 MIB 22, 24 available data (sample) 20 definition 20 MIB browser 29 MIB-II 282 Mid-level Manager see MLM 26 midmand 82, 83 MLM 44, 51, 80, 81, 293 advantages 26, 27 AIX installation from CD 82 AIX prerequisites 82 benefits 27 best practice 28 description 44 discovery 26 discovery limitations 28 distributed network management 26, 104 distributed network managment 104 distributing polling activities 106 event automation 26 install from CD 81 install rules, services, connections 94
installation 44, 52 limitations 28 manage nodes outside their segment 51 NetView communication 27 node discovery 105 performance data collecting 26 polling 105 read-write community string 81 recommendation 106 remote install communication channels 94 remote installation 48, 81 remotely install 80 remotely installing 52 Service Provider 104 starting 82 status polling 26, 27 stopping 82 three-tier hierarchy 26 threshold setting 26 trap filter 27 trap filtering 28 trap forwarding 27 usage 26, 27 verify trap forwarding 88 MLM SmartSet 52 mlmcfg 82 installation 82 mmc 211 modifies the source IP address 8 multiple interfaces 276 multi-vendor management products 25
N
name resolution 48 NAT 77, 78 definition 8, 77 Net8 119 netmon 28, 83 -a 50 51, 85 relationship to MLM 106 setting SNMP status polling 70 netmon.lrf 83, 84 -a 50 84 netmon.seed 70 NetView xvii, xviii, 23 APIs 25 as NO 56 as TMR server 115
366
auto discovery 266 automated event response 25 central trap receiver 25 checking polling distribution 87 checking running daemons 49 Client 29 clients 56 collecting network events 34 collecting SNMP data 34 communication with TDS 32, 37 communication with TEC 32, 35, 37 configuration polling 105, 266 customizeable graphical user interface 25 detecting network changes 24 event filtering 35 event management 21 event rule 35 flexibility 26 forwarding traps 278 GUI 44 in secure network 53 in Service Provider TMR 107 install through firewall 109 installation 48, 112, 115 installation conclusions 114 installation prereq 43 installation recommendation 116 installation requirements (Tivoli) 32 installed on TMR servers 114 installing Database Support 49 installing NetView for Windows 50 installing server 48 integrated with Tivoli 30 integration with TEC 35 introduction 19 Java client 37, 142 Java client (see Java client) 29 Java console on Win2k via IPSEC tunnel 230 Java Web client 142 MIB browser 142 MLM communication 27 MLM communications 52, 86 MLM trap forwarding via TCP 86 netmon 28 netview (command) 49 NetView for Windows prerequisite 50 on managed nodes at customer locations 108 Oracle database 103 own TMR-Region 114
paging 25 performance graphs 25 placed in customer environments 106 placement 102 recommended event forwarding configuration 130 recommended event forwarding solution 125 reducing port usage 132 reducing ports 131 remote access 28, 37, 141 remote access using VPN 199 remote session 28 server setup application 133 server setup dialog 126 SmartSets 23, 25, 29 Solaris 23 starting GUI 49 status polling 24 test environment 43, 103 three-tier hierarchy 26 topology database 24 within a DMZ 266 NetView 6.01 Patch CD 49 NetView client usage 29 NetView NT forwarding events 139 trapfrwd 278 NetView server icon right-clicking 49 network architecture 18 non-secure 9 secure 9 topology 18 Network address translation see NAT 8 network administrators 18 network diagnostics 29 Network File System 126 Network Information Service 126 Network layer 6 network layer-based VPN 164 network management xvii, 17 across firewalls 36 architecture 41 centralized 23 communications 54 introduction 17
367
see NM 41 through VPN 199 network management station see NMS 20 Network Monitor SMS version 75 Network Object see NO 42 network object group creating 59 network objects 25 network operating center see NOC 29 network segments 36 network service providers 36 network topolog 29 network topology 23 network traffic reducing 27 reducing trap traffic 28 network utilization 34 NFS 126 NIS 126 NM components 44 definiton 41 server 46 NMS data source 21 definition 20 function 20 SNMP authentication 22 NO 67 adding a network object 58 creating 56 creating network object group 59 defining the firewall 181 definiton 42 host attribute (when to use) 58 object name 58 object type 58 permitting traffic between NOs 66 tunnel definitions 177 workstation type 182 NOC definition 29 Node Down 276 non-promiscuous 75 nvserverd 125, 126
nvserverd trap forwarding 124 nvsnmptrap 45 example 45
O
odadmin 110, 111 odinfo 111 set_port_range 111 ODBC drivers 50 OID 278 OpenBSD 149 OpenSSH 149, 151 Oracle 25, 102, 103, 116, 118, 119, 121 communications port 119 listener ports 123 oserv 4, 111 OSI Layer 7 outbound 62 outsourcing xvii ovaddobj 84, 278 ovdelobj 84 ovstart 51, 85 ovstatus 49, 51
P
-P switch 70 packet analysis 6 packet filter 9 packet filtering 5, 6 paging 25 payload 77 performance analysis 21, 116 performance data 21, 102 performance graphs 25 performance management 18, 21 Perl 73, 74 download 74 ping 29, 42, 47, 55 PNM 264 defined 261 Point to Point Tunnelling Protocol see PPTP 167 Policy 175 polling status 20 Polling using SNMP 70 port 3 >1023 22, 24, 25, 27, 55, 61, 79 0 25, 79
368
111 128 1521 119 161 21, 24, 27, 56, 61, 79 162 25, 27, 56, 79 20 93 21 93, 95, 96 22 150, 154 23 4, 55, 79 259 204 500 255 5000 95, 97 512 95, 96, 110, 111 5529 141 69 55 8 25, 79 8080 144 8892 144, 146 94 4, 111 blocking 6 destination 41 dynamic 4 FTP 4 high 3, 4 high port range 4 IANA track range 4 odd numbers 4 private 4 privileged 4 Registered 4 source 41 well-known 3, 4 well-known list 4 well-known range 4 portmapper 128 PPTP 12, 168 definition 167 pre-shared secret 216 Prime Network Management Model see PNM 261 private network 10 keeping private 11 proactive management 21 problem resolution speeding up 29 Program FilesIBMFirewalllog 73 promiscuous network mode 75 protocol ipip 203 proxy
application level 6, 9 server 6, 10, 263 Proxy server 263 public network 11
R
rcp 148 RDBMS 25, 33, 34, 116 reachability 36 read-only community string 52 redundancy 263 refresh SNMP 52 Regenerate Connection Rules and Activate 68 Relational Database Managmenet System see RDBMS 25 reliability 36 Remote access 141 remote access 141 NetView 28 network management 37 secure access from home 178 SSH 148 X-Windows 28 remote control 32 Remote Installation 91 remote installation recommendation 98 Remote Procedure Call see RPC 126 Remote SPI 175 Remote Tunnel Address 175 Remote User Address 175 remote users 11 report generation 18, 34 Reporting 73 reporting 33 firewall block 73 rexec 48, 94, 95, 98, 109, 111, 114 RFC 4 1057 126 1157 19 1831 126 2341 168 rhosts 155 RIM 114, 117 RIM object 117 rlogin 148 RMI
369
definiton 146 router 46, 47, 54, 70 routers 18, 20 Routing 62 routing tables discovery 24 RPC 127 definiton 126 Microsoft 127 portmapper 128 security considerations 130 Sun 127 RS6000 43P 43, 44 RSA 155 rsh 148 rule 60, 66 basic configuration 55 configuration 78 Direction 62 firewall definiton 41 MLM Traps to NetView 90 Routing 62 SNMP requests 62 SNMP response 62 rules 54, 55, 60 building 60 packet filtering 6 ruleset action box 138
S
safe traffic 10 screened subnet 10 disadvantages 10 screening router 5, 6, 8, 9, 10 secure interface see SI 42 secure network 46, 180 see SN 7, 41 SecuRemote 186, 187, 203 authenticated 196 create a site 194 downloading 329 getting ready to use 194 key retrieve request 195 port usage 204 through a firewall 203 SecuRemote client 178
SecureWay Firewall 44, 54 hardening 54 initial installation 55 installation 44, 54 installation considerations 54 installation issues 54 introduction 54 security building block 9 security holes 11 security policies 97 Seed File 70 Seed File Editor 70 sending traps 45 serial interfaces 70 Server farms 267 ServerPort 131 serversetup 51 service 42, 64, 66 adding a new one 64 adding to a connection 67 configuration 63, 66, 78 definition 42 direction of traffic 63 groups rules 63 SNMP 63 SNMP requests 62 Service Composition 65 service delivery 36 Service Level Agreement see SLA 25 Service Pack 47, 50 service provider xvii network managment 36 see SP 101 Services SNMP Request 79 services 41, 54, 55, 60 set_port_range 110 SI 59 definiton 42 Simple Network Management Protocol 19 SLA 25, 102, 264, 278 service provider 36 slow link 28 smart card authentication 10 smart client function 11 SmartSet 23, 25, 29, 51 smconfig 86 S-MIME 164
370
smitty 82 smmlm 82 SMS 75 SMTP mail servers 263 SN 41, 42, 45, 53, 54, 59, 60, 62, 63, 66, 80 building NO 56 definition 7 definiton 41 sniffer tracing 74 SNMP 98 across firewall 102 adapter for TEC 134 agent 20, 21, 22, 24, 25 architecture model 20 authentication 22 authorized NMS access methods 22 communication 23 communications 49 concept 20 daemon 48 distributed model 20 encryption 22 get 60 listening port 22 manager 20 managment application basis 23 MIBII 49, 52 network management system 19 NT Service 51 performance data 102 polling 66, 70 ports 56 read-only string 81 refresh AIX daemon 52 register NMS at agents 22 requests to the firewall 62 see RFC 1157 19 service 52 service on Windows 66 snmpget destination port 21 snmpget packet capture 77 snmpwalk 49, 50, 70 testing SNMP service 50 thresholds 25 todays standard 19 trap configuration dialog 136 trap forwarding 124 , 132 trap port 22 traps 21, 56
Windows NT service 81 Windows SNMP error 50 Windows SNMP service 50 snmpd 52 snmpd.conf 52 SNMPv1 22 SNMPv2 20, 22 SNMPv3 23 snmpwalk 50, 52, 69 , 76 SOCKS 9, 164 Socks server 263 source address 6 source port 41 SP 101 scenario 101 spoofing 22 sqlplus 121 SSH 86, 98 , 99, 114, 146, 287 client configuration 156 client install 156 daemon configuration 153 enable X11 sessions 154 firewall configuration 161 generate key 155 installing 152 port usage 150 sample configuration 150 starting client 157 starting daemon 155 stopping daemon 155 usage with Oracle 124 Windows NT client 158 X-Window solution 148 SSH version 1 148 SSH version 2 148 SSH1 149 SSH2 148 ssh-keygen 155 SSL 164 Start Capture 76 static route 48 status polling 26, 267 distributing 27 subnet 28 subnet mask 58 suspicious behavior 11 SWF 42, 58, 66, 71 definiton 41 disabling 75
371
GUI 56 rules shipped with it 79 service 63 switches 18, 20 Sybase 25, 116 SYNC 42 sysContact 50, 70 sysLocation 50, 70 sysName 50, 70 sysServices 50, 70 system administrators 18 system management platform 30 sysUpTime 50, 70
TCP 22, 41, 79 TCP header 77 TCP/IP 3, 47, 51, 77 configure 48 host-to-host protocol 3 ports 3 TDS xvii, xviii, 33, 102, 116, 261 communication requirements 37 communication with NetView 32, 37 communications 102 cooperation 116 database transfers 117 evaluate network events 34 event analysis 34 guides 34 implementation 34 integration 114 NetView in DMZ 286 relation to NetView 33 reports 34 test environment 103 usage 25, 116 using NetViews data 34 what is it? 33 TEC xviii, 34, 43, 101, 261 adapters 34 basic function 34 communicating with TDS 33 communication with NetView 32, 35, 37 communications 102 comunication requirements 37 console 35 event correlation 35
event rules 35 events from NetView 25, 132 more information 35 reducing port usage 130, 132 SNMP adapter 133, 134 test environment 103 TEC connection 124 tecad_nv6k 125, 139 configuration 140 NetView for UNIX 140 telnet 4, 9, 42, 55, 79, 97, 147 proxy support 6 Test environment 102 TFTP 55, 98 threshold setting 26 thresholds 25 time periods 42 Tivoli xvii, 30 authentication 31 communications 32 Desktop 48 desktop 48 endpoint 32 endpoint requirements 32 endpoints 31 framework 30, 31, 32, 102 gateway 31, 32 installation requirement 31 managed node 31, 32, 37, 43 managed nodes 31 management agent 32 objcall 111 Object Dispatcher Service 111 oserv 111 platform 23 policies 35 port range 110 roles 35 TMA 32 TMR 31 TMR server 37 verification 31 Tivoli Decision Support see TDS xvii Tivoli Desktop install MLM remotely 91 Tivoli Enterprise Console see TEC xvii Tivoli framework 43
372
Tivoli management region see Tivoli TMR 31 TMA see Tivoli management agent 32 TMR xvii, 107 TMR server 31, 32, 43, 48, 59, 103, 108 hostname 48 name resolution 48 TMR, interconnection 116 TNS 119 listener configuration 122 TNS listener 119 tnsnames.ora 124 topology data 21 topology database 21, 24 topology management 18 topology map 23 topology view 21 traceroute 29 tracing hackers 11 traffic type 41 Transparent Network Substrate 119 Transport layer 6 trap filters 27 trap forwarding TCP conversation 89 trap sending process 22 trapd configuration 136 setting options 134 trapfwrd.lrf 278 traps 21 trend analysis 18 trouble ticket system 25 troubleshooting communications 45 network environment 71 tunnel creating a defintion 172 dynamic filter type 174 static filter type 174 tunnel definition exporting 176 importing 176 tunneling 8 tunneling techniques xvii type of traffic flow 42
U
UDP 22, 24, 25, 56, 62, 86 UI 59, 62, 66 definition 42 UN 41, 42, 53, 54, 60, 62, 63, 66, 67, 75 building NO 56 definition 41 UNIX 4 UNIX daemons 4 unnumbered serial interfaces 70 unsecure interface see UI 42 unsecure network 42, 45, 46 see UN 41 URL filtering capability 7 usrOVbin 45 usrOVconfrapfwrd.conf 279
V
verify MLM install through firewall 97 verify NetView / MLM communication 87 virtual circuit 6 Virtual Private Network 7 see VPN 8 virtual private network see VPN 163 Virtual Private Networking 6 VPN xvii, xviii, 7, 287 authentication option 183 based on user names 186 building a client to site 178 building options 11 case study 7 change management 170 client to site concept 163 configuration management 170 creating a user 186 Data Link layer 11 defining the tunnel at a gateway 179 definition 8 definiton 163 encryption domain 184 encryption schemes 184 explained 11 Exportable for SecuRemote 184 firewall rule 190 firewall rule components 190 IPSec 12
373
IPSec based 164 Layer 2 11 Layer 3 12 maximizing value 164 network discovery design consideration 171 Network Layer 12 network layer 12 network management 199 parameters 184 performance management 170 pitfalls 171 problem management 170 transport mode 215, 256 using IBM SecureWay Firewall 163 using only Windows 2000 210 VPN tunnel deactivating 177 VPN tunnels dynamic 171 static 171
W
Web server 8, 10 Webspheres Edge Server 263 Windows SNMP service 50 Windows 2000 23 activating security policy 228 associate filter action 226 custom console 211 IPSEC client configuration 228 IPSecurity policy 211 security policy filters 216 security policy protocols 219 testing VPN connection 229 tunnel endpoint 215 Windows NT 23, 44, 46, 50, 54 Network Monitor 74, 75 Windows NT 4.0 43, 44, 47, 51 winntsystem32 45 WinPCAP 45 wstartesvr 131 wstopesvr 131
X
X11 147 X-Windows 28, 147, 290
374
IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook "made the difference" in a task or problem you encountered. Using one of the following methods, please review the Redbook, addressing value, subject matter, structure, depth and quality as appropriate. Use the online Contact us review redbook form found at ibm.com/redbooks Fax this form to: USA International Access Code + 1 845 432 8264 Send your comments in an Internet note to redbook@us.ibm.com
Document Number Redbook Title Review
SG24-6229-00 Extending Network Management Through Firewalls Solutions for todays Service Provider
What other subjects would you like to see IBM Redbooks address?
Please rate your overall satisfaction: Please identify yourself as belonging to one of the following groups: Your email address: The data you provide here may be used to provide you with information from IBM or our business partners about our products, services or activities. Questions about IBMs privacy policy?
O Very Good
O Good
O Average
O Poor O Solution Developer
O Customer O Business Partner O IBM, Lotus or Tivoli Employee O None of the above
O Please do not use the information collected here for future marketing or promotional contacts or other communications beyond the scope of this transaction.
The following link explains how we protect your personal information. ibm.com/privacy/yourprivacy/
375

Design Secure Network Management Solutions Secure Network Management Communications Best Practice for DMZ Management
Todays networked environment requires a high degree of security, which means that network management poses many new challenges. Using Tivoli NetView and associated technologies, this redbook will address key network security and management architecture, design, and implementation issues. This redbook addresses several fundamental issues: - A best-practice network management architecture to manage a DMZ (eBusiness) - How to manage the availability of multiple ISP connections to the Internet (eBusiness) - Which ports are needed for discovery, polling, and communications between NetView and associated products - Examples of implementing remote network management using VPN or Secure Shell tunnelling - How to configure Checkpoint Firewall-1 and IBM SecureWay Firewall for network management communications - Best practices for managing networks behind a firewall This book is essential in planning secure NetView-based network management solutions. This redbook will provide invaluable information for both network and security management professionals.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6229-00 ISBN 073842241X

Firewalls

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Firewalls

Încărcat de

Drepturi de autor:

Formate disponibile

Extending Network Management Through Firewalls

Stephen Hochstetler Harry Tanner Ramachandra Kulkarni Sebastian Mika

International Technical Support Organization Extending Network Management Through Firewalls

Copyright IBM Corp. 2001

Extending Network Management Through Firewalls

Extending Network Management Through Firewalls

Copyright IBM Corp. 2001

Extending Network Management Through Firewalls

Extending Network Management Through Firewalls

Extending Network Management Through Firewalls

Extending Network Management Through Firewalls

Copyright IBM Corp. 2001

Extending Network Management Through Firewalls

Copyright IBM Corp. 2001

The team that wrote this redbook

Extending Network Management Through Firewalls

Extending Network Management Through Firewalls

Copyright IBM Corp. 2001

Chapter 1. Introduction to firewalls

1.1 TCP/IP preview

Copyright IBM Corp. 2001

1.1.1 Well-known ports

1.1.2 High ports

1.2 The concept of the firewall

Extending Network Management Through Firewalls

1.3 The components of a firewall

Chapter 1. Introduction to firewalls

Extending Network Management Through Firewalls

Application level Gateway Application Yes

Circuit level Gateway Transport through session No

Done at the Proxy Provided No Yes

Done at the client Usually no logging Yes No

1.4 Terminologies associated with the firewall

Chapter 1. Introduction to firewalls

Dual homed host

Firewall DMZ Router

Figure 1. Theoretical firewall environment

1.5 Firewall architectures

1.5.1 Screening router

Extending Network Management Through Firewalls

Secure Network Internet Screening Router

Figure 2. Screening router

1.5.3 Dual-homed gateway

Chapter 1. Introduction to firewalls

Secure Network Dual homed Firewall

Figure 3. Dual-homed gateways

1.6 Firewall objectives and firewall rules

Extending Network Management Through Firewalls

1.6.1 Beyond the firewall: filtering content

1.7 Virtual Private Networks

Chapter 1. Introduction to firewalls

1.7.1 Case study of VPN

Extending Network Management Through Firewalls

Remote employee with IpSec client

Figure 4. VPN case study

Chapter 1. Introduction to firewalls

Extending Network Management Through Firewalls

Chapter 1. Introduction to firewalls

Extending Network Management Through Firewalls

Chapter 2. Network management

Copyright IBM Corp. 2001

Extending Network Management Through Firewalls

2.2 Simple Network Management Protocol (SNMP)