The McAfee Network Security Manager (Manager) is the central management component for the

McAfee Network Security Platform (NSP).

In this module, you will learn about Manager deployment options, hardware platform requirements,
and installation prerequisites. You will also learn how to install the Manager software on a customer-
supplied server for a new deployment. For training purposes, assumes the module assumes the
classroom server and client meet the minimum requirements defined for the NSP.

On successful completion, you should be able to:

• Identify supported deployment paths.
• Identify the platform requirements.
• Identify required ports.
• Describe Manager and Sensor deployment considerations.
• Describe the Manager Disaster Recovery (MDR) feature.

Important: Planning the NSP deployment requires integrated effort from all departments. As a
security administrator, you will still depend on network and systems teams to know about the
network and systems. All changes to the configuration should be followed per Organizational practice
and documented.
The Manager supports two deployment paths. The customer-supplied deployment path is focused
on, in this material.

Network Security Manager Appliance

The Manager Appliance is ordered from McAfee. This unit is preloaded with the Manager software
for rapid deployment. The Manager Appliance is part of the McAfee Network Security Platform
Intrusion Prevention System. The Manager Appliance is a 1-U rack dense chassis with an Intel
Processor.

Customer-Supplied Server Deployment

With a customer-supplied server deployment, the NSP Manager software is manually installed on a
supported 64-bit Windows Server or a supported virtual platform. There is more setup required;
however, there is more flexibility with the platform choice, and the platform is open (non-
proprietary). Customer-supplied hardware and software must meet the specifications for the
Manager release planned for installation.
This slide highlights base platform requirements and recommendations.
The NSP Manager software runs on a dedicated Windows server. The larger the deployment, the
more high-end the Manager server should be. Many NSP issues result from an under-powered
Manager server. It is recommended that you exceed the minimum recommendations, wherever
possible.
Operating System
Any of the following 64-bit Microsoft Windows operating systems are supported.
• Windows Server 2008 R2 Standard or Enterprise Edition, SP1 (Full Installation), English operating
system
• Windows Server 2008 R2 Standard or Enterprise Edition, SP1 (Full Installation), Japanese
operating system
• Windows Server 2012 Standard Edition (Server with a GUI) English operating system
• Windows Server 2012 Standard Edition (Server with a GUI) Japanese operating system
• Windows Server 2012 R2 Standard Edition (Server with a GUI) English operating system
• Windows Server 2012 R2 Standard Edition (Server with a GUI) Japanese operating system
• Windows Server 2012 R2 Datacenter Edition (Server with a GUI) English operating system
• Windows Server 2012 R2 Datacenter (Server with a GUI) Japanese operating system

MySQL
The Manager requires communication with MySQL database for the archiving and retrieval of data.
The Manager installation set includes a MySQL database for installation (that is, embedded on the
target Manager server). You must use the supported OS listed under Server requirements and must
use the Network Security Platform-supplied version of MySQL. The MySQL database must be a
dedicated one that is installed on the Manager.

Alert: If you have a MySQL database previously installed on the Manager server, uninstall the
previous version and install the Network Security Platform version.
The requirements for the Manager Client are listed below. The Manager Client connects to the server
using a supported web browser.
Monitor Display
Right-click on the Desktop and select Screen Resolution and go to Advanced Settings > Monitor, and
configure Colors to True Color (32bit).

When logging into the Manager from a client machine for the first time, you are prompted to install a
Java Runtime Engine (JRE) plug-in. This plug-in is required to view objects in the Manager Home page
and other areas of the Manager program, such as the Threat Analyzer. Do not update java from
anywhere but the Manager. Turn off the automatic update settings in the browser.

Ensure the browser does not cache pages; for example, by default Internet Explorer automatically
checks for newer versions of stored pages. To ensure pages are not cached, complete these steps
from the menu bar:
1. Select Tools > Internet Options. The Internet Options dialog opens.
2. Within the Browsing history section of the window, click Settings.
3. The following options display in the Temporary Internet Files section of the dialog: Check for
newer versions of stored pages: Every time I visit the web page, Every time I start Internet
Explorer, Automatically, and Never.
4. Make sure the Never option is not selected and that any one of the other options is selected so
that cached Manager pages are not loaded. Caches pages can result in system errors.
Continued on the next page.
Internet Explorer Compatibility View Settings
If you are using Internet Explorer, go to Tools > Compatibility View Settings and make sure Display
intranet sites in Compatibility View and Display all websites in Compatibility View check boxes are
not selected.
Internet Explorer ActiveX Controls and Plug-ins When Accessing the Manager from the Server
In the Internet Explorer, go to Tools > Internet Options > Security> Internet > Custom Level and
enable the following:
• ActiveX controls and plug-ins: Run ActiveX controls & plug-ins
• ActiveX controls and plug-ins: Script ActiveX controls marked safe for scripting
• Downloads: File Download
• Miscellaneous: Allow META REFRESH
• Scripting: Active Scripting

