Table Of Contents
Biomedical Network Admission Control (BNAC)
Biomedical NAC Solution Overview
Challenges Experienced in Hospitals
Biomedical NAC Solution Services
Access Control and Enforcement
Cisco Infrastructure Access Switches and Routing
Endpoint Attributes for Profiling
Profile Graduation and Certainty Factors
Strategies for Profiling Medical Devices
Medical Device Communication Flows
Patient Monitoring Systems Description
Sample Profiles for Philips MP50 IntelliVue
Philips Behavior Monitoring Profile
Dräger Infinity Patient Monitors
Sample Profile for Dräger Infinity
Dräger Behavior Monitoring Profile
Analyzing How the Device Works on the Network
Discover Profiling Attributes for New Medical Device
Implementing the BNAC Solution
Basic Pre-Planning Considerations
Establishing Connectivity Between the NAC Appliances
Adding the NACS(s) into the NACM
Creating the Biomedical Device Profiles
Creating a NAC Event and Map Event to the Profile and the NAC Role
The Profiler Service Command Set
HA System Considerations for Service Profiler Commands
Database Restore on Standalone (non-HA) Systems
Database Restore on HA Systems
Upgrading Profiler System Software
Example: Upgrading the Profiler Version
Example: Upgrading the Collector Versions
Using WinSCP to Move Upgrade Files to Servers
Biomedical Network Admission Control (BNAC)
Revised: July 7, 2009
Contents
Biomedical NAC Solution Overview
Executive Summary
Hospitals continue to spend millions of dollars on upgrading their network infrastructure and/or building new wings to their existing acute care or ambulatory care environments. Internet Protocol (IP) convergence is slowly but steadily becoming a reality and customers are demanding an environment whereby they can improve quality of patient care and at the same time reduce overall expenses. Many hospitals have or are moving towards a converged IP network and as such they are looking at ways to connect Information Technology (IT) devices, biomedical devices, and guest services on a converged IP network in a secure and reliable manner.
Currently, there is no effective solution in the market that can automate the process of dynamic endpoint identification and provisioning of end-device with the appropriate security measures. There is a clear pain point among healthcare customers and Cisco has a unique opportunity to help address this business need.
The primary goal of this solution is to implement Biomedical Network Admission Control (BNAC) that automates device assignments to controlled zones on the hospital's wired network. The secondary aspect of this solution is to proactively monitor the behavior of these devices and provide the network administrator with visibility into how these devices are behaving on the network. This document describes the specific features and benefits that hospitals and care providers can take advantage of to reduce IT operational cost and improve overall patient care.
In order to understand the specific solution requirements, it is important to learn some of the business dynamics that are driving the need for the solution. Figure 1 illustrates a growing market trend of a converged biomedical network.
Figure 1 Converged Network
Biomedical devices such as patient monitoring (PM), ventilators, infusion pumps are the fastest growing population of network connected devices (wired or wireless) in the provider space. For example, some larger healthcare providers expect to have 150,000 biomedical devices on the converged IP network in the next 3 to 4 years. Medical Device Manufacturer's (MDMs) continue to introduce devices that are IP-enabled and this trend continues to pick up momentum. Hospitals use a variety of these biomedical devices. As increasingly number of biomedical devices become IP-enabled, hospitals are looking at ways to maximize their use in the most effective and economical ways.
According to the American Hospital Association's (AHA) hospital statistics, in 2002 there were 5,810 hospitals in the United States. The smaller hospitals have less of a need to implement a solution as the hospital biomedical/IT group may prefer to implement the port provisioning (for example, for wired connectivity) manually. The smaller hospital may also have fewer biomedical devices and as such it is less of a concern for tracking these devices or connecting them to the network.
Based on the customer feedback obtained, the ideal target hospital is one with over 100 beds, with the optimum being between 200 to 450 beds. The larger (100 beds and up) hospitals will have a large number of biomedical devices and for them to manually connect IP-enabled devices onto the network is economically unfeasible.
Solution Description
The BNAC is a solution that integrates the Cisco NAC Appliance and NAC Profiler components into an existing healthcare campus network. The solution automates the process of connecting wired biomedical devices to the hospital's existing infrastructure network. Once this end-point device is connected, the network will continuously monitor its behavior to make sure the device is working and behaving correctly. If the behavior is different than expected, system will alert and/or report the information to the IT administrator. The administrator can then intervene and choose to segregate the device accordingly. Figure 2 illustrates the basic wired communication flow for the solution.
Traditionally, the Cisco NAC Appliance has been used in the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources. The Cisco NAC Appliance allows network administrators to authenticate, authorize, evaluate, and remediate wired, wireless, and remote users and their machines prior to network access.
The BNAC solution focused on testing defined medical device endpoints for admission control dynamic profiling and access port provisioning. The solution is architected to co-exist with the traditional NAC features described above, but focused only on the testing of biomedical device endpoints. The solution uses existing NAC architectures provided by other product and solution-level testing; specifically the Wireless and Network Security Integration Solution Design Guide (http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/secwlandg20/sw2dg.html).
There is a clear business need for a solution that allows hospitals to use any biomedical or IT devices on a common network infrastructure by connecting that device to any port in a hospital (for wired communication).
Challenges Experienced in Hospitals
The following are real-world examples that were received from Cisco healthcare customers:
Problem Scenario #1: (Wired - Security)
1.
A family member of a patient who is looking for an Internet connection, plugs an infected laptop into a bedside wall jack that is reserved for medical devices.
2.
Problem Scenario #2: (Wired - Provisioning)
1.
2.
3.
Problem Scenario #3 (Wired - Provisioning and Reporting)
1.
2.
3.
There is a business problem whereby customers are looking for effective ways where they can automate the process of getting a given end-device—biomedical or IT —onto the network without going through the manual process, which is a very common approach in the healthcare industry today. Hospitals do not want to manage multiple disparate networks nor do they want to provision a port manually because of the added cost and delays encountered.
Healthcare organizations want to use a single unified converged IP network whereby the IT devices, biomedical devices, and guest services can run on the same network. In this setting, they want to accomplish the following:
•
•
•
Given the number of MDMs and type of biomedical devices, we have prioritized the partner engagement and functionality. We have targeted patient monitoring equipment such as Philips and Dräger and are targeting wireless devices, including infusion pumps from Cardinal Health, in future releases of the solution.
Target Market
Solution Benefits
Biomedical Network Access Control (BNAC) is a Cisco healthcare solution that addresses the following key challenges:
•
Enable the ability to connect patient monitors to different bedside wall jacks (switch ports) within the hospital and allow the network to automatically identify the device type and vendor. Upon device identity, the network will reprovision the associated port to the correct segment of the network.
•
Allow port access to only approved patient monitors through profiling process. Upon correct port access assignment, continuously monitor the device behavior. On compliant behavior, graduate and report a higher confidence factor. On potential bad behavior, lower the confidence level and alert the administrator for further action.
•
Present graphic interface of profiling events that occur on the network and have the ability to send event changes such as profile matches to a central network management plane.
Scope of Solution
This release of the BNAC solution focuses on wired patient monitoring devices.
Future releases of the solution will target wireless devices including Cardinal Health infusion pumps, GE patient monitor devices, and the inclusion of wireless guest services. Inclusion of these devices depends on vendor participation and availability.
This Application Deployment Guide (ADG) details the specific use cases, architecture, component configurations, and implementation details of the solution. The guide does not include implementation details on specific vendor patient monitor devices. Consult with the medical device vendors for specifics on product specifics.
Note
Medical Device Overview
There are many types and vendors of biomedical devices available in the market. The biomedical devices that are candidates for inclusion in future releases of the solution are as follows:
•
•
•
•
•
•
•
•
•
Inclusion of vendors in future releases of the BNAC solution will be based on priority. The top biomedical manufacturers are listed in Figure 2.
Figure 2 Biomedical Device Landscape
In Figure 2 above, the solid versus partially filled red circles indicate the concentration level of each vendor's product lists.
Biomedical NAC Solution Services
BNAC Services
The BNAC solution consists of the following key areas of functionality:
•
Device Identity
Device identity is the process of determining what type of endpoint is being added to the network. Biomedical devices such as patient monitors are typically "headless", sealed devices and are not capable of running any form of third-party authentication agents, 802.1x supplicant, or a NAC client. In addition, they do not provide a means by which a user can manually intervene through a browser.
To properly identify these types of devices, the BNAC solution gathers specific endpoint attributes to determine, within a certain level of confidence, the type of endpoint. The solution is flexible to allow the gathering of different types of attributes to determine an overall "confidence" level in identifying a device.
The device identity process involves recording a network endpoint's attributes and observable behaviors and analyzing its identifiable characteristics in order to classify it to a particular group. The MAC address attribute is typically used to identify the devices.
Access Control and Enforcement
Access control and enforcement is the network access provisioning process to allow or restrict access of devices onto the network.
As devices connect to the network, the BNAC solution will follow a specific process to enforce network access policies. In the BNAC solution, the NAC Manager performs SNMP set commands to the relevant access switch dynamically, changing the configuration of the particular switchport. For example, if access control is granted based on an endpoint profile match, the NACM will set the particular switch port to be a member of the proper medical device VLAN. If there is no medical device profile match, the NACM will assign the port to an authentication VLAN and no access is granted to the medical VLAN.
Behavior Monitoring
Behavior monitoring is the on-going process of monitoring the behavior of an endpoint over time after the device has been allowed network access.
Non-authenticating or non-NAC endpoints, such as patient monitors and infusion pumps, need to be monitored over time to ensure that their behavior is consistent with their known device type. Typically, medical device endpoints cannot authenticate or participate in network admission control.
When these medical device endpoints begin to exhibit known behaviors, such as communicating over a known set of ports to a centralized station, the behavior monitoring function will detect this. This well known behavior can be reported via the GUI or logged to a management system to indicate that there is a high degree of confidence that a proper device has accessed the network. This type of behavior monitoring acts as a another layer of identity detection, since MAC spoofing can be used to gain unauthorized network access.
The Cisco NAC Profiler's Behavior Monitoring continuously collects and analyzes behavior information for all endpoints using the network. When the behavioral attributes of an endpoint change, the NAC Profiler engine evaluates whether or not the behavioral changes warrant a change in the profile of the endpoint. If a change in the profile is warranted, NAC Profiler will "transition" the endpoint to a higher confidence profile and provides alerts to network and security management. This can alert for an administrator to change the network access provided by the authentication or NAC system to deny access to the suspect device. In this way, Cisco NAC Profiler can automatically counter attempts to thwart the edge security system.
Whereas endpoint profiling provides automated population of exception lists or white lists to accommodate non-authenticating and non-NAC nodes, behavioral monitoring provides an additional security mechanism as well as automated ongoing management of these critical elements of network authentication and admission control systems. The behavior monitoring functionality of NAC Profiler adds a second credential to the known and authorized non-authenticating or non-NAC endpoints, that of a behavioral signature to ensure that the MAC address of these devices cannot be exploited as a means to bypass network authentication or admission control.
Visibility and Reporting
Visibility and reporting is the process of providing the administrator with real-time/batch information on device identity, access control, and behavior monitoring. The Cisco NAC Profiler user interface provides the ability to view and manage the endpoints connecting to the enterprise network. The Endpoint Console tab of the User Interface provides several views of the endpoint data that allow for the display of information about the endpoints, current and historical, as well as information regarding the connection status of all endpoints in the environment.
The different views provided in the Endpoint Console provide the primary user interface for monitoring the endpoint profiling and behavior monitoring functionality of Cisco NAC Profiler. Several options are provided for viewing the current state of the profiles and endpoints for both the directory and port provisioning modes of the system. The views themselves provide insight into the endpoint landscape, the effectiveness of the profiles to classify all endpoints being observed on the network as well as providing the ability to drill-down into current and historical information collected by Cisco NAC Profiler on each endpoint. In addition, summary information regarding the profiles enabled for population by Cisco NAC Profiler into the Cisco NAC Appliance can be ascertained at-a-glance.
The profiler events functionality provides for four event types: newly profiled, MAC change, profile change, and NAC events. The events are created and can be configured to alert network and operations staff, through SNMP traps to the network management system (NMS), syslog entries on the NAC Profiler, and another syslog server on the network.
Solution Architecture
The solution architecture (see Figure 3) identifies the key solution components, integration points, and relevant configurations.
Figure 3 Biomedical NAC Overall Architecture
Architectural Scope
The architecture solution described in Figure 3 above is divided into four main functional areas: devices, access, distribution, and core.
Access Layer
Cisco IOS-based Catalyst switches are deployed at the hospital edge for wired access. The switches are typically deployed at the IDF distribution closets located in the various bedside wings of the hospitals. Ethernet jacks are distributed to each of the wiring closets.
The following are the NAC Appliance-supported Cisco switch platforms:
•
•
•
•
•
•
•
The switches that have medical devices are required to be under NAC control. For general NAC deployments requiring posture assessment for IT devices including PCs, the switches will also need to be NAC-enabled. For details on how switches become NAC-enabled, refer to Implementing the BNAC Solution.
Switches participate in the following functions of the solution:
•
•
Note
Distribution Layer
The distribution layer of the healthcare campus network contains Cisco IOS-based Layer 2 and Layer 3-based switches and routers. The distribution switches/routers components participates in the profiling process through the following functions:
•
•
•
The distribution layer may typically also include the Patient Monitoring Central Station (CS). The CS works to aggregate the vital signs data sent from the patient monitors at the access layer. In addition, the NACS is typically deployed at the distribution for wire out-of-band deployments. Both the trusted and untrusted interfaces of the NACS connect to the distribution switch.
Core
The core layer uses Cisco IOS-based routers in the healthcare campus network. The core is reserved for high speed routing, without any services. Services can be placed in a service switch on the data center.
Data Center Services Layer
The data center layer uses Cisco IOS-based routers/switches in the healthcare campus network. The data center components participate in the following functions:
•
•
•
The primary NAC Appliance and profiler components are deployed in data center layer and/or distribution layer.
NAC Appliance Components
The key components that enable the hospital network to become NAC controlled is the NAC Appliance products. The NAC Appliance product consists of the following components:
•
Administration server and database for clean access deployments. Centralized configuration and monitoring of NAC Servers controls the switch VLAN assignments of access ports through SNMP in out-of-band deployments.
•
Enforcement server between the untrusted (managed) network and the trusted network. The NACS enforces the polices defined in the NACM. The NAC Collector modules are run off the NACS.
•
Gathers all of the relevant data about the endpoints and aggregates that information to profiler server. NAC Collector modules reside on the NACS.
•
Server that discovers, catalogs, and profiles all endpoints (Biomedical, IT, and Guest) connected to the network. Product is OEM'd from Great Bay Networks.
Access Switch Modes
In order to support the common access deployments that will be used in a healthcare network, this solution supports three access methods. Switches at the access may be configured in the following three switch mode types:
•
•
•
Figure 4 illustrates three deployment modes that are common in many healthcare organizations.
Figure 4 Three Healthcare Deployment Models
•
•
•
The CS can be deployed either at the distribution switch or at the data center.
Type 1: Layer 3 at the Edge
Figure 5 shows the Type 1 access deployment model. In the Type 1 access, a Layer-3 switched virtual (SVI) is configured on the access switch. The access VLAN (ie., VLAN 110) is configured on the medical device ports. Layer 3 routing is supported from the switch to the upstream distribution switch/router.
The CS can be located either in the distribution or the core. Medical devices communicate with the CS across a Layer-3 boundary using standard IP routing. For Dräger implementations, medical devices communicate with each other over Layer 3 multicast.
Figure 5 Type 1 Deployment Model
Type 2: Layer 2 at the Edge
Figure 6 shows the Type 2 access deployment model. In the Type 2 access, a Layer 3 SVI interface is configured on the upstream distribution switch. The access VLAN (ie., VLAN 110) is configured on the medical device ports, and there are only Layer 2 accesses at the switch (no Layer 3 routing). The access VLAN is trunked upstream to the distribution switch.
For medical device implementations that support Layer 3 routing, the CS can be located either in the distribution or the core. Medical devices communicate with the CS over Layer 3 routing. For Dräger implementations, medical devices communicate with each other over Layer 3 multicast.
Figure 6 Type 2 Deployment Model
Type 3: Layer 2 End-to-End
Figure 7 shows the Type 3 access deployment model. In the Type 3 access, there is no Layer 3 interface configured. The access VLAN (ie., VLAN 110) is configured on the medical device ports and this Layer 2 VLAN is trunked through the network. This Type 3 is required for Layer 2 adjacent-only implementations of patient monitoring where the devices can only communicate to the central stations and/or other devices through Layer 2.
For medical device manufactures that support a Layer 2 implementation, the CS is located on the same VLAN as are all of the patient monitors. This implementation is not supported by Dräger.
Figure 7 Type 3 Deployment Model
NACS Modes
In Cisco NAC Profiler, the collector function is collocated on the Cisco NAC Appliance and provides the NAC Server (NACS) services. The way the collector functions, specifically which component modules are enabled and how they are configured, depends on the specifics of the Cisco NAC Appliance deployment. The solution should support both out-of-band and in-band NACS modes.
Keeping the above considerations in mind, there are four possible NACS operation modes:
•
•
•
•
The choice of deployment model has implications on how the collector and the underlying component modules are able to gather and process endpoint profiling and behavior monitoring data from endpoints and the network infrastructure. Understanding these implications prior to the deployment and configuration of collectors is crucial to a successful deployment.
Out-of-Band (OOB) Mode
With the Cisco NAC Appliance OOB deployment, the NACS is inline with user traffic only during the process of authentication, assessment, and remediation. Following that, user traffic does not pass-through the NACS. In OOB deployment, the NAC Manager (NACM) uses SNMP to control switches and set VLAN assignments for ports. When the NACM/NACS is set up for OOB, the NACM can control the switch ports of supported switches.
The typical use of OOB mode is primarily for wired deployments. This release of the BNAC solution focuses on this type of NACS deployment.
In-Band (IB) Mode
With Cisco NAC Appliance IB deployment, the NACS is always inline with user traffic before, during, and after authentication, posture assessment, and remediation. The typical use of IB mode is primarily for wireless and VPN deployments. This deployment guide does not cover IB type deployments.
The references to these PINs are listed in Table 1.
Table 1 References for PINs
ESE Campus Design
3.0
http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html#anchor2
Secure Wireless
2.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/secwlandg20/sw2dg.html
Security Baseline
1.0
http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html#anchor2
BNAC Solution Components
NAC Components
Table 2 lists the NAC components of the solution.
Cisco Infrastructure Access Switches and Routing
Table 3 lists the access switches and routers in the solution.
Table 3 Access Switches and Routers in the Solution
Access Switch
Cisco Catalyst 6500, 4500, 3750, 3750-E, 3560, 2960, and 2950
Access switches used in wired deployments
Complete listing of switch support:
http://www/en/US/docs/security/nac/appliance/support_guide/switch_spt.html
Minimum IOS Version:
http://www/en/US/docs/security/nac/appliance/support_guide/switch_spt.html
Routers
4500 and 6500
Routers and switches used in wired deployments at distribution and core layer
Medical Devices
Table 4 lists the medical device components of the solution.
Other
Table 5 lists additional components of the solution.
Table 5 Additional Solution Components
DHCP Server
External DHCP Server
Server to provide IP addresses to the bedside patient monitors
N/A
BNAC Design and Profiling
High Level Flow
The areas of functionality follow a logical sequence of events as depicted in Figure 8.
Figure 8 High-level Logical Flow
A sample medical device endpoint flow is as described in the following steps for each of the functional area shown in Figure 8.
Device Identity
Step 1
Step 2
Step 3
Step 4
Step 5
Access Control and Enforcement
Step 6
Step 7
Behavior Monitoring
Step 8
Step 9
Reporting and Visibility
Step 10
Step 11
NAC Server Placement
For wired deployments, the preferred method of the NAC Server mode is out-of-band (OOB) mode. This is preferred because both user IT devices and medical devices will be deployed behind access switches.
Traditional NAC Appliance functionality enforces corporate host security policies on users and hosts accessing the network. NAC can leverage existing security technologies, such as antivirus, antispam, and operating system updates to ensure that user machines are current with the latest patches. A typical PC would be required to install a Clean Access Agent to gather information about the user and the PC/host. The process of evaluating the software on the PC is typically referred to as posture assessment. The NAC system can assess and authorize users according to the compliance of the user's PC.
For these IT devices, the NAC Server will only be inserted in the path of the user during this posture assessment and quarantine period. Once the users have been authenticated, the NAC Server will be placed out-of-band.
Medical devices typically do not support any agents and/or 802.1x supplicant, and they are not subject to posture assessment. Medical devices, however, will use the the profiling methods described in this deployment guide, and support OOB NACS modes.
OOB mode uses switch port-level VLANs. While medical devices are first being identified, the ports are configured for the authentication VLAN. This prevents any unknown devices from getting access to the production VLANs. Once the devices have been identified through the identity profiling process, the port will be auto-provisioned for the correct medical device VLAN for that particular device.
For medical devices that attach to the access switches, there is no true posture assessment functions. The devices will however need to be identified through use of the profiling functionality, and the OOB band works well for medical devices as well.
The following two NAC Server OOB modes are supported in the BNAC solution:
•
•
The in-band mode for NAC Server traditionally is reserved for wireless and VPN deployments. This version of the BNAC solution covers only wired devices, and therefore will not use the in-band modes of operation.
OOB Layer 2 Virtual Gateway
The OOB Layer 2 Virtual Gateway model supports access deployments where access switches are configured for Layer 2 connectivity. Figure 9 illustrates this mode.
Figure 9 Out-of-Band Layer-2 Virtual Gateway
For the design shown in Figure 9, role-based VLAN assignments are used. For example:
•
•
•
•
Based on the devices plugged into the switchport, the port will be auto-provisioned to be configured to the appropriate VLAN.
The following is a sample configuration for the access switch:
!interface FastEthernet0/5description PATIENT MODE SWITCH PORTswitchport access vlan 6switchport mode accesssnmp trap mac-notification added!interface FastEthernet0/10description TRUNKswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 6-8,10switchmode trunk!The following is a sample configuration for the distribution switch:
!interface FastEthernet1/0/5description TRUNKswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 6-8,10switchport mode trunk!interface FastEthernet1/0/4description Untrusted Portswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 6switchport mode trunk!interface FastEthernet1/0/3description Trunsted Portswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 99 (for NACS Management)switchport mode trunk!interface vlan 7description PhilipsIp address 77.1.1.1 255.255.255.0!interface vlan 8description DrägerIp address 88.1.1.1 255.255.255.0!interface vlan 10description EmployeeIp address 99.1.1.1 255.255.255.0OOB Layer 3 IP Gateway
The OOB Layer 3 IP Gateway model supports access deployments where access switches are configured for Layer 3 connectivity. Figure 10 illustrates this mode. This mode can be used only if NAC posture assessment is not required, and device profiling is the main requirement and/or if the specific design requires an OOB Layer 3 NACS setup.
Figure 10 Out-of-Band Layer 3 IP Gateway
NAC Design
NAC Profiling Design Overview
The NAC Profiler classifies or profiles each endpoint it discovers and locates on the network into exactly one profile according to the passive and active profiling mechanisms of the endpoint profiling engine. Each profile is a logical container or grouping that contains one or more endpoints with similar behavioral-based characteristics (for example, Vendor A patient monitors, Vendor B patient monitors, etc.) and similar ability to comply with the authentication, NAC or other requirements placed on the endpoints in a network.
The NAC Profiler uses collector modules that allow collect and injest the relevant endpoint data. The collector modules include:
•
•
•
•
•
The modules come installed on the NAC Server or can be housed in a separate collector server. For more detail on collector modules, refer to "Collecting the Data" section.
NAC Profiler classifies or profiles each endpoint it discovers and locates on the network into exactly one profile according to the profiling mechanisms of the endpoint profiling engine. Each profile is a logical container or grouping that contains one or more endpoints with similar behavioral-based characteristics (for example, Vendor A patient monitors).
Cisco NAC Profiler performs dynamic endpoint profiling. Endpoint profiling identifies and locates each endpoint on the network, groups those endpoints according to their capabilities or limitations, then allows accommodation of non-authenticating or non-NAC endpoints through a selection of mechanisms: interacting with the network infrastructure directly to allow manual reprovisioning or acting as a directory of non-authenticating or non-NAC capable endpoints.
Cisco NAC Profiler's endpoint profiling is inherently dynamic and can detect changes at the network edge resulting from network adds, moves, and changes. New MAC address or profile change events can be used to alert network or security operations and to enable re-provisioning required to effectively support moves, adds, and changes in the authenticated or admission controlled network.
Endpoint Attributes for Profiling
The NAC Profiler supports the attributes shown in Table 6 to profile a particular endpoint.
Table 6 above illustrates the basic identity attributes that the NAC Profiler supports to build profiles on. These attributes can be grouped into three basic areas as shown in Figure 11. For example, a sample profile can be build using the traffic flow attributes of destination port and destination IP address. Either SPAN or NetFlow data would be examined to determine if there is a traffic flow match. This data would then be sent to the NetWatch/NetRelay/NetFlow collector modules.
Figure 11 Endpoint Attributes
Creating a Profile
Profiles are created using the GUI on the NAC Profiler (see Figure 12). Cisco NAC Profiler performs the endpoint profiling function by aggregating identifying attributes of an endpoint and its behavior to ascertain the device's type. The accuracy of endpoint profiling performed by Cisco NAC Profiler is reflected in a measure of certainty or confidence level that the device is currently in the correct profile. Each rule when created/added to an endpoint profile is assigned an individual certainty value that is reflective of how well the rule testing true predicts that the device belongs to the profile the rule is bound to.
Figure 12 Profile Creation
Rules are created using the Add Rule set of submenus shown in Figure 12. For example, click on the Traffic button to configure a traffic matching rule.
Figure 13 illustrates the rule created using the following traffic attributes:
•
•
•
•
•
Figure 13 Sample Traffic Attribute
A device graduates into only one profile at any given time based on one or more rules that have been tested to be true based on observation by the Cisco NAC Profiler system. The certainty values are not hard-coded because the relative certainty for different kinds of behavior vary from one enterprise network to another. In general, the rules added to a profile should be architected so that the more compelling aspects of an endpoint's behavior cause the certainty value to increase more than the less compelling attributes of the machine or its behavior. This ensures that the identity of the device will be driven more by the unique characteristics of its own type as opposed to attributes that might be shared with other device types.
Profile Graduation and Certainty Factors
The MAC address of an endpoint is often useful as a starting point in identifying the endpoint type; however, this value is easily copied (i.e., spoofed) by someone wanting to gain unauthorized network access. As a result, a best practice in constructing the rules used in endpoint profiles is to assign lower certainty values for the MAC vendor rule, while providing higher certainties to rules of other rule types such as protocol behavior, OS behavior, or DHCP vendor class. These identifiable aspects of endpoint behavior are inherently more complex, and hence more unlikely to be used in attempts to gain unauthorized network access, and therefore are more likely to result in an accurate endpoint profiling of end stations of that type. See Figure 14.
Figure 14 Endpoint Profiling
For profiles containing a single rule, the profile certainty factor (CF) equals the certainty for the single rule. When multiple rules are added to a profile, the following algorithm is used to create a combined certainty value for all rules in the profile that test true for given endpoint:
Current CF = (newCF*(1-currentCF)
Figure 15 shows a sample profile of a medical device with MAC address 00:09:fb:0a:c2:13 that has first matched the patient monitor profile called A - Philips Identity. Based on assigned this profile, the certainty factor was 20 percent. A new profile was matched at a later time called A - Philips Behavior Mon, which used a stronger profiling criteria. The CF is now 91 percent based on the matching algorithm as described in the above formula.
Figure 15 Summary Information for MAC Address 00:09:fb:0a:c2:13
Rule Types
The Cisco NAC Profiler rules provide several ways in which to classify endpoints with specific attributes into an endpoint profile. The option of adding multiple rules of multiple rule types to a given profile is supported. The rules used in constructing endpoint profiles can use a number of different criteria that range from Layer 2 to Layer 7 information that can be gleaned by the collectors from endpoint traffic or other sources of information described in this document. The available Cisco NAC Profiler rule types are as follows:
•
•
•
•
•
•
When multiple rules are configured for a profile, each is assigned a certainty value. It is important to understand that traffic matching both rules will never produce a combined certainty in excess of 100 percent. For example, two 80-percent certainty rules being matched will not yield a 160-percent certainty or even a 100 percent certainty. The result will be much higher than 80 percent (96 percent, to be exact in this case), but not equal to or greater than 100 percent. Additionally, it is important to understand that endpoints do not need to match all rules in order to be classified by Cisco NAC Profiler into a given profile. When multiple rules are included in a profile, Cisco NAC Profiler use the logical OR operation, which results in endpoints being classified into the profile when any one rule is satisfied. To create a combination or rules with Boolean logic other than `OR' refer to advanced rules. Examples of rules created within a profile, refer to "Creating a Profile" section.
Collecting the Data
A key aspect of the profiling process is to gather the relevant data on the network to "fingerprint" the device. In the BNAC solution, this is achieved through the following:
•
•
Profile Collectors
The collector modules collect endpoint information for the system that is processed into the database and analyzed and presented by the Cisco NAC Profiler server. The five component modules running on the collector(s) are as follows:
•
•
•
•
•
Version 4.1.2 of the NAC Server has collectors pre-installed with the NAC software and are coresident on the NAC Server. Note that collectors reside on the NACS, but are configured and activated off the NACM GUI.
The profiler gathers and observes endpoint attributes using four basic methods of gathering information:
•
•
•
•
SNMP
SNMP is used to gather information from the network infrastructure components including switches and routers. The key collector modules used for this type of polling are NetMap and NetTrap.
•
•
Figure 16 shows a sample debug of a mac notification message:
17:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get request, reqid 1223937565, errstat 0, erridx 0vmVlan.10001 = NULL TYPE/VALUE17:27:07: SNMP: Response, reqid 1223937565, errstat 0, erridx 0vmVlan.10001 = 617:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get-next request, reqid 1223937567, errstat 0, erridx 0vtpVlanEntry.4 = NULL•
Note that device MAC addresses are entered into the profiling system through these polling methods. Currently, there is no way to enter MAC addresses manually.
Traffic Analysis
Traffic analysis is accomplished through observing endpoint traffic. The key collector modules used is NetWatch, which resides on the NAC Server. Traffic is sent directly from the key aggregation point through a SPAN port and processed by the NetWatch collector. This data is then sent to the profiler to determine if there is a profile match based on the particular traffic attributes.
NetFlow Data
NetFlow data can be exported to the NAC Server as an alternative to observing traffic in the NetWatch collector. The key collector module used here is NetRelay, which resides on the NAC Server.
Active Techniques
Active techniques can be used where the profiler itself will communicate with endpoints or network services (DNS) to get data about endpoints. The key collector modules used is NetInquiry. Active Techniques is not used in this design guide.
SPAN
The NetWatch collector (as described above) is used as a passive traffic analyzer that is used to observe traffic between the end medical devices and/or the central servers in the network. A SPAN port will be used in the network to send traffic to the NetWatch collector.
SPAN port mirroring should be used on a network switch within the healthcare network. SPAN sends a copy of Layers 2 and 3 network packets that are seen on one switch port (or an entire VLAN), to a network monitoring connection on another switch port.
Local SPAN supports a SPAN session entirely within one switch; all source ports or source VLANs and destination ports reside in the same switch or switch stack. Local SPAN copies traffic from one or more source ports in any VLAN or from one or more VLANs to a destination port for analysis.
Typically, the SPAN port should be configured in one of the following locations:
•
•
•
RSPAN
RSPAN can be used in cases where it may not be possible to aggregate a SPAN port. RSPAN supports source ports, source VLANs, and destination ports on different switches (or different switch stacks), enabling remote monitoring of multiple switches across your network. The traffic for each RSPAN session is carried over a user-specified RSPAN VLAN that is dedicated for that RSPAN session in all participating switches. The RSPAN traffic from the source ports or VLANs is copied into the RSPAN VLAN and forwarded over trunk ports carrying the RSPAN VLAN to a destination session monitoring the RSPAN VLAN. Each RSPAN source switch must have either ports or VLANs as RSPAN sources. The destination is always a physical port.
SPAN/RSPAN Limitations
Traffic monitoring in a SPAN session has the following restrictions:
•
•
•
•
•
•
•
•
Sample SPAN Configuration
Figure 16 shows a sample SPAN deployment.
Figure 16 Sample SPAN Deployment
Distribution Switch:
!monitor session 1 source interface Fa1/0/1monitor session 1 destination interface Fa1/0/4 encapsulation replicate!NetFlow
NetFlow is a network protocol that runs on Cisco routers and is used for collecting IP traffic information. Cisco routers that have the NetFlow feature enabled generate NetFlow records. These records are exported from the router in User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP) packets and collected using a NetFlow collector.
The network flow is defined to use a 7-tuple key, where a flow is defined as a unidirectional sequence of packets all sharing all of the following 7 values:
1.
2.
3.
4.
5.
6.
7.
Flexible NetFlow and IPFIX support user-defined flow keys.
The router will output a flow record when it determines that the flow is finished. It does this by flow aging: when the router sees new traffic for an existing flow, it resets the aging counter. Also, TCP session termination in a TCP flow causes the router to expire the flow. Routers can also be configured to output a flow record at a fixed interval even if the flow is still ongoing.
Sample NetFlow Configuration
Figure 17 shows a sample NetFlow deployment.
Figure 17 Sample NetFlow Deployment
!interface FastEthernet0/0description Downstream to Bedside Patient Monitorsip address 10.1.1.1 255.255.0.0ip helper-address 20.108.11.36ip pim sparse-dense-modeip route-cache flowduplex autospeed auto!interface FastEthernet0/1description Upstream to Patient Info Centerip address 20.108.11.1 255.255.0.0ip pim sparse-dense-modeip route-cache flowduplex autospeed auto!ip flow-export version 5ip flow-export destination 172.1.1.1 2055where 172.1.1.1 = Collector2055 = fixed port numberR1#show ip cache flowIP packet size distribution (276 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .996 .000 .000 .000 .000 .000 .003 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000IP Flow Switching Cache, 278544 bytes2 active, 4094 inactive, 14 added363 ager polls, 0 flow alloc failuresActive flows timeout in 30 minutesInactive flows timeout in 15 secondsIP Sub Flow Cache, 21640 bytes0 active, 1024 inactive, 0 added, 0 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedlast clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-Telnet 3 0.0 42 40 0.0 24.5 15.3UDP-other 7 0.0 1 77 0.0 0.0 15.5ICMP 2 0.0 24 60 0.0 26.2 15.1Total: 12 0.0 15 47 0.0 10.4 15.4SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP PktsFa0/1 20.108.11.11 Null 255.255.255.255 11 0208 0208 1Fa0/1 172.28.200.33 Local 20.108.11.1 06 8C01 0017 94Then after a ping from 10.1.1.13 to 20.108.11.11, the following is observed:
R1#show ip cache flowIP packet size distribution (290 total packets):1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480.000 .996 .000 .000 .000 .000 .000 .003 .000 .000 .000 .000 .000 .000 .000512 544 576 1024 1536 2048 2560 3072 3584 4096 4608.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000IP Flow Switching Cache, 278544 bytes4 active, 4092 inactive, 16 added381 ager polls, 0 flow alloc failuresActive flows timeout in 30 minutesInactive flows timeout in 15 secondsIP Sub Flow Cache, 21640 bytes0 active, 1024 inactive, 0 added, 0 added to flow0 alloc failures, 0 force free1 chunk, 1 chunk addedlast clearing of statistics neverProtocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)-------- Flows /Sec /Flow /Pkt /Sec /Flow /FlowTCP-Telnet 3 0.0 42 40 0.0 24.5 15.3UDP-other 7 0.0 1 77 0.0 0.0 15.5ICMP 2 0.0 24 60 0.0 26.2 15.1Total: 12 0.0 15 47 0.0 10.4 15.4SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP PktsFa0/1 20.108.11.11 Fa0/0 10.1.1.13 01 0000 0000 4Fa0/1 20.108.11.11 Null 255.255.255.255 11 0208 0208 1Fa0/1 172.28.200.33 Local 20.108.11.1 06 8C01 0017 100Fa0/0 10.1.1.13 Fa0/1 20.108.11.11 01 0000 0800 4Collection Locations Summary
For a medical device-enabled network, the best place to collect NetFlow and SPAN port export data is at the closest aggregation point to the core. For central stations that are deployed at the distribution, the collection point is at the distribution switch. For central stations that are deployed at the core, the collection point is at the core switch.
SNMP information is collected directly from the access switch through normal IP connectivity. The access switches must have Layer 3 connectivity to the NAC Collector (NACS).
In summary, data may be collected at the following three primary locations in the healthcare network:
•
•
•
Figure 18 shows the primary locations to collect data.
Figure 18 Data Collection Location
VLAN Naming
The VLAN naming feature on the access switches is used in the BNAC solution. Here, a common VLAN name can be used in the NAC Manager configuration and assigned to the different access switches. The access switches will then have that common VLAN name mapped to the exact unique VLAN number that should be provisioned on the access port.
Standard best practices suggest not spanning VLANs across multiple distribution switches. However, to provide for scalability, a common VLAN name can be assigned to all access layer segments. See the following example:
SW-1(config)#vlan 401SW-1(config-vlan)#name VENDORX_PATIENT_MONITORSW-1(config-vlan)#^ZSW-1#sh vlanVLAN Name Status Ports---- -------------------------------- --------- -------------------------------1 default active Fa1/0/4, Fa1/0/5, Fa1/0/7Fa1/0/8, Fa1/0/9, Fa1/0/10Fa1/0/11, Fa1/0/12, Fa1/0/13Fa1/0/14, Fa1/0/15, Fa1/0/16Fa1/0/17, Fa1/0/18, Fa1/0/19Fa1/0/20, Fa1/0/21, Fa1/0/22Fa1/0/23, Fa1/0/24, Gi1/0/1Gi1/0/26 VLAN0006 active Fa1/0/37 XPORT active Fa1/0/1, Fa1/0/2, Fa1/0/68 Dräger active Fa2/0/1401 VENDORX_PATIENT_MONITOR active Fa2/0/7Strategies for Profiling Medical Devices
Cisco NAC Profiler uses a number of mechanisms to establish and maintain the endpoint type and location. The NAC Profiler Collector modules are deployed at the aggregation points of the network where traffic between the endpoint medical devices and the central stations are accessible. That traffic can then be redirected to a monitoring interface off the NACS/Collector or gathered from a NetFlow-enabled router or switch.
Table 7 describes the identity attribute, the process, and the collector modules that are used.
Identity Attributes
For medical devices, the following basic profiling attributes are setup:
•
•
•
Profiling Flow Overview
The overview flow (see Figure 19) describes the sequence of events that happen after the wired medical device is plugged into the switch port.
Figure 19 Profiling Flow
Medical Device Communication Flows
When profiling medical devices, it is important to understand how the communication flows work. Patient monitor devices, for example, will typically communicate with either a centralized server or with other patient monitors, to send vital signs information.
The following subsections provides examples of how the typical patient monitors communicate on the network, and sample profiles for identity and behavior monitoring.
Patient Monitoring Systems Description
A patient monitoring system provides real-time monitoring of ElectroCardioGram (ECG) and other physiological data from critically ill patients. This provides for a mission-critical, real-time system that operates continuously without interruption. Residing on the clinical network are patient monitoring systems (bedside devices and central stations) and telemetry systems that alert clinicians to potentially life threatening situations.
A typical patient monitor system consists of the following components:
•
•
•
•
Communication
Devices may operate within a simple routed environment use the following types of communication techniques over the IP network:
•
•
•
Table 8 lists the most active protocols and port numbers used within the IntelliVue network. The port numbers become very important in identifying the fixed communication ports that will be part of the device profiling process.
The flow exchange between a bedside patient monitor endpoint and the Central Station (CS) over a router contains information that can be used to profile the endpoint.
The sniffer trace in Figure 20 shows the MAC address used in the patient monitor devices.
Figure 20 Patient Monitor Devices MAC Address
The sniffer trace in Figure 21 shows the Med-ltp message over port 24000. Figure 21 shows the patient monitor communicating to the PIC over port 24000.
Figure 21 Med-ltp Message on Port 24000
Sample Profiles for Philips MP50 IntelliVue
Philips Identity Profile
Name: A - Philips Device IdentityDescription: Match MAC address and 1st 6 octetsRule(s): MAC AddressMAC Address String: 00:09:FBConfidence Level: 30%Notes: Match on 1st 6 octet of MAC address matchesSource of data: MAC address from DeviceProcess: SNMP mac notification from source switch port sent to CollectorPhilips Behavior Monitoring Profile
Name: A - Philips Behavior MonDescription: Match PIC destination IP address 20.108.11.36 and destination ports "or" operation for ports 24000, 24001, 24002, 24003, 24004, 24005Rule(s): TrafficDestination IP address: 20.108.11.36Destination port (s): 240002400124002240032400424005Certainty Level: 90%Notes: Match if "any" ports match AND IP address matchesSource of data: SPAN port off of agg switch for uplink to PICNETFLOW off of agg switchThe GUI screenshots in Figure 22 and Figure 23 show the patient monitors configured using the profile information above.
Figure 22 Identity Profile Example
Figure 23 Behavior Monitoring Profile Example
Dräger Infinity Patient Monitors
Functional Overview
The Dräger Infinity is Dräger's patient monitoring product. Dräger uses a mission-critical, real-time system operate continually without interruption. Residing on the clinical network are patient monitoring systems (bedside devices and central stations) and telemetry systems that alert clinicians to potentially life threatening situations.
The Dräger product consists of the following components:
•
•
•
•
Dräger Infinity uses multicast for more than 90 percent of the network I/O and requires an IGMP- enabled network. The system is unique in that the patient monitor devices need to both transmit and receive multicasts. The communications flow is illustrated in Figure 24.
Figure 24 Dräger Infinity Communication Flow
There are four groups common to all members of the monitoring unit (MU):
NameService (224.127.MU.255), port 2150 every 20 secondsAlarm (224.127.MU.254), port 2000 every 1 secondTime (224.127.MU.253), port 2100 every 10 secondsVentAlarm (224.127.MU.252). port 9250 every 1 secondEach patient monitor transmits waveform data to a unique address:
Waveform ((224.CI.MU.xxx), port 2050 5 - 6 times every secondWhere CI = Patient Emulator's Connect IDMU = Monitoring Unit ID and xxx = last octet of the PC running the program.In the case of an actual monitor, CI = 0 and xxx = the last octet of its IPSample Profile for Dräger Infinity
Dräger Identity Profile
Name: B - Dräger Device IdentityDescription: Match MAC address and 1st 6 octetsRule(s): MAC AddressMAC Address String: XX:XX:XXConfidence Level: 30%Notes: Match on 1st 6 octet of MAC address matchesSource of data: MAC address from DeviceProcess: SNMP mac notification from source switch port sent to CollectorDräger Behavior Monitoring Profile
Name: A - Dräger Behavior MonDescription: Match Multicast IP destination and port for Name Service, Alarm, Time, "or" VentDestination IP address: 224.127.MU.255Destination port 2150Destination IP address: 224.127.MU.254Destination port 2000Destination IP address: 224.127.MU.253Destination port 2100Destination IP address: 224.127.MU.252Destination port 9250Certainty Level: 90%Notes: Match if "any" ports/destination addressmatch Source of data: SPAN port off of agg switch for uplinkNETFLOW off of agg switchFigure 25 Dräger Behavior Monitoring Profile
Creating Customized Profiles
This deployment guide provides some sample profiles for patient monitors as result of testing in a lab setting. There are many other medical devices of different vendors and models that hospital and providers support on their healthcare network. This necessitates the need to create custom profiles for those makes and models. This section provides some guidelines for creating working profiles for these devices.
The process uses the inherent reporting and visibility capabilities of the BNAC solution, and requires some basic understanding of how the medical devices behave on the network.
Specifically, the pre-planning process consists of the following:
Step 1
Step 2
Step 3
Step 4
Analyzing How the Device Works on the Network
Understand how the basic medical devices operate over the network.
•
•
•
•
•
Discover Profiling Attributes for New Medical Device
Step 1
Step 2
Step 3
Step 4
Step 5
On the NAC Profiler go to Endpoint Console > Endpoint Directory
Examine the types of endpoints that have been discovered. Locate the device of interest that needs a custom profile created. The example in Figure 26 shows the profiler endpoint directory.
Figure 26 Profiler Endpoint Directory
Step 6
Step 7
•
•
Figure 27 Captured Data
Step 8
On the NAC Profiler, go to Configuration > Endpoint Profiles > Create Profiles. See Figure 28.
Figure 28 Behavior Monitoring Profile
Note that these attributes can be broken up to create two different profiles: one profile for behavior monitoring (as shown in Figure 28 above) and one profile for MAC address identity (see Figure 29).
Step 9
Figure 29 MAC Address Identity Profile
MAC Vendor ID Example
MAC Vendor ID information can be useful to create a basic identity profile. During the discovery gathering phase, the a Fetal Monitor with a Vortex Ethernet interface was detected. The actual MAC vendor ID was shown to be the string "VORTEX COMPUTER". A profile can now be built using that MAC vendor ID string as illustrated in Figure 30.
Figure 30 MAC Vendor ID Example
End-to-End BNAC Flow
Figure 31 shows the end-to-end flow for the BNAC solution.
Figure 31 End-to-End Flow
In Figure 31, collectors poll all access switches and captures device MAC, port, and IP information. The following occur in Figure 31:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
a.
b.
Step 8
Step 9
High Availability
Each of the individual servers in the BNAC solution can be configured in high availability (HA) mode, meaning that there are two servers that act in an active-standby configuration.
NAC Manager
NAC Manager can be configured in HA where there are two NAC Managers that act in an active-standby configuration. The entire configuration on NAC Manager is stored in a database. The standby NAC Manager synchronizes its database with the database on the active NAC Manager. Any changes made to the configuration on the active NAC Managers is immediately pushed to the standby NAC Manager.
The following key points provide a high-level summary of HA-NACM operation:
•
•
•
•
•
•
•
Refer to the NAC Manager documentation for more details:
http://www/en/US/docs/security/nac/appliance/configuration_guide/413/cam/m_ha.html
NAC Server
To provide protection against a single point of failure, the NAC Server can be configured in HA mode as well. The HA mode for the NAC Server is similar to that of the NAC Manager and also uses an active-standby configuration. Each server still share a virtual IP address called service IPs, but do not share virtual MAC addresses.
The following key points provide a high-level overview of HA-NACS operation:
•
•
•
•
•
•
Refer to the NAC Server documentation for more details:
http://www/en/US/docs/security/nac/appliance/configuration_guide/413/cas/s_ha.html
NAC Profiler
Cisco NAC Profiler (Release 2.1.8 and later) provides a high-availability option in the Profiler Server software. The HA option allows Cisco NAC Profiler Server appliances to be deployed as a pair of physical appliances that operate as a single entity, with a single, shared database manageable through single virtual IP (VIP). This option is provided to protect against either appliance hardware or software failure, or the loss of network connectivity to a single appliance so that the Cisco NAC Profiler system remains available.
The following key points provide a high-level summary of HA operation for Cisco NAC Profiler Server appliances:
•
•
•
•
•
•
•
Refer to the NAC Server documentation for further details:
http://www/en/US/docs/security/nac/profiler/configuration_guide/218/p_cfgpser.html#wp1053873
Scalability
The BNAC solution uses the scalability numbers that are recommended according to the individual platforms. The NAC Manager supports NAC Servers according to the breakdown listed in Figure 32. The hardware platforms (3310, 3350, and 3390) determines the number of NAC Servers supported on the NAC Manager, as well as the number of concurrent users/devices on the NAC Manager.
The NAC Profiler 3350 platform can support up to 40,000 MAC addresses (i.e., 40,000 simultaneous endpoints).
Figure 32 Scalability Values
Profiler Reporting
Profiler events are a critical component of the endpoint Behavior Monitoring capability of Cisco NAC Profiler as well as the integration with Cisco NAC Appliance. Cisco NAC Profiler is able to not only discover, locate and identify the endpoints on the network; it also constantly monitors the endpoint environment for changes. When the endpoint connected to a designated port changes, or if an endpoint begins exhibiting behavior indicative that the endpoint device type (i.e., profile) has changed, these events are logged by the Cisco NAC Profiler and the system can automatically alert network operations or security management. In this way, the endpoint behavior monitoring function of Cisco NAC Profiler provides invaluable support for the ongoing management Cisco NAC Appliance deployments.
Newly profiled, MAC Change, and Profile Change events are created and configured to alert network and security operations through one or a combination of common alerting mechanisms: SNMP traps to the NMS, syslog entries on the Profiler Server itself or another syslog server on the network, as well as events notification within the Endpoint Console of the Cisco NAC Profiler web interface.
Endpoint behavior monitoring can be used to assist in the ongoing management, troubleshooting, and improvement of the network security posture by immediately and automatically alerting appropriate personnel and systems when changes of interest are occurring at the edge of the network.
Cisco NAC Profiler provides four Endpoint Event delivery methods applicable to Newly Profiled, Profile Change, and MAC Change events. Those delivery methods are as follows:
•
•
•
Any combination of the three options can be selected for the Endpoint Event being created as shown in Figure 33.
Figure 33 Endpoint Event
Refer to the NAC Profiler documentation for further details:
http://www/en/US/docs/security/nac/profiler/configuration_guide/218/p_prof_events.html
The Profiler GUI can be used to also track the inventory of all devices that are plugged into the access switches. The profiler endpoint console is used to display the endpoints in two ways:
By Profile
Devices can be displayed and sorted by the profiles that the devices match.
On the NAC Profiler go to Endpoint Console > View/Manage Endpoints. See Figure 34.
Figure 34 Displaying Endpoints
On the NAC Profiler, go to Display Endpoints by Profile. See Figure 35.
Figure 35 Displaying Endpoints by Profile
On the NAC Profiler, select the desired profile. The devices belonging to the particular profile are displayed as shown in Figure 36.
Figure 36 Selecting and Displaying the Profile of a Device
By Device Port
On the NAC Profiler, devices can also be displayed and sorted by the switch ports.
On the NAC Profiler, go to Endpoint Console > View/Manage Endpoints > Display Endpoints by Device Ports > Ungrouped. See Figure 37.
Figure 37 Displaying a Device by Ports
The access switches are displayed, with their location string, provided that the location information is configured on the switches. To configure location strings on the switches, use the following commands:
hostname SW-1!snmp-server location Maternity Ward Floor 2 Closet 5By selecting the switch hostname (for example, SW-1), the current devices are shown attached to their respective ports (as shown in Figure 38).
Figure 38 Sample Display of Access Switch
Implementing the BNAC Solution
Basic Pre-Planning Considerations
•
Understand that medical device endpoints will transition from a profile with a lower certainty factor to one with a higher certainty factor.
•
Determine where the NAC Server Collectors will be placed in order to get access to the endpoint data. Understand how the component modules on each Collector will be used. Consider distribution of NetMap polling and NetWatch usage. The overall placement of the NAC Server will influence the Collector placement, since Collectors are coresident on the NAC Server.
•
Inventory the switches and routers in the network (LAN attached). Keep record of the IP addresses of each component, and if necessary, import them to CSV file. The CSV file will used to export the addresses into the NACM. For smaller deployments the switch and router IP addresses can be entered manually into the NACM.
•
Configure the correct RO and RW strings to match the NAC Manager and NAC Server strings.
•
Determine how data feeds will be provided to the Collectors. Consider if bidirection SPAN is possible in construction of traffic rules.
•
Determine if NetFlow will be useful for Profiler.
Basic Implementation Steps
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
The current method of importing profiles is through the NAC Profiler GUI.
Installing the NAC Appliances
Step 1
•
•
•
http://www/en/US/products/ps6128/products_installation_and_configuration_guides_list.html
Step 2
Figure 39 Cisco NAC Profiler
The Cisco NAC Manager is shown in Figure 40.
Figure 40 Cisco NAC Manager
The Cisco NAC Server is shown in Figure 41.
Figure 41 Cisco NAC Server
Step 1
service perfigo configStep 2
service perfigo configservice collector configStep 3
service profiler config
Install Software Licenses
Step 1
•
•
Note
Also, HTTP GUI to NAC Server is not functional until the NAC Server license is added to the NAC Manager.
Step 2
•
•
Note
Establishing Connectivity Between the NAC Appliances
Figure 42 Establishing Connectivity Between NAC Appliances
NACS Configuration
Adding the NACS(s) into the NACM
Figure 43 Adding NACS into NACM
Switch Configuration
Step 1
SW-1#!snmp-server community cisco ROsnmp-server community cisco123 RWsnmp-server enable traps snmp linkdown linkupsnmp-server enable traps mac-notificationsnmp-server enable traps licensesnmp-server host 172.28.200.35 cisco mac-notification snmpsnmp-server host 172.28.200.36 cisco mac-notification snmpwhere 172.28.200.35 = NAC Collectors172.28.200.36 = NAC ManagerStep 2
!interface FastEthernet1/0/1description MON1switchport access vlan 6switchport mode accesssnmp trap mac-notification added!interface FastEthernet1/0/2description MON2switchport access vlan 6switchport mode accesssnmp trap mac-notification added
Profiler Configuration
Creating the Biomedical Device Profiles
Step 1
On the NAC Profiler go to Configuration > Endpoint Profiles > Create Profiles. See Figure 44 and Figure 45.
Figure 44 Creating Identity Profiles (1)
Figure 45 Creating Identity Profiles (1)
Step 2
On the NAC Profiler, go to Configuration > Endpoint Profiles > Create Profiles. See Figure 46.
Figure 46 Behavior Monitoring Profile
Step 3
On the NAC Profiler, go to Configuration > Endpoint Profiles > View Profiles List. See Figure 47.
Step 4
On the NAC Profiler, go to Configuration > Endpoint Profiles.
Figure 47 Summary of Profiles
Creating the NAC Role
Step 1
a.
b.
c.
Figure 48 Creating NAC Role
Creating a NAC Event and Map Event to the Profile and the NAC Role
Step 1
a.
b.
c.
d.
e.
f.
Figure 49 Creating NAC Event and MAP Event for Profiles
Step 2
The summary of configured NAC events is listed below.
Go to Configuration> NAC Profile Events > View NAC Events. See Figure 50.
Figure 50 Summary of NAC Events
NACM Configuration
Creating the Role on NACM
Step 1
a.
b.
c.
Figure 51 Creating Role on NACM
Step 2
On the NACM, go to User Management > User Roles > List of Roles. See Figure 52.
Figure 52 Configuring Roles on NACM
Configuring Switch Models
Step 1
a.
b.
c.
d.
Figure 53 Configuring Switch Models
Step 2
On the NACM, go to Switch Management > Profiles > Switch > List. See Figure 54.
Figure 54 Summary of Switch Profiles
Step 3
a.
b.
c.
d.
e.
f.
Figure 55 Creating Profile that Controls Access Switch Ports
Step 4
On the NACM, go to Switch Management > Profiles > Port > List. See Figure 56.
Figure 56 Viewing Summary List of Profiles
Step 5
a.
b.
Figure 57 Configuring NACM to Receive SNMP Traps
Step 6
On the NACM, go to Switch Management > Devices.
a.
b.
c.
Figure 58 Assigning Profile to Switch Ports
Step 7
a.
b.
Figure 59 Mapping IP Address of Switches to Model Number
Step 8
a.
b.
Note
Figure 60 Assign Profile of Switch Ports
Wired Mobility Example
The following example illustrates the events that occur when devices are plugged into the access switches. The screen shots below show the GUI monitoring.
Figure 61 shows two devices that graduated to the monitoring profile. The entries have been populated into the NACM Filter list.
Figure 61 Wired Mobility Example
Step 1
•
•
•
Figure 62 Baseline Configuration
Step 2
Figure 63 Moving Patient Monitor
Step 3
Before unplugging the device:
Current configuration : 137 bytes!interface FastEthernet1/0/1description MON1switchport access vlan 7switchport mode accesssnmp trap mac-notification addedendAfter unplugging the device:
SW-1#17:24:38: SNMP: Queuing packet to 172.28.200.3517:24:38: SNMP: V1 Trap, ent cmnMIBNotificationPrefix, addr 10.1.1.77, gentrap 6, spectrap 1cmnHistMacChangedMsg.0 =01 00 07 00 09 FB 0A C2 13 00 03 00cmnHistTimestamp.0 = 626788417:24:38: SNMP: Queuing packet to 172.28.200.3617:24:38: SNMP: V1 Trap, ent cmnMIBNotificationPrefix, addr 10.1.1.77, gentrap 6, spectrap 1cmnHistMacChangedMsg.0 =01 00 07 00 09 FB 0A C2 13 00 03 00cmnHistTimestamp.0 = 626788417:24:39: SNMP: Packet sent via UDP to 172.28.200.3517:24:39: SNMP: Packet sent via UDP to 172.28.200.3617:24:39: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:24:39: SNMP: Get request, reqid 1223937529, errstat 0, erridx 0dot1dBasePortEntry.2.3 = NULL TYPE/VALUE17:24:39: SNMP: Response, reqid 1223937529, errstat 0, erridx 0dot1dBasePortEntry.2.3 = 1000117:24:39: SNMP: Packet sent via UDP to 172.28.200.3617:24:39: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:24:39: SNMP: Get request, reqid 1223937531, errstat 0, erridx 0vlanTrunkPortEntry.14.10001 = NULL TYPE/VALUE17:24:39: SNMP: Response, reqid 1223937531, errstat 0, erridx 0vlanTrunkPortEntry.14.10001 = 217:24:39: SNMP: Packet sent via UDP to 172.28.200.3617:24:39: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:24:39: SNMP: Get request, reqid 1223937533, errstat 0, erridx 0vmVlan.10001 = NULL TYPE/VALUE17:24:39: SNMP: Response, reqid 1223937533, errstat 0, erridx 0vmVlan.10001 = 717:24:39: SNMP: Packet sent via UDP to 172.28.200.3617:24:39: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:24:39: SNMP: Set request, reqid 64682075, errstat 0, erridx 0vmVlan.10001 = 617:24:39: SNMP: Response, reqid 64682075, errstat 0, erridx 0vmVlan.10001 = 617:24:39: %SYS-5-CONFIG_I: Configured from 172.28.200.36 by snmp17:24:39: SNMP: Packet sent via UDP to 172.28.200.36Goes to Authentication VLAN:
SW-1#sh run int fa1/0/1Building configuration...SW-1#SW-1#sh run int fa1/0/1Building configuration...Current configuration : 137 bytes!interface FastEthernet1/0/1description MON1switchport access vlan 6switchport mode accesssnmp trap mac-notification addedendPlug device back in:
17:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get request, reqid 1223937565, errstat 0, erridx 0vmVlan.10001 = NULL TYPE/VALUE17:27:07: SNMP: Response, reqid 1223937565, errstat 0, erridx 0vmVlan.10001 = 617:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get-next request, reqid 1223937567, errstat 0, erridx 0vtpVlanEntry.4 = NULL TYPE/VALUE17:27:07: SNMP: Response, reqid 1223937567, errstat 0, erridx 0vtpVlanEntry.4.1.1 = default17:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get-next request, reqid 1223937569, errstat 0, erridx 0vtpVlanEntry.4.1.1 = NULL TYPE/VALUE17:27:07: SNMP: Response, reqid 1223937569, errstat 0, erridx 0vtpVlanEntry.4.1.6 = VLAN000617:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Get-next request, reqid 1223937571, errstat 0, erridx 0vtpVlanEntry.4.1.6 = NULL TYPE/VALUE17:27:07: SNMP: Response, reqid 1223937571, errstat 0, erridx 0vtpVlanEntry.4.1.7 = PHILIPS17:27:07: SNMP: Packet sent via UDP to 172.28.200.3617:27:07: SNMP: Packet received via UDP from 172.28.200.36 on Vlan717:27:07: SNMP: Set request, reqid 64682081, errstat 0, erridx 0vmVlan.10001 = 717:27:08: SNMP: Response, reqid 64682081, errstat 0, erridx 0vmVlan.10001 = 717:27:08: %SYS-5-CONFIG_I: Configured from 172.28.200.36 by snmp17:27:08: SNMP: Packet sent via UDP to 172.28.200.36SW-1#SW-1#sh run int fa1/0/1Building configuration...Current configuration : 137 bytes!interface FastEthernet1/0/1description MON1switchport access vlan 7switchport mode accesssnmp trap mac-notification addedendSW-1#Figure 64 shows the current switch port locations of the two patient monitors. Figure 65 shows the MAC address history of Patient Monitor #2 by port, IP address, and profile match.
Figure 64 Location of Switch for Two Patient Monitors
Figure 65 Patient Monitor #2 Display
Figure 66 MAC Address History for Patient Monitor #2
Solution Limitations
The following solution limitations were encountered as part of the solution testing:
•
•
•
•
•
•
•
Note
Appendix
The Profiler Service Command Set
The Profiler command line provides a service profiler command set that enables several system-level functions to be executed from the LINUX command line of Profiler appliances. These commands are available only as the root user, use the su - command to switch to the root user prior to issuing the following service profiler commands:
service profiler status
service profiler start
service profiler stop
service profiler restart
service profiler config
service profiler debug
A description, guidelines for use and example output (if applicable) are provided below for each of these commands.
•
–
–
–
•
•
•
•
–
–
–
If an existing configuration is found, the system will prompt if reconfiguration is desired. If reconfiguration is not selected, the script will move onto the next configuration task without making changes to the existing configuration. At the completion of the scripts, the system will be restarted.
Note that if reconfiguration is selected, the scripts will prompt for new information without displaying the current settings.
•
Note that the proper usage of this command is to stop the service first (service profiler stop), then start the service in debug mode (service profiler debug). Typically, the service is run in debug mode for a specified period of time, and the service is returned to normal operation by restarting it (service profiler restart). The Server.out (located in usr/Profiler/logging) containing the debug information is then collected for offline analysis.
HA System Considerations for Service Profiler Commands
Profiler All-in-one and Server Only systems implemented as HA pairs have additional considerations for use of the service commands when working with members of an HA pair. The secondary system in an HA pair will always show the status of all installed modules as Not Running. This is the normal state for the secondary appliance-the HA protocol is maintaining database synchronization and in the event of failure of the primary, the modules will be started in conjunction with the failover.
In addition, the start option is not available on secondary appliances in an HA pair. If service profiler start is entered at the command line of an appliance in HA mode in the secondary state, the following message will be displayed:
This collector is in HA mode and will not be started
While the system is running in HA mode, the Profiler service on the secondary member of the pair should be left to the control of the HA protocol and not manipulated via the command line.
Profiler Database Operations
The Profiler system uses a PostgreSQL database to store all system configuration and endpoint data. PostgreSQL is a powerful, enterprise-class relational database system that strongly conforms to ANSI-SQL 92/99 standards.
Because the system configuration and endpoint data is stored in a single database, system backup and restore consists of creating a backup copy of the Profiler database and moving it to an off-system repository. The Server module will perform an automatic copy of the Profiler database each day at 3:00AM system time of the appliance running the module. These daily backups can be found in the /backup directory in compressed (.gz) format. As outlined later in this document, the .gz compressed format is the format that the database restore scripts expect when restoring a backed-up database to a system. The Server module will maintain the backup directory so that database backups older than 30 days are automatically deleted from the backup directory.
It is highly recommended that the Profiler database backups are moved off the appliance and stored with other system backups in accordance with file backup best practices.
Database Backup
In addition to the automated backups performed by the system, it is also possible to make a backup copy of the Profiler database at any time. In Version 2.1.8 and later releases, a backup copy can be made and transferred off the system through the Profiler GUI. Navigate to the Utilities tab, and select System Summary. At the bottom of the System Summary, three buttons are displayed: Display Server Log, Download DB Dump, and Collect technical logs (see Figure 67).
If these buttons are not displayed in the system summary, the Profiler version is pre version 2.1.8. Use the manual procedure outlined below to make a backup copy of the Profiler database and transfer it off the Server appliance. Consideration should be give to upgrading the Profiler software on the system to version 2.1.8 or higher to take full advantage of this and other features.
Figure 67 System Summary Showing DB Backup Button
To initiate the backup of the database, select the Download DB button which results in the browser displaying the download file dialog that allows the designation of an off-appliance location to save the database backup copy to. Specifying a path for the file will result in the database being saved to a compressed file and copied to the specified location. By default, the filename for the backup copy is Profilerdb.gz.
For systems prior to Version 2.1.8, the backup of the database and copy to an off-appliance location must be performed manually using the following steps:
Step 1
Step 2
pg_dump | gzip > Profilerdb.gz
Step 3
Step 4
Database Restore
A backup copy of the Profiler database can be restored to a Profiler system at any time. Again, because the database contains both the system configuration and the endpoint data, any changes made to the system configuration since the backup was created will be lost.
Profiler database restore is performed differently for systems with the Server module running in standalone mode, and those running as HA pairs. Before restoring a database to a Profiler system, it is important to determine first if it is a standalone or HA system, then use the appropriate procedure below to restore the Profiler database.
Database Restore on Standalone (non-HA) Systems
Beginning with Version 2.1.8, restoring the Profiler database to a standalone system can be performed through the execution of a single script. Follow these steps to restore the database to a 2.1.8 system.
Step 1
Step 2
Step 3
./restoreDB.pl /backup/Profilerdb.gz
where Profilerdb.gz is the filename of the backup
Step 4
For database restore on prior Version 2.1.8, standalone systems (indicated by the above named script not being present in the /usr/beacon/scripts directory), use the following steps to drop and create the database manually, then restore the backup copy to it.
Step 1
Step 2
dropdb beacon
createdb beacon
gunzip -c /backup/beacondb.gz | psql
where beacondb.gz is the filename of the backup
Step 3
Database Restore on HA Systems
Version 2.1.8 has several usability and maintenance enhancements to the HA functionality, including automation of the database restore process. Prior to restoring the database on an HA system, the system must be upgraded to Version 2.1.8 or later. For more information, refer to "Upgrading Profiler System Software" section.
The Profiler HA protocol includes a database synchronization function that ensures that the system configuration and endpoint data maintained in the database is kept in synch on both members of the pair. Therefore, the process to restore the Profiler database on an HA pair requires the restore on the primary, and reliance on the synchronization process to update the secondary appliance database.
To ensure that the database restore is performed on the primary, the restore process outlined in this section should be performed on the VIP/Service IP for the HA pair.
Follow these steps to restore a Profiler database on an HA pair:
Step 1
Step 2
Step 3
./restoreDB-HA.pl /backup/Profilerdb.gz
where Profilerdb.gz is the filename of the backup
Step 4
Weekly Database Maintenance
The Profiler system will perform necessary database maintenance each week to ensure the integrity of the system automatically. The database maintenance requires a brief stop and restart of the Server module in order to perform these functions. By default, this weekly maintenance will occur automatically on Sunday at 2:00AM based on the system clock of the system running the Server module. This event is logged in the Server logs, is normal behavior and is not a cause for concern.
Upgrading Profiler System Software
Great Bay Software releases regular updates of the Profiler Endpoint Profiler system software. These upgrades are released as a single file, in compressed format (.zip) and are available from the Great Bay Software technical support secure website (www.GreatBaySoftware.com/support, registration is required) for customers with a valid maintenance contract.
Along with the upgrade package, an MD5 checksum will be posted to ensure file integrity. Check the MD5 checksum prior to using the upgrade package to ensure that the upgrade package has not become corrupted.
The software upgrade package will include all necessary files for upgrading the Profiler software, underlying components, and the Profiler database (if required, and only on All-in-one and Server Only systems). The upgrade is performed by a single script, and the script will automatically detect the operating mode of the appliance (e.g., All-in-one, Server Only, Remote Collection) and upgrade the system accordingly.
The filename of the upgrade package indicates the version and build of the Profiler Endpoint Profiler release. For example, an upgrade package with the filename ProfilerUpgrade-2.1.8-26.zip indicates that this upgrade package is for upgrading systems to Profiler Release 2.1.8, build 26.
Upgrading Standalone Systems
Upgrading the Profiler software on standalone systems is a straightforward process. The upgrade script that is integral to the upgrade package will determine the operating mode of the system and upgrade all installed components automatically as needed. Follow the steps below to upgrade standalone Profiler systems.
Step 1
Step 2
Step 3
md5sum ProfilerUpgrade-xx.xx.xx-yy.zip
This command will calculate and display the checksum of the file to the terminal on the appliance so it can be checked against the one supplied with the file.
Step 4
Step 5
Step 6
./upgrade.pl
Step 7
To modify the configuration of the Profiler, use service profiler config followed by the return of the system prompt.
Step 8
Upgrading HA Pairs
The procedure for upgrading the software on a HA pair is performed on the secondary appliance in the pair first, and then on the primary. In the process of the upgrade, the system that was the secondary prior to the upgrade will take over the functions of the primary, similar to what would occur in the event of the failure of the primary.
Upgrading the Profiler software on a HA pair should be completed on both members of the pair sequentially in a single operation. Do not leave the pair with the first appliance upgraded and delay the upgrade of the other member of the pair.
If it is desirable to return the HA pair back to its state previous to the upgrade, failover of the pair will be necessary to force the member that was primary prior to the upgrade back to that state.
Follow these procedures to upgrade the Profiler software on a HA pair.
Step 1
Step 2
Step 3
Step 4
md5sum ProfilerUpgrade-xx.xx.xx-yy.zip
This command will calculate and display the checksum of the file to the terminal on the appliance so it can be checked against the one supplied with the file.
Step 5
Step 6
Step 7
./upgrade.pl
Step 8
To modify the configuration of the Profiler, use the service profiler config command and followed by the return of the system prompt.
Step 9
This completes the upgrade of the software on the secondary appliance. Proceed by copying the upgrade package to the other appliance in the HA pair, and performing the upgrade process on the appliance that was primary at the outset of the upgrade procedure.
Once the second appliance has been successfully upgraded, both members of the HA pair are now at the new revision. The original secondary is now the primary, and vice versa.
If it is desirable to return the HA pair back to the state it was in prior to the upgrade (original primary now secondary returned back to primary state), follow the procedure below to force the failover of the system.
Example: Upgrading the Profiler Version
[beacon@NAC3350-1 ~]$ su rootPassword: xxx[root@NAC3350-1 beacon]# pwd/home/beacon[root@NAC3350-1 /]# cd /home[root@NAC3350-1 home]# lsbeacon[root@NAC3350-1 home]# cd beacon[root@NAC3350-1 beacon]# lsjpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip ProfilerUpgrade-2.1.8-37 ProfilerUpgrade-2.1.8-37.zip profiles[root@NAC3350-1 beacon]# cd profiles[root@NAC3350-1 profiles]# lsprofiles.pl profiles.tgz setProfiles.pl[root@NAC3350-1 profiles]# cd ..[root@NAC3350-1 beacon]# lsjpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip ProfilerUpgrade-2.1.8-37 ProfilerUpgrade-2.1.8-37.zip profiles[root@NAC3350-1 beacon]# su -[root@NAC3350-1 ~]# lsanaconda-ks.cfg install.log install.log.syslog RPMS[root@NAC3350-1 ~]# pwd/root[root@NAC3350-1 ~]# cd ..[root@NAC3350-1 /]# pwd/[root@NAC3350-1 /]# cd home[root@NAC3350-1 home]# lsbeacon[root@NAC3350-1 home]# cd beacon[root@NAC3350-1 beacon]# lsjpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip ProfilerUpgrade-2.1.8-37 ProfilerUpgrade-2.1.8-37.zip profiles[root@NAC3350-1 beacon]# md5sum jpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zipaefdb394f8a0a3ae66364d45102cec30 jpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip[root@NAC3350-1 beacon]# unzip jpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zipArchive: jpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zipcreating: ProfilerUpgrade-2.1.8-38/RPMS/inflating: ProfilerUpgrade-2.1.8-38/RPMS/openldap-clients-2.3.39-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-HTML-Parser-3.55-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-LDAP-0.33-3.fc6.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-Convert-ASN1-0.20-1.1.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssh-4.7p1-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-devel-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-slony1-1.2.12-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-XML-SAX-0.14-2.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-libs-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-pl-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/expat-devel-1.95.8-8.2.1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-ldap-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssl-devel-0.9.8b-15.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/httpd-tools-2.2.9-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-Compress-Zlib-1.42-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/mod_ssl-2.2.9-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/Profiler-2.1.8-38.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/db4-devel-4.3.29-9.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-cli-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-docs-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssl-0.9.8b-15.fc6.i686.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/httpd-manual-2.2.9-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/apr-devel-1.2.7-10.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openldap-devel-2.3.39-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-Net-SSLeay-1.30-4.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openldap-servers-sql-2.3.39-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-python-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/fedora-logos-8.0.2-1.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-odbc-08.01.0200-3.1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-server-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-contrib-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-odbc-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/httpd-2.2.9-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-pgsql-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/httpd-devel-2.2.9-1.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-HTML-Tagset-3.10-2.1.1.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-pdo-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-MailTools-1.74-3.fc6.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssh-server-4.7p1-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/ProfilerRequirements-2.1.8-38.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openldap-2.3.39-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-IO-Socket-SSL-1.01-1.fc6.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssh-askpass-4.7p1-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-XML-NamespaceSupport-1.09-1.2.1.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openldap-servers-2.3.39-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/perl-TimeDate-1.16-3.2.1.noarch.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/apr-util-devel-1.2.8-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/openssh-clients-4.7p1-4.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/libedit-2.9-4.20060603cvs.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/Beacon-2.1.8-38.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/php-common-5.1.6-3.7.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/RPMS/postgresql-8.1.10-1.fc6.i386.rpminflating: ProfilerUpgrade-2.1.8-38/upgrade.pl[root@NAC3350-1 beacon]# lsjpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip ProfilerUpgrade-2.1.8-37.zip profilesProfilerUpgrade-2.1.8-37 ProfilerUpgrade-2.1.8-38[root@NAC3350-1 beacon]#[root@NAC3350-1 beacon]# lsjpgorsky_1225629066_ProfilerUpgrade-2.1.8-38.zip ProfilerUpgrade-2.1.8-37.zip profilesProfilerUpgrade-2.1.8-37 ProfilerUpgrade-2.1.8-38[root@NAC3350-1 beacon]# cd ProfilerUpgrade-2.1.8-38[root@NAC3350-1 ProfilerUpgrade-2.1.8-38]# ./upgrade.plUpgrading to the latest build.Backing up current DB.Upgrading system RPMs.Restarting upgraded system services.Backing up current DB.Stopping DB for upgrade.Upgrading Beacon and database RPMs.Starting DB.Restarting LDAP.Starting slapd: [ OK ]Updating OUI tableRestarting the ProfilerTo modify the configuration of the Profiler, use the service profiler configuration command:
[root@NAC3350-1 ProfilerUpgrade-2.1.8-38]#[root@NAC3350-1 ProfilerUpgrade-2.1.8-38]# service profiler startStarting Profiler: [ OK ][root@NAC3350-1 ProfilerUpgrade-2.1.8-38]# service profiler statusProfiler StatusVersion: Profiler-2.1.8-38o Server Runningo Forwarder Not Installedo NetMap Not Installedo NetTrap Not Installedo NetWatch Not Installedo NetInquiry Not Installedo NetRelay Not InstalledExample: Upgrading the Collector Versions
[root@NAC3310-1 ~]#[root@NAC3310-1 ~]#[root@NAC3310-1 ~]# lsanaconda-ks.cfg fstab.orig i18n-old inittab.old install.log install.log.syslog[[root@NAC3310-1 ~]# service collector startStarting Collector: [ OK ][root@NAC3310-1 ~]# pwd/root[root@NAC3310-1 ~]# cd /[root@NAC3310-1 /]# cd store[root@NAC3310-1 store]# lscca_upgrade-4.1.3.1 Collector-2.1.8-37.i386.rpm upload winscp417setup.exe[root@NAC3310-1 store]# lscca_upgrade-4.1.3.1 Collector-2.1.8-37.i386.rpm jpgorsky_1224602644_Collector-2.1.8-38.i386.rpm upload winscp417setup.exe[root@NAC3310-1 store]# rpm - U jpgorsky_1224602644_Collector-2.1.8-38.i386.rpm[root@NAC3310-1 store]# service collector startStarting Collector: [ OK ][root@NAC3310-1 store]# service collector stopStopping Collector service: [ OK ][root@NAC3310-1 store]# service collector startStarting Collector: [ OK ][root@NAC3310-1 store]# lscca_upgrade-4.1.3.1 Collector-2.1.8-37.i386.rpm jpgorsky_1224602644_Collector-2.1.8-38.i386.rpm upload winscp417setup.exe[root@NAC3310-1 store]# service collector statusProfiler StatusVersion: Collector-2.1.8-38o Server Not Installedo Forwarder Runningo NetMap Runningo NetTrap Runningo NetWatch Runningo NetInquiry Runningo NetRelay RunningUsing WinSCP to Move Upgrade Files to Servers
Figure 68 Moving Upgrade Files to Servers
