Extending Network
Management Through
Firewalls
Stephen Hochstetler
Harry Tanner
Ramachandra Kulkarni
Sebastian Mika
Design Secure Network Management
Solutions
Secure Network Management
Communications
Best Practice for DMZ
Management
Extending Network Management Through Firewalls
June 2001
SG24-6229-00
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.
Before using this information and the product it supports, be sure to read the general information in Appendix G, “Special notices” on page 349.
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 . . . 3
1.1 TCP/IP preview . . . 3
1.1.1 Well-known ports . . . 4
1.1.2 High ports. . . 4
1.2 The concept of the firewall . . . 4
1.3 The components of a firewall . . . 5
1.4 Terminologies associated with the firewall . . . 7
1.5 Firewall architectures . . . 8
1.5.1 Screening router . . . 8
1.5.2 Bastion . . . 9
1.5.3 Dual-homed gateway . . . 9
1.6 Firewall objectives and firewall rules . . . 10
1.6.1 Beyond the firewall: filtering content . . . 11
1.7 Virtual Private Networks . . . 11
1.7.1 Case study of VPN . . . 12
Chapter 2. Network management . . . 17
2.1 Introduction . . . 17
2.2 Simple Network Management Protocol (SNMP) . . . 19
2.2.1 IP network communication . . . 21
2.3 Network management with NetView . . . 23
2.3.1 Centralized network management. . . 23
2.3.2 Distributed network management solution . . . 26
2.3.3 Remote network management access . . . 28
2.4 NetView as part of a Tivoli system management platform . . . 30
2.4.1 Tivoli Decision Support (TDS). . . 33
2.4.2 Tivoli Enterprise Console (TEC) . . . 34
Part 2. Network management environments . . . 39
Chapter 3. Management across a single firewall . . . 41
3.1 Introduction . . . 41
3.1.1 Definition of terms . . . 41
3.2 General description of the testing environment . . . 42
3.2.1 Tivoli NetView . . . 43
3.2.2 Tivoli Mid-Level Manager (MLM). . . 44
3.2.3 IBM SecureWay Firewall . . . 44
3.2.4 Other tools used . . . 45
3.3 Phase 1: Network management 101 . . . 46
3.3.1 General topology for Phase 1 . . . 46
3.3.2 Building network components for Phase 1 . . . 47
3.3.3 Conclusion for Phase 1. . . 53
3.4 Phase 2: Network management across a single firewall . . . 53
3.4.1 General network topology for Phase 2 . . . 53
3.4.2 Polling using SNMP . . . 70
3.4.3 Troubleshooting techniques . . . 71
3.4.4 NAT and firewalls . . . 77
3.4.5 Conclusion for Phase 2. . . 78
3.5 Phase 3: Distributed network management across firewalls . . . 80
3.5.1 General network topology for Phase 3 . . . 80
3.5.2 Introducing NetView Mid-Level Manager. . . 81
3.5.3 Installing Mid-Level Manager . . . 81
3.5.4 Configuring NetView . . . 83
3.5.5 Testing communications between NetView and MLM . . . 86
3.5.6 Analysis of results . . . 89
3.5.7 MLM remote installation . . . 91
3.5.8 Conclusion to Phase 3 . . . 97
3.5.9 Security considerations . . . 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.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 . . . 261
6.1 The eBusiness architecture . . . 261
6.1.1 The corporate network . . . 261
6.1.2 DMZ . . . 262
6.1.3 The Internet . . . 264
6.2 eBusiness network management architecture. . . 264
6.2.1 Discovery and configuration polling . . . 266
6.2.2 Internet connectivity . . . 268
6.2.3 Forwarding traps . . . 278
6.2.4 Tivoli Decision Support . . . 286
6.3 Consolidating enterprise network management . . . 288
6.3.1 Alternative solutions . . . 292
6.4 Conclusion . . . 296
Part 3. Additional information . . . 299
Appendix A. IBM SecureWay Firewall installation . . . 301
A.1 Prerequisites . . . 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 . . . 347
F.1 Locating the additional material on the Internet . . . 347
F.2 Using the Web material . . . 347
F.2.1 How to use the Web material . . . 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
Figures
1. Theoretical firewall environment8
2. Screening router9
3. Dual-homed gateways10
4. VPN case study13
5. Network management concept20
6. Network management with Tivoli NetView24
7. Distributed network management with NetView26
8. Remote access to network management system30
9. Tivoli system management structure31
10. NetView in connection with TEC and TDS33
11. Phase One topology for Scenario One47
12. IP routing on Windows NT 4.048
13. NetView IP map topology49
14. NetView for Windows NT IP map topology51
15. Phase 2 network topology for Scenario 153
16. SWF configuration client57
17. Network objects58
18. Creating network objects59
19. Network object group60
20. Creating a rule61 21. SNMP response rule63 22. Creating a service64 23. Service composition65 24. Adding a connection67 25. Connection details68 26. Connection control69
27. Netmon seed file editor71
28. Log facilities72 29. Adding log facilities72
30. Sniffer host placement76
31. Start packet capture76
32. Live capture and results77
33. CNAT and NAT78
34. Network topology and communications for Phase 380
35. NetView SNMP configuration for MLM85
36. NetView with APM installed86
37. MLM alias table87
38. MLM interface status table88
39. Packet capture for MLM traps to NetView89
41. MLM remote installation from the Tivoli Desktop. . . 92
42. MLM installation output . . . 92
43. MLM remote installation analysis - Part One. . . 93
44. Remote MLM installation analysis - Part Two . . . 94
45. MLM remote installation communication summary . . . 96
46. Network management in SP networks . . . 101
47. Test environment. . . 104
48. Distributed management with MLMs . . . 105
49. NetView in SP subnetworks . . . 106
50. Distributed management with NetView in one TMR . . . 108
51. Installation managed node from TMR server . . . 110
52. Installation NetView from TMR server . . . 113
53. NetView in unsecure networks with separate TMR . . . 115
54. NetView database integration in TDS analysis . . . 117
55. NetView database connection through firewall . . . 119
56. Oracle database connection rule. . . 121
57. Forward events with nvserverd . . . 125
58. Event forwarding administration from NetView to TEC . . . 126
59. TEC server configuration in NetView for UNIX . . . 127
60. Communications between NetView and TEC . . . 128
61. Dynamic rule configuration for RPC communication . . . 130
62. Sending events from NetView to a restricted TEC port . . . 132
63. Forward all events to TEC . . . 133
64. Configuration of trap forwarding . . . 134
65. NetView trapd configuration dialog box . . . 135
66. Forward specific events to TEC. . . 136
67. Definition of specific events . . . 137
68. Forward only rule passed events to TEC . . . 138
69. Communication NetView NT and TEC Server on NT . . . 141
70. Remote access to network management servers . . . 142
71. Communication between Java Web client and NetView server . . . 144
72. Telnet connection with subsequent export of X11 GUI . . . 147
73. X11 Forwarding through encrypted tunnel . . . 148
74. SSH test environment . . . 151
75. SSH authentication setup . . . 159
76. SSH port forwarding setup . . . 159
77. SSH session startup . . . 160
78. Running SSH session . . . 160
79. VPN main menu . . . 173
80. Tunnel definition . . . 174
81. Exporting the tunnel definitions . . . 176
82. Importing a tunnel definition at the partner firewall . . . 176
84. Activating the tunnel . . . 178
85. Client to site VPN . . . 179
86. Check Point FireWall-1/VPN-1 login panel . . . 180
87. Create new network object . . . 180
88. Defining network object of type network . . . 181
89. Workstation properties of the network object . . . 182
90. Defining network interfaces . . . 183
91. Authentication option for the workstation . . . 183
92. VPN parameters definition . . . 184
93. FWZ encryption properties . . . 185
94. Encapsulate the traffic . . . 185
95. User creation menu . . . 186
96. User creation and configuration . . . 187
97. User authentication definition . . . 188
98. User encryption properties . . . 188
99. FWZ properties configuration . . . 189
100. Creating the VPN rule (left half of the panel). . . 190
101. Creating the VPN rule (right half of the panel). . . 190
102. Policy install. . . 192
103. Policy installation . . . 192
104. Accepting unauthorized FWZ traffic . . . 193
105. Policy properties . . . 194
106. Create a site on the SecuRemote client . . . 195
107. SecuRemote client authentication . . . 196
108. Tracer Route example of encryption and encapsulation . . . 197
109. Telnet to a secure host . . . 197
110. Telnet to secure host . . . 198
111. VPN traffic - sniffer output . . . 199
112. Java Web client (normal communication, non-VPN) . . . 200
113. NetView Java Web client authentication . . . 201
114. Java Web client map options . . . 201
115. Sniffer output of the Java Web client after VPN implementation. . . 202
116. SecuRemote client behind a firewall . . . 203
117. Rule definition to allow ipip . . . 204
118. Rule definition to allow port 259 on the firewall . . . 205
119. Defining the service . . . 206
120. SecuRemote Connection 1 . . . 207
121. SecuRemote Connection 2 . . . 208
122. Regenerate the rules . . . 209
123. VPN client/server configuration . . . 210
124. Creating a new security policy. . . 211
125. Security Policy creation wizard . . . 212
127. Request for secure communication . . . 213
128. Policy Wizard - Edit panel . . . 213
129. Policy properties . . . 214
130. Tunnel end point definition . . . 214
131. Policy network type . . . 215
132. Policy authentication methods. . . 215
133. IP filter list addition . . . 216
134. IP filter addition . . . 217
135. Filter wizard . . . 217
136. IP traffic source definition . . . 218
137. Traffic destination . . . 218
138. IP protocol type . . . 219
139. IP filter wizard . . . 219
140. Complete filter rule creation . . . 220
141. IP filter list . . . 221
142. Filter action . . . 222
143. Filter action wizard . . . 222
144. Filter action name . . . 223
145. Filter action general options . . . 223
146. Communication with non-IPSec computers. . . 224
147. IP traffic security . . . 224
148. Filter action wizard . . . 225
149. Filter action selection. . . 226
150. Security rule wizard . . . 227
151. IP security rules . . . 227
152. Assign the rule to the system . . . 228
153. Filter properties of the client . . . 229
154. Sniffer output of the ping packet from the client to the server . . . 230
155. VPN configuration panel . . . 232
156. IP security start options dialog . . . 233
157. Internet key management application . . . 233
158. Key management tunnel properties panel. . . 234
159. Key management policy panel . . . 235
160. Key policy property panel . . . 236
161. Key management proposals . . . 237
162. Key management proposals properties. . . 238
163. Transform properties panel . . . 239
164. Key management proposals properties after transform definition . . . 240
165. Key management policy panel after proposal definition . . . 241
166. Key management policy panel after policy definition. . . 242
167. Key management authentication method . . . 243
168. Internet Key Management Application after key tunnel definition . . . 243
170. Data management tunnel endpoint definition . . . 245
171. Data management policies . . . 246
172. Data management policy property panel. . . 247
173. Data management proposals panel . . . 248
174. Data management proposal definition. . . 249
175. Transforms properties definition dialog . . . 250
176. Data management proposal panel after proposal definition . . . 251
177. Data management proposals panel after new proposal definition. . . 252
178. Data management policies after new policy definition. . . 253
179. Data management options . . . 254
180. Internet Key Management Application after key tunnel definition . . . 254
181. Define the rule for IKE communication . . . 256
182. Define the rule for ESP communication. . . 257
183. Define the service for VPN rules . . . 258
184. Define the connection for the VPN . . . 259
185. The Prime Model . . . 262
186. The Primary Network Management model (PNM). . . 265
187. DMZ discovery and configuration polling. . . 266
188. NetView IP Internet submap . . . 269
189. Object creation . . . 269
190. Internet Access object group properties . . . 270
191. Internet Access group . . . 271
192. Internet map after loadhosts command executed . . . 273
193. Relocating Internet networks to the Internet Access submap . . . 274
194. Changing symbol properties . . . 275
195. Internet management submap . . . 276
196. Internet Access disabled . . . 277
197. Sample Internet connectivity events . . . 277
198. Trap settings for NetView NT . . . 279
199. Internet Access management . . . 281
200. Performance management of exterior router without SNMP access. . . 283
201. Performance management of exterior router with SNMP access . . . 285
202. Sample router MIB-II report showing serial interface throughput . . . 286
203. Tivoli Decision Support for the enterprise . . . 287
204. VPN for secure communications . . . 289
205. Sending DMZ events directly to TEC . . . 292
206. Alternative Solution 2 - DMZ MLM. . . 295
207. Using MLM under NetView to filter traps . . . 296
208. Enable IP forwarding . . . 302
209. Installing IBM Intermediate Support Driver . . . 302
210. Insert disk for Support Driver. . . 303
211. Select IBM Intermediate Support Driver . . . 303
213. SecureWay Welcome . . . 304 214. Select components . . . 305 215. License agreement . . . 305 216. Installation options. . . 306 217. Confirm settings . . . 307 218. Setup in progress . . . 308
219. Hardening the system . . . 308
220. Installation summary . . . 309
221. Check Point 2000 welcome . . . 312
222. Check Point 2000 license agreement . . . 312
223. Check Point 2000 product menu . . . 313
224. Server/Gateway components selection . . . 314
225. Setup type . . . 315
226. Gateway/Server module . . . 315
227. Backward compatibility screen . . . 316
228. Destination location for firewall modules . . . 317
229. Destination location for management client. . . 317
230. Management client dialog . . . 318
231. Destination location for reporting server . . . 319
232. Reporting server modules . . . 319
233. Reporting server mail settings . . . 320
234. Web server settings of reporting server. . . 321
235. Destination location for reporting client . . . 321
236. Reporting client modules . . . 322
237. Firewall license installation . . . 323
238. Administrators dialog . . . 324
239. Firewall IP-Address . . . 324
240. Configuration of GUI clients . . . 325
241. IP Forwarding dialog . . . 326
242. Key Hit session . . . 327
243. Setup complete . . . 328
244. SecuRemote Installation Welcome panel . . . 330
245. SecuRemote license agreement . . . 330
246. Existing version dialog box . . . 331
247. SecuRemote installation directory . . . 332
248. SecuRemote Desktop Security . . . 332
249. SecuRemote Network Bindings. . . 333
250. SecuRemote setup complete . . . 334
251. Control Panel. . . 342
252. Local Area Connection . . . 342
253. Local Area Connection properties . . . 343
254. Installing Network Component . . . 344
256. Select Driver for WinCap . . . 345 257. WinCap driver installed . . . 346
Tables
1. Comparing various gateways. . . 7
2. SNMP protocol. . . 21
3. NetView status polling . . . 24
4. MLM communication in distributed management . . . 27
5. FW1 Firewall configuration for Phase Two . . . 55
6. Service and rule Configuration for Phase 2 . . . 79
7. Connections and services for Phase 2 . . . 79
8. Service and rule configuration for MLM traps to NetView . . . 90
9. Connection for MLM traps to NetView . . . 90
10. Service and rule configuration - MLM remote installation from NetView . . 95
11. Connection for MLM remote installation from NetView . . . 95
12. General communications for MLM remote installation . . . 96
13. Communication rules for distributed management with MLMs . . . 105
14. Firewall rule for installation of management node . . . 112
15. Firewall rule for NetView installation on managed node . . . 113
16. Firewall rule for NetView connection to database server. . . 118
17. Oracle databases. . . 119
18. Firewall rule for NetView connection to Oracle database . . . 120
19. Firewall rule for RPC communication . . . 129
20. Firewall rule with restricted TEC reception port . . . 132
21. Firewall rule for NetView connection to Oracle database . . . 135
22. Firewall rule for NetView NT communication with TEC NT . . . 141
23. Communication rules for Web client to NetView server . . . 146
24. Communication rule for SSH connections . . . 150
25. Firewall rule for SSH test lab . . . 161
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 Tivoli’s 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
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
management tools. He has also been leading the development of network management systems for IBM’s 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
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
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 Tivoli’s 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 por ts
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
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.
Firewall (FW) A combination of hardware and
software, with the help of expertly built Particulars Application level
Gateway
Circuit level Gateway
Operates in OSI Layer Application Transport through session Require proxies for each
service
(for example, HTTP, FTP, and so on)
Yes No
TCP/IP Translation Done at the Proxy Done at the client
Logging Provided Usually no logging
Modified Client Required No Yes
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.
Dual homed host A general purpose computer which has at least two network interfaces.
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.
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
10.69.14.X
DMZ Router
Internet
Firewall Secure Network
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.
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,
10.69.14.X
Secure Network
Screening Router
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.
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.69.14.X
Internet Secure Network
• 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)
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
Transport Mode 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.
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.
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 client’s 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.
Mail Server Intranet Server VPN Gateway
Remote employee with IpSec client Internet
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
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.
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.
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 today’s 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.
The NetView network management platform, which is part of the Tivoli’s 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.
You can find the RFC (Request For Comment) documents on following Web sites:
•www.rfc-editor.org •www.rfc.net
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.
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 Network Management System NMS Console NSD Agent Agent Agent Agent Server Switch Client Router
• 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 Tivoli’s 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 Source Destination Protocol Source- Port
Dest- Port SNMP-
Request
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.
SNMP- Reply SNMP- Agent NM station UDP >1023 161 SNMP-Trap SNMP- Agent NM station UDP >1023 162 Function Source Destination Protocol Source-
Port
Dest- Port
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.
Figure 6. Network management with Tivoli NetView
The network management system uses the SNMP protocol and Cisco’s 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 Source Destination Protocol Source - Port Dest.- Port SNMP- Request NetView SNMP-Agent UDP >1023 161 SNMP- Reply SNMP-Agent NetView UDP 161 >1023 SNMP Agent SNMP Agent NetView LAN/WAN Database SNMP Agent SNMP Agent SNMP Agent
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
SNMP- Trap SNMP- Agent NetView UDP >1023 162 Ping- Request NetView Network objects ping/ICMP 0 8 Ping- Reply Network objects NetView ICMP echo-reply 8 0
Function Source Destination Protocol Source - Port
Dest.- Port