Internet Explorer Privacy Settings When Accessing the Manager from the Server
In the Internet Explorer, go to Tools > Internet Options > Privacy and ensure the setting is
configured as something below Medium High; for example, do not set it at High or at Block all
Cookies.
If the setting is higher than Medium High, you will receive an Unable to configure Systems.
Permission denied error and the Manager configuration will not function.
Client Versus Server Access
You will experience better performance in the configuration and data-forensic tasks by connecting to
the Manager from a browser on the client machine. Performance may be slow if you connect to the
Manager using a browser on the server machine itself.
We have looked at the requirements for deployment on a physical server. The table shows system
requirements for hosting the NSP Central Manager/Manager server on a VMware platform.
The virtual machine requirements are shown in the table. Remember, it is recommended to exceed
the minimum requirements, if possible.
The table shows the ports are used on the Network Security Manager server. McAfee recommends
that you use the Sensor and Manager management port on the same internal network for security
and management reasons.

Alert: NSP product documentation states the need to disable other Web Services prior to installing
the Manager. This is because the Manager server has to integrate with the Apache server, which is
shipped along with the Manager installation package. Because other Web Services use port 80 and
443, the Manager installation will fail if the other Web Services are not disabled, because it cannot
run the Apache server.
Continued on the next page.
Ports 4166 and 4167
Currently port 4167 is used as the UDP source port number for the SNMP command channel
communication between Manager and Sensors. This is to prevent opening up all UDP ports for
inbound connectivity from SNMP ports on the sensor. Older JRE versions allowed the Manager to
bind to the same source port 4167 for both IPv4 and IPv6 communication. With JRE version 1.7.0_45
and higher, it is no longer possible to do so. The Manager uses port 4166 as the UDP source port to
bind for IPv6.

If you have IPv6 Sensors behind a firewall, you need to update the firewall rules accordingly such that
port 4166 is open for the SNMP command channel to function between those IPv6 Sensors and the
Manager.

Continued on the next page.

2048-bit Encryption
The Manager and Sensor have so far established trust using 1024-bit certificates. With the growing
need for enhanced security, this connection is being upgraded to be encrypted using 2048-bit
certificates. Network Security Platform supports heterogeneous environments, which accommodate
both 1024-bit and 2048-bit encryption. That is, the Manager is both 1024 and 2048-bit capable, and
can be used to manage Sensors running on 2048-bit capable and/or 1024-bit capable software
versions.

The upgrade from 1024-bit to 2048-bit encryption is done automatically with no user intervention
necessary. Once done, use the status command to view the encryption type, and show command to
view the ports used for 2048-bit encryption.

1024-bit Encryption
When a Sensor with software that does not support 2048-bit encryption is loaded and the Manager is
upgraded to a version that supports 2048-bit encryption, the Sensor can establish trust with the
Manager using 1024-bit certificates.
A desktop firewall on the Manager server is recommended. Certain ports are used by the
components of NSP. Some of these are required for Manager–Sensor and Manager client-server
communication. All remaining unnecessary ports should be closed.

If a firewall resides between the Sensor, Manager, or administrative client, which includes a local
firewall on the Manager, the following ports must be opened:
• UDP ports 4166, 4167, and 8500
• TCP ports 22, 443, 8501, 8502, 8503, 8504, and 8555

Use a scanning tool such as Vulnerability Manager to ensure that there no ports open other than
what is required.

It is strongly recommended that customers configure a packet-filtering firewall to block connections

to ports 8551, 8552, 3306, 8007, 8009, and 8552 of the Manager server. The firewall can either be a
host-based or network-based. Set the firewall to deny connections to these ports if the connections
are not initiated by the localhost. The only connections that should be allowed are those from the
Manager server itself; that is, the localhost. For example, if another machine attempts to connect to
port 8551, 8552, 3306, 8007 and 8009 the firewall should automatically block any packets sent.

NOTE: If you choose to use non-default ports for the Install port, Alert port, and Log port, ensure that
those ports are also open on the firewall.
Some of the Manager's operations might conflict with the scanning processes of McAfee VirusScan or
any other anti-virus software running on the Manager.

Folder Exclusions
The anti-virus software might scan every temporary file created in the Manager installation directory,
which might slow down the Manager's performance. Be sure to exclude the Manager installation
directory and its sub-directories from the anti-virus scanning processes, specifically these folders:
• <Manager installation directory>\MySQL\ and its sub-folders. If these folders are not excluded,
VirusScan may delete essential MySQL files.
• <Manager installation directory>\App\temp\tftpin\malware\ and its sub-folders.

SMTP Connections
By default, VirusScan blocks all outbound connections over TCP port 25. This helps reduce the risk of
a compromised host propagating a worm over SMTP using a homemade mail client. VirusScan avoids
blocking outbound SMTP connections from legitimate mail clients, such as Outlook and Eudora, by
including the processes used by these products in an exclusion list.

The Manager takes advantage of the JavaMail API to send SMTP notifications. If you enable SMTP
notification and run VirusScan 8X or above, you must add the java.exe to the list of excluded
processes. If you do not explicitly create the exclusion within VirusScan Enterprise (VSE), you see a
Mailer Unreachable error in the Manager Operational Status to each time the Manager attempts to
connect to its configured mail server.
To add the exclusion, follow these steps:
1. Launch the VirusScan Console.
2. Right-click the task called Access Protection and choose Properties from the right-click menu.
3. Highlight the rule called Prevent mass mailing worms from sending mail.
4. Click Edit.
5. Append java.exe to the list of Processes to Exclude.
6. Click OK to save the changes.
A protocol analyzer, such as Wireshark is recommended. Wireshark is a packet sniffer computer
application. It is used for network troubleshooting, analysis, software and communications protocol
development, and education. For more information, go to www.wireshark.org.
There are two Manager deployment options: Single Manager or a Central Manager.

Single Manager
With a Single Manager deployment, there is a single NSP server in the network that runs the NSP
Manager interface (Manager). NSP Clients access the NSP Manager from this single NSP server.

Central Manager
The Central Manager is a centralized system managing multiple Managers. The Central Manager
architecture consists of a Central Manager, which is interconnected to various Managers. Central
Manager manages configurations and pushes them globally to Managers. Configurations are pushed
to the Sensors indirectly through Managers.

If you have a large Sensor deployment (for example, 200 Sensors deployed across various geographic
locations), consider using a Central Manager at the organization's headquarters and deploy a
dedicated Manager for each region. Each Manager will then handle the daily device operations for all
Sensors configured to it.

When you use a Central Manager, the regional/local Managers can add their own region-specific
rules, but cannot modify any configuration established by the Central Manager. Configuration updates
to the Sensors must be applied through the local Managers.

Continued on the next page.

Reminder: A Central Manager installation is not the same as Manager Disaster Recovery (MDR)
configuration. An MDR configuration enables you to have a standby Manager available in cases
where the Primary Manager fails. The MDR feature is available for deployments where the following
conditions are met:
• Two Managers (called Primary and Secondary) are available. The Primary is in active mode and
the secondary in standby mode.
• The Primary and Secondary use the same Manager software release version. Manager version of
both Primary and Secondary Manager needs to be similar for the creation of MDR pair.
• The Primary and Secondary Managers share the same database structure.
The database houses the alert and packet log data that the Sensors generate, as well as system files,
logs, and so forth. The integrity and availability of this data is essential to ensure proper system
operation.

The amount of space required for the database is governed by many factors, mostly unique to the
deployment scenario. These factors determine the amount of data you want to retain in the database
and the time for which the data has to be retained.

Things to consider while determining the database size requirements are:

• Aggregate alert and packet log volume from all Sensors: Many Sensors amount to higher alert
volume and require additional storage capacity. Note that an alert is roughly 2048 bytes on
average, while a packet log is approximately 1300 bytes.
• Lifetime of alert and packet log data: You need to consider the time before you archive or delete
an alert.

Maintaining the data for a long period of time (for example, one year) require additional storage
capacity to accommodate both old and new data.

As a best practice, McAfee recommends archiving and deleting old alert data regularly, and
attempting to keep the active database size to about 60 GB.
For comparison, generation of 10,000 alerts per week is low, while 1,000,000 alert per week is high. If
you are generating 1,000,000 alerts per week, it is recommended that you check the applied NSP
policies to determine if you are applying a policy that is an exact match for the protected network
environment.
Sensor placement is an individual company decision. Some things to consider are what assets they
want to protect, the configuration of the network, the location of aggregation points, the type of
traffic, how the traffic is routed, and so on.

Existing Network Infrastructure and Corporate Security Policy

Understanding the network and corporate environment is the most difficult part, and probably bulk
of the work in effective IPS deployment. It encompasses the following.
• Network topology
• Network address space being monitored
• Statically assigned server addresses
• VLAN
• Dynamic Host Configuration Protocol (DHCP)-assigned addresses
• Operating systems running on the servers
• Applications running on the servers
• Corporate security policy

The size of the network will determine the number of Sensors required to successfully and efficiently
protect the network. A large network with many access points, file servers, and machines in use may
require a larger level of IPS deployment than a small office with just a single access point and few
machines. You must also factor in any redundancy requirements.
Access Points
You are only as strong as your weakest link. Intrusions coming in from the Internet are important to
combat, but misuse and intrusions attempted through the extranets or inside the corporate network
are equally as critical to defend against. In fact, research statistics show that insiders are the most
common source of attacks.

Critical Servers
File servers containing financial, personnel, and other confidential information need protection from
those people wishing to exploit the critical information. These machines are extremely appealing
targets. And, as discussed in the previous section, insiders pose a threat that must be addressed.
Consider whether you need different levels of security for different parts of the organization. Assess
how much of the sensitive material is on-line, where it is located, and who has access to that
material. In addition, estimate the typical volume of network traffic generated by these systems. If
you have already designed the sensor placement, please show this on the network diagram.

Traffic Flow
Bandwidth and traffic flow are crucial to running a successful enterprise network. Bandwidth
requirements vary in an enterprise network, as different applications and business functions have
different needs. Bandwidth utilization on the network segments that you need to monitor
determine what type of Sensor will work best for you. NSP offers multiple Sensors providing
different bandwidths.

Monitoring of Security Operations

To successfully defend against intrusions, McAfee recommends dedicated monitoring of the security
system. Network intrusions can happen at any given moment, so having a dedicated 24-hour-a-day
prevention system make the security solution complete and effective.

Monitoring at the Perimeter

Deployment at the perimeter does not protect you from internal attacks, which are some of the
most common source of attacks. Perimeter monitoring is also useless if a network has multiple ISP
connections at multiple locations (such as one Internet connection in New York and one in San Jose)
and if you expect to see asymmetric traffic routing (that is, incoming traffic comes through New York
and outgoing traffic goes out through San Jose). The IPS simply will not see all the traffic to maintain
state and detect attacks. Deployment in front of the servers that you want to protect both detects
attacks from internal users and deals effectively with the geographically diverse asymmetric routing
issue.
McAfee states that the Windows-based NSP Manager and the Global Edition can support up to 100
Sensors. So, can 100 Sensors actually be supported? It depends. The number of Sensors you can
effectively deploy with a single Manager is highly dependent on interrelated factors, so no single
solution works for all environments. Some factors depend on the Sensor’s implementation and how
much alert traffic the network generates. Others factors involve the size of the installation. Consider:
• Number of updates per Sensor. Signature set and policy update times take progressively longer
with each new Sensor.
• Number of alerts and packet logs (The number of alert and packet logs sent to the Manager is
the true bottleneck for the number of Sensors than a Manager can support. Under normal
circumstances, the Manager should not receive more than 150 events per second. If this rate
continues for a long period of time, the Manager becomes backlogged and is not be able to keep
up with event processing.)
• Un-tuned policies. Un-tuned policies have the potential to overload manager resources with
inbound alerts.
• System limitations, such as the number of Virtual IDS (VIDS) supported.
Rule: This answer is highly dependent upon existing network factors and deployment options. There
is no specific X=N response. A general rule of thumb is not to exceed 50 Sensors for any given
Manager.
Sometimes the worst happens. In this age, where outages to IT systems can cost millions of dollars in
lost revenue, lost productivity, and legal issues, every organization must face the near certainty of a
system failure occurring at a future date.

Anticipating these events and planning corrective courses of action is now a prerequisite to business
success. Most organizations now employ some manner of business continuity planning (BCP), a
subset of which is disaster recovery planning (DRP). To this end, NSP has long provided a Sensor high-
availability configuration.

What if the worst should happen to the Manager server? Most companies are not willing to rely on
the manual method of Manager data archival, restoration of backups, and importing of exported
policies to recover their Manager as part of their IPS DRP.

With MDR, two Manager servers are deployed as part of NSP. One host is configured as the Primary
system; the other as the Secondary. Each uses the same major release Manager software with
mirrored databases; however, the two hosts’ hardware configuration does not need to be identical.
The Secondary Manager can be deployed anywhere; for example, at a disaster recovery site, far from
the Primary Manager.

Continued on the next page.

The Primary Manager is the active Manager by default; this Manager communicates with the
Update Server, pushes configuration data to the Sensors, and receives alerts from the Sensors. The
Secondary Manager remains in a standby state by default. While in standby mode it monitors the
health status of the Primary Manager and retrieves Sensor configuration information from the
Primary Manager at configured intervals of time.

A Sensor connected to an MDR pair maintains communication with both Managers at all times. The
Sensor sends alerts, packet logs to both the Managers. Real-time synchronization between the MDR
pair ensures that the data present in the active mode is exactly mirrored in the standby.

In case one of the Managers goes down, then after it comes up, the other Manager will update the
missed alerts and packet log data to the first Manager during the next synchronization. Sensors can
only be added to an active Manager. (A new Sensor added to the active Manager in an MDR pair
establishes trust first with the Primary Sensor, and then attempts on its own to establish trust with
the Secondary.)

The Secondary Manager is a warm standby system; it will not guarantee state synchronization with
the Primary Manager. It does update configuration information at regular intervals (every 15
minutes), but it does not maintain state. (You can also manually update Secondary Manager
configuration rather than waiting for the automatic update.)

When the NSM is installed with two Managers configured in Manager Disaster Recovery (MDR),
both Managers must be updated with Sensor alert data. How do the Sensors communicate to the
NSM to update the alert information?
The Sensor attempts to send alerts to both NSMs in an MDR configuration. If the alert was sent
successfully to one NSM, you can remove the alert from the Sensor buffer. If the Sensor cannot send
the alert to either of the NSMs, it is saved in the Sensor buffer. The Managers synchronize their
databases with each other to update any alerts that might not have been received on the other
Manager when they communicate the next time. Each alert is tagged with unique attributes to aid in
the synchronization between the Managers.
Some final key considerations necessary to ensure a successful deployment are listed below.
• Consider back-up and recovery plans: Ensure client servers and applications servers are properly
configured to revert to the previous state in the event of any problems occurring from the actual
application installation; for example, perform regular back-ups. In addition, be sure to install NSP
in a test environment first before installing it on a live system.
• Identify test systems: Identify test systems to use to test the initial deployment. Do not deploy
NSP into a production environment, without testing the deployment first.
• Consider conflicts with existing products: Refer to product documentation for potential issues
with other products working in the same environment, and any incompatibilities. For example, if
you plan to use an existing server to host the Manager software, make sure the server meets the
platform requirements for NSP.
• Ensure end-use communications: Who should be informed of changes to the environment
impacted by the product deployment, and when should they be informed? For example, if be
sure to advise IT of port usage, especially if using non-standard ports, as well as IP addresses for
the NSP platform devices.
• Apply software updates: Apply available software updates to the installation prior to full
implementation. This includes Microsoft operating system updates and patches.
• Do validation testing: What steps are necessary to ensure proper system performance?
• Follow testing procedures: Conduct necessary testing procedures on each NSP component,
including typical tasks related to everyday maintenance and use; for example, monitor database
capacity and take the appropriate actions to ensure there is an acceptable amount of free disk
space.
Change control processes ensure that changes proposed to the environment’s information resources
are reviewed, authorized, tested, implemented and released in a controlled manner. This process and
relevant procedures are dependent on the company’s requirements. However, for purposes of this
discussion, a change control process should include the following phases:
• Preparing for change: Preparation, assessment and strategy development.
• Managing change: Detailed planning and change management implementation.
• Reinforcing change: Data gathering, corrective action and celebrate successes.

Operational procedures for each of these phases should be developed to include, among others:
• Identifying, prioritizing, and implementing the change.
• Obtaining proper authorizations.
• Defining requirements.
• Determining inter-dependencies and compliance checks.
• Assessing any impacts.
• Testing.
• Evaluating user acceptance.
• Release planning.
• Documenting the change.
• Monitoring the effects.
• Defining roles and responsibilities.
• Outlining emergency change details.