In this module, you will learn about Manager deployment options.

You will also learn how

to install the Manager software on a customer-supplied server for a new deployment.

The NSP Sensors are high-performance, scalable, and flexible content processing
appliances built for the accurate detection and prevention of intrusions, misuse, denial of
service (DoS) and distributed denial of service (DDoS) attacks, and network access control
of hosts. You will learn about the Sensors basics, such as the Sensor series that Network
Security Platform (NSP) supports, Sensor features and functionality, and supported
deployment modes.

On successful completion, you should be able to:

• Identify supported deployment paths.
• Describe Manager and Sensor deployment considerations.
• Identify key features and functionality of Sensors.
• Identify key Sensor deployment options.
The Manager supports two deployment paths. The customer-supplied deployment path is
the focus of this module and course.
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.
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
other Managers. Central Manager manages the configurations and pushes them globally to
Managers.
If the customer has a large Sensor deployment (for example, 200 Sensors deployed across
various geographic locations), they should 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 using a Central Manager, the regional/local Managers can add their own region-
specific rules, but cannot modify any configurations established by the Central Manager.

NOTE
• Standard Manager (Local/Regional Manager) can be configured for redundancy (MDR).
• Manager of Managers (Central Manager) can be configured for redundancy (MDR).
Sensor placement is an individual company decision. Some things to consider are what
assets you 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 can be the most difficult part, and
most likely will be the bulk of the work in effective IPS deployment. This environment
encompasses:
• Network topology
• Network address space being monitored
• Operating systems running on the servers
• Applications running on the servers
• Corporate security policy

Network Size
The size of the customers network will determine the number of Sensors required to
successfully and efficiently protect it. 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 the redundancy
requirements needed.
Continued on the next page.
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 a customer’s critical information. These
machines are extremely appealing targets. And, as discussed in the previous section,
insiders pose a threat that must be addressed.
Customers should consider whether they need different levels of security for different
parts of the organization. Assess how much of their sensitive material is on-line. Where is
it located? Who has access to that material? In addition, it’s important to estimate the
typical volume of network traffic generated by these systems.

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 need to be monitored determine what type of Sensor will work best. 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 an organization 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 need to be protected 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. Customers should 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.
Before installing the NSP Manager software, customers should verify the following tasks
are complete.

• All parties involved need to agree to the solution design, including the location and
mode of all Sensors, the use of sub-interfaces or interface groups, and if and how the
Manager will be connected to the production network.

• You will need Administrator/root privileges on the server to properly install the Manager
software, as well as the installation of an embedded MySQL database. Also document all
account credentials to be used; for example, the NSP Database User account, MySQL
root database, and the admin account used to log into the NSP Manager interface.

• The proper static IP addresses for the Manager and Sensor need to be allocated. You can
use DHCP for the Manager server IP address assignments, but for the Sensors, you
cannot assign IP addresses using DHCP. You will need to ensure Manager name
resolution by either listing the Manager on DNS Server, or by adding the Manager’s
server name and IP to the server’s and client’s host files
(C:\windows\System32\drivers\etc). A commercial version of MySQL does not get
installed. You must use the NSP version of MySQL.

Continued on the next page.

• The ports to be used by the NSP Manager are available and open; for example, SMTP
Port 25, SNMP Forwarding Port 162, USD Port (source port to bind for IPv4), USD Port
4166 (source port to bind for IPv6).
• The unnecessary ports are closed.
• If applicable, identify the ports to be mirrored, and someone who has the knowledge
and rights to mirror.
• The Windows Regional and Language Options settings match the server’s operating
system; for example, if the server’s OS is Japanese, Regional and Language Options
must be configured for Japanese.
• The time on the Manager server is synchronized with the current time. To keep time
from drifting, use a timeserver. If the time is changed on the Manager server, the
Manager will lose connectivity with all Sensors and the Update Server because SSL is
time-sensitive. If Manager Disaster Recovery (MDR) is configured, ensure that the time
difference between the Primary and Secondary Managers is less than 60 seconds. (If
the spread between the two exceeds more than two minutes, communication with the
Sensors will be lost.)
• A desktop firewall is installed. A packet-filtering firewall is recommended 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.
• Anti-virus exclusions are configured (if applicable). Some of the Manager's operations
might conflict with the scanning processes of McAfee VirusScan Enterprise (VSE) or any
other anti-virus software running on the Manager.
• ISS or PWD are not installed on the server.
• You have identified hosts that may cause false positives; for example, HTTP cache
servers, DNS servers, Mail relays, SNMP managers, and Vulnerability scanners.
The process of setting up and running Network Security Platform falls into these basic
stages:
1. Installing the Manager
2. Deciding where to deploy Sensors and in what operating mode
3. Establishing Sensor-to-Manager communication
4. Configuring the deployment using the Manager
5. Updating signatures and software
6. Viewing and working with data generated by the sensors
7. Tuning the deployment
8. Checking in on the System Health
9. Analyze the attacks and take appropriate actions
10.Generate Reports to view the overall deployment and protection.

Each of these stages consists of a number of tasks; some are simple, some are complex.

We’ll start with installing the Manager.

Before you begin:
Always review the Release Notes and Installation Guide for complete steps, installation
requirements and known issues. Once you have met the system requirements and have
decided on deployment options you can begin the Manager installation.
1. First, Log into the server as the Administrator.
2. Close all open programs, including email, and instant messaging to avoid port
conflicts and a Manager initialization failure.
3. Disable or uninstall IIS (Internet Information Server) and PWS (Personal Web Server).
4. Close any open browsers. Open browsers may cache old class files and cause
conflicts. You will restart the server, after installation is complete.
Complete these steps on the target server:
5. Run the Manager executable file, to launch the Managing Installation Wizard.
6. The Installation Wizard starts with an introduction screen. When prompted, click Next.
6. Confirm your acknowledgement of the License Agreement by selecting "I accept the
terms of the License Agreement.“ You will not be able to continue the installation if
you do not select this option.
 7. Choose a Manager Type. The default is Network Security Manager.

As mentioned, the Central Manager applies to multi-Manager deployments, where the

Central Manager acts as a Manager of Managers. Once installed, a Central Manager cannot
be converted to Manager or vice versa.
 8. Browse and select the destination for the Manager software, if different than the
default. For a first-time installation, the default installation directory is:
• Network Security Manager: C:\Program Files\McAfee\Network Security
Manager\App
• Network Security Central Manager: C:\Program Files\McAfee\Network Security
Central Manager\App

Alert: Installing the Manager software on a network-mapped drive may result in improper
installation. The Manager software cannot be installed to a directory path containing
special characters.
9. You have the option of placing the NSP start icon in several different places, such as
the desktop, start menu, and so forth.
10. Define password for Default User Account. These credentials are required to access
the Manager GUI, after setup is complete. For training purposes, the password defined
is admin123.
11. Define the database connection. The database user account is configured to enable
communication between the database and the NSP Manager. If no database is
installed, a pop-up window prompts you to install the database. Install, as directed.
• Database Name: It is recommended to keep LF in the name of the database for
troubleshooting purposes (for example, LF_NSPdatabase) if you want to have a
name other than the default.
• Database User and Database Password: These parameters are user-defined.
• Use a combination of upper-/lower-case letters, numbers (0-9), and/or special
characters.
• Do not use null or empty characters.
• The first character of the Database name must be a letter. Do not exceed
16 characters.
• For security, ensure the Database User password is different than the password
for the MySQL root.
 12. Define MySQL Root Password for MySQL database administration.

Use these guidelines:

• Use a combination of upper-/lower-case letters, numbers (0-9), and/or special
characters.
• Do not use null or empty characters.
• The first character of the Database name must be a letter. Do not exceed 16
characters.
• For security, ensure the MySQL root password is different than the password for the
Database User.
 13. Specify the installation directory for Apache Solr. Solr is a fast, open source enterprise
search platform, with a with a REST-like application programming interface (API).

The Manager uses Solr to enhance database access. At least 20 GB of free disk space is
required on the drive on which Solr is installed.

For more information about Solr, go to http://lucene.apache.org/solr.

 14. Optionally, tune maximum virtual RAM usage. The Physical server memory divided by
2 or 1170MB, whichever is greater.

The RAM size indicated here determines the recommended amount of program memory
(virtual memory) to allocate for server processes required by Network Security Platform.

The Recommended Maximum RAM Usage is Physical Server Memory divided by 2 or 1170
MB, whichever is greater. The Actual Maximum RAM Usage can be between 512 MB up to
the Physical Server Memory size. Since JBoss memory uses hard-disk-based memory
(program memory), the total amount of both can exceed the Manager server's RAM
memory size.
 15. You are prompted to enter the number of Sensors to be managed. The system uses
your entry to automatically configure the maximum number of simultaneous
concurrent database connections. You can keep or modify the automatic calculation.

The recommended settings are:

• 1-5 Sensors = 40 connections
• 6-20 Sensors = 50 connections
• 20+ Sensors = 60 connections

If the Manager server has multiple IP addresses, you can specify a dedicated IPv4 and IPv6
address for communication with the Sensors. This option displays only if the Manager has
more than one IP address.
NOTE: If IPV6 is NOT used then ensure that the protocol is disabled on the NIC. It avoids
Manager start-up issues - if ipv6 is enabled on the NIC and it is set for DHCP (which it is by
default) it creates an APIPA (prefix FE80::/64) address which is non-routable and the
manager service cannot bind to it.
 16. If the Manager server has multiple IP addresses, you can specify a dedicated IPv4 and
IPv6 address that it should use to communicate with the Sensors.

The option to specify a dedicated interface is displayed only if the Manager has more than
one IP address.
17. You are prompted to review the installation settings before completing the install
process. Click Previous to make corrections. Click Install, after you are satisfied with
the settings.
Wait while the Manager database is initialized.
You are then prompted to validate all the installation settings before proceeding. After the
installation is complete a congratulations message is displayed.

A reboot is required after successful installation completes. Restart the server manually if
not prompted.
This section assumes you have permissions granting you access to the software. In the
NSP, this translates to a Super User role at the root admin domain. Your actual view of the
interface may differ, depending on the role you have been assigned within NSP; for
example, certain tasks may be unavailable to you if your role denies you access.
Connect to the Manager server with a supported browser at this address:
https://<hostname or host-IP>.

If there is a problem with the website’s security authority, click the link to continue to the
website.
Add the Manager server to the Trusted Sites zone.

The figure shows the Trusted Site configuration using Internet Explorer.
To eliminate the certificate error message, complete these steps form the Login window.
1. Click the Certificate error button on the title bar at the top of the page. Do not
attempt to log into the Manager at this time.
Installing the Security Certificate (Continued)
2. An Untrusted Certificate dialog appears. Click View Certificates. A Certificate
Information dialog appears.
3. From the General tab, click Install Certificate.
Installing the Security Certificate (Continued)
4. From the Welcome to the Certificate Import Wizard dialog, click Next.
5. Click the Place all certificates in the following store radial button, then click Browse
to locate the certificate.
Installing the Security Certificate (Continued)
6. From the Select Certificate Store dialog, select Trusted Root Certification
Authorities, then click OK.
7. Verify the Certificate store field, then click Next.
Installing the Security Certificate (Continued)
8. From the Completing the Certificate Import Wizard dialog, click Finish.
Installing the Security Certificate (Continued)
9. When prompted, click Yes to install the certificate.
10. You are alerted when the import is successful. Click OK.
Complete these steps to log into the Manager.
1. Connect to the Manager server with a supported browser at this address:
https://<hostname or host-IP>.
2. Disable pop-up blockers. Turn off any automatic update settings in the browser.
3. Enter a valid Login ID and Password defined on the Manager.
• Login ID: admin
• Password: <defined during install>
Note: If logging in from the Manager appliance, the Login ID is ismadmin and
Password is admin123$.
4. Click Login.
5. If prompted, click Yes to let the web page close the window.

Continued on the next page.

You are prompted to run the Manager Installation Wizard, and enter basic setup
information. If you do not have the information, simply close the Wizard. You can later
launch the Wizard from the Manage page.

For training purposes, we will not walk through the installation wizard.

At any time, you can go through the installation wizard setup procedures from the Manage
page. The Manage page is accessed by clicking the Manage icon on the menu bar.
The Manager Dashboard page appears after a successful login to its interface. This
interface is the launching point for NSP configuration and management. Access and
permissions are controlled by the user account. In this beginning, you will access the
Manager with the default root admin account, which provides full access to the NSP tasks
and resources.

The Dashboard includes a combination of Operational and Security panes. You see threat
and attack information at a glance and can immediately drill down to detail.

Java Script
Java script is incorporated, allowing some menu object to display more quickly in the
browser and reduces overhead since fewer java applets are being downloaded and
interpreted. There is not a definitive schedule for making the entire UI Java script at this
time. Legacy screens remain java applets.
The NSP Manager pages are organized by task to simplify navigation and use. Let’s take a
look around the entire user interface. This will help you understand where the various
configuration options are located, and where you can view event details.

The Dashboard is the landing page when first logging in. It provides a snapshot of system
operations and security. It links to detail pages, allowing you to quickly drill-down for more
information.

You can use the menu bar to logically navigate around the user interface based on what
task you want to perform. From the menu bar, you have access to the following task-
based pages:
• Dashboard: Obtain quick view of system operation and security.
• Analysis page: Perform network and events analysis.
• Policy page: View, edit, and configure policies from a central location.
• Devices page: Manage and configure devices (Sensors); for example, add and edit. It
has two tabs: Global and Device.
• Manage page: Configure and maintain the Manager, users, third-party servers, Manage
system operations and users, as well as application integration.

Access and permissions are controlled by the user account.

The Manager menu bar, located at the top of the pages, is a primary navigational control.
Each Manager page is represented by an icon. You simply click the icon for the page you
want to access. The Manager also provides icons and other controls; for example, to
customize your view (expand, collapse), log out of the Manager, or access the NSP online
Help pages.
The table here, highlights the controls specific to monitors.

NOTE: Data displayed in the Top High-Risk Endpoints monitor is automatically refreshed
by the Manager on an hourly basis. This is not user configurable.
As you have probably noticed, the Dashboard is customizable. Customers can customize
the Dashboard with the pre-built monitors available.
Use the Dashboard Settings dialog to select which monitors to display, the refresh rate,
and number of columns to display.
The checked off monitors will be displayed on the Dashboard. Not all monitors are
displayed, by default.

Shown here are the available Operational monitors. Simply check/tick the monitors you
want to display on the Dashboard.
Remove the check/tick to hide a monitor from the Dashboard.
Use the Automatic Refresh and Layout drop-down lists to modify these parameters. The
default for Automatic Refresh is 1 minute. The default for Layout is 3 Columns.
Selecting a different set of monitors, such as Security will display a list of the available
Security monitors. Again, notice that selected monitors are checked/ticked. This means
that only these selected monitors will be displayed on the dashboard.
Let’s quickly review the available monitor types, starting with Operational monitors.
Operational monitors provide a quick glance of the system’s status and operation.
• Device Summary: The Device Summary monitor shows the current versions of the
Sensor software and signature set of the logged in domain.
• Manager Summary: The Manager Summary monitor shows Manager details, such as
software and signature set version.
• Messages from McAfee: The Messages from McAfee monitor displays any product or
security-related messages from McAfee. The messages can be related to operating
system patches, signature set release, Manager software update, Sensor software
update, and so on.
• Running Tasks: The Running Tasks monitor displays the status of currently
in-progress activities on the Manager that the NSP identifies as long-running
processes. This monitor corresponds to Running Tasks in Troubleshooting folder on
Manage page.
• System Health: The System Health monitor displays the current health of the Manager
and installed Sensors, and links to System Faults in Troubleshooting folder on Manage
page for more detail. Based on the severity of issues, the System Health displays
messages, such as whether Manager/Sensor is up or down.
The System Health monitor displays the current health of the Manager and installed
Sensors in the system. Based on the severity of issues, the System Health displays
messages, such as whether the Manager or Sensor is up or down. The alert counts greater
than zero are hyperlinked to the System Faults page.
Any messages sent by the Manager or Sensors are displayed in three categories, Critical,
Error, or Warning. When you click on the values displayed under various columns, you are
redirected to the page that displays information concerning the value.
The Status column shows the functional status for all of the installed NSP components. By
double-clicking on the values, you can drill-down for more information.
The color scheme (except for the Status columns) reflects the number of current
unacknowledged alerts.
• Green: If all cells are green, there are no unacknowledged alerts for that component.
• Blue: If cells for a component are blue, there are one or more unacknowledged
Informational alerts for that component.
• Yellow: If cells for a component are yellow, there are one or more unacknowledged
Warning alerts for that component.
• Orange: If cells for a component are orange, there are one or more unacknowledged
Error alerts for that component.
• Red: If cells for a component are red, there are one or more Critical alerts that are
unacknowledged for that component.
The fields are hyperlinked to let you drill-down to detail for an isolated alarm. In the
example, we have clicked the link for the Manager Critical alarm from the System Health
monitor on the Dashboard.

The System Faults page opens, showing the details for this alarm.

From the detail page, you can:

• Acknowledge: Mark the fault as recognized.
• Unacknowledge: Unacknowledge an acknowledged fault. Sets the Ack. field to blank.
(Default)
• Delete: Remove the selected fault completely from the System Health view.
 No longer appear in the n/n counts.
 Different from Acknowledge because Delete is a complete removal, while
Acknowledge leaves the fault in the System Health for later analysis.
• Close: Return to the System Faults page.
Now let’s quickly look at the Security monitors. The Dashboard page displays the top
threats as security monitors. This helps you quickly view and investigate the top threats in
the network.
You can hover over any of the event alerts (bar graph) for more information, and the fields
are hyperlinked to let you drill-down to detail. Meaning that if you click on any of the event
alerts, you will be taken to the corresponding details of the event, under the Analysis tab.

The Manager provides these security monitors:

Top N: Hyperlinked to the Threat Explorer, which is access from the Analysis page.
 Top Active Botnets: View the top active botnets on the network.
 Top Applications: View the top N applications on the network. You can filter
applications by bytes, attacks, or connections. Available with NSP 8.0 and later.
 Top Attack Subcategories: View the attack subcategories in the network.
 Top Attacker Countries: View the top attacker countries in the network.
 Top Attackers: View the top attackers in the network.
 Top Attacks: View the top N attacks on the network.
Top N Monitors (Continued)
 Top Endpoint Executables: View the top executables based on number of endpoints
using them or the number of attacks they have initiated. This monitor is populated
only if you have enabled McAfee Endpoint Intelligence Agent (EIA integration).
 Top High-Risk Endpoints: View the top N applications on the network. Data displayed
in the Top High-Risk Endpoints monitor is automatically refreshed by the Manager on
an hourly basis (not configurable). The attack counts per malware phase are classified
as Exploits, Infections, and Callbacks.
 Top Malware Detections: This monitor is populated when a malicious file has been
detected. It shows the File Hash and the Attack Count of the detected malware.
 Top Target Countries: View the top target countries in the network.
 Top Targets: View the top targets in the network.
Unacknowledged Alert Summary: Hyperlinked to the Real-Time Threat Analyzer, which is
access from the Analysis page. Here you can view unacknowledged alerts in the database,
sorted by severity.
Alerts are categorized by system impact severity level: High, Medium, Low, and
Informational. Like the System Health monitor, the fields are color-coded by severity. Alert
counts greater than zero link to details.
Again, you can click a link in any of the Top N monitors, to view corresponding details
under the Analysis tab. In the figure, we clicked the Zeus botnet from the Top Active
Botnets monitor. The Active Botnets page opens, under the Analysis tab, with
corresponding details, such as:
• About: Click to download the Detailed Botnet Report. The comprehensive botnet
report provides information such as the botnet description, symptoms of the bot, bot
prevention methods, bot removal tips etc.
• Name: Displays the name of the botnet family.
• C&C communication: Displays the status of the bot's communication with the
Command and Control server, whether blocked or unblocked.
• Events: Displays the number of bot events.
• Last Event: Displays the date and time of the occurrence of the last event.
Click the Help icon on the active page to view context-sensitive help, including more
information about each field.
The Unacknowledged Alert Summary monitor, of the Dashboard page, displays statistics
for the unacknowledged alerts in the logged-in domain. Alerts are categorized by system
impact severity level: High, Medium, Low, and Informational. Like the System Health
monitor, the fields are color-coded by severity.
Now let’s take a look at the Analysis tab. Under the Analysis tab are pages used for
analysis, threat monitoring, and event reporting. It also populates the dashboard summary
monitors. A brief description on the available pages is listed here. We’ll take a close look
at each page, in the upcoming sections of the training.
The Policy tab, is accessed by clicking the Policy icon on menu bar. Like the other tabs, it
provides access to sub-pages, which are used to configure and manage the security
policies, this includes IPS, firewall, etc. Many of the pages offer preconfigured policies for a
quick start.

Note that a policy is a set of rules that governs what traffic will be detected and how to
respond to detected events.
The Devices tab helps you to manage and configure the devices, such as NSP Sensors. The
navigation pane is organized by two tabs:
• Global: Manage functionalities related to the devices, such as failover pairs, add and
remove devices, and so on.
• Devices: Manage individual device-specific configuration.
The Manage page allows you to manage the system. The types of tasks you can perform
from the Manage tab, include:
• Updating: View important information regarding the update and upgrade of the
software. Download the latest attack and signature information, botnet detectors, and
Sensor device software.
• Users and Roles: Add users and assign roles to them thereby granting the users
specific privileges to use every security resource deployed in the deployment.
• Setup: Create the admin domains and child admin domains, view the alert
notifications, configure Manager Disaster Recovery (MDR) pair, etc. It’s where you
would configure proxy and email server information, if needed.
• Integration: Manage and configure the integration of Network Security Platform with
other McAfee products, such as ePO, GTI, etc.
• Reporting: Generate configuration reports to view the current software and signature
versions, the configuration and status of a Sensor, policy settings, configure report
automation, and define report preference (such as language).
• Maintenance: Maintain the device by archiving, pruning, backing up data, and others.
• Troubleshooting: View all the product-specific announcements, the system logs, and
system faults. This also gives the details about background processes initiated by
administrative users, alert relevance analysis, MDR pair switchover events, Manager
policy cache, and helps you to audit the actions of users on the Manager.
As mentioned, the Updating pages provides you with important information regarding the
update and upgrade of the software. You can download the latest attack and signature
information, botnet detectors, and Sensor device software from these pages.

Here is also where you can configure Automatic Updating. The Manager allows you to
schedule the download and deployment of the signature set and callback detectors. Once
configured, the scheduler downloads the signature set and callback detectors from the
McAfee Update Server to the Manager. The success/failure of the import process is
indicated through fault notifications, emails, and SNMP traps.

Once the new signature set and callback detectors are available on the Manager, they can
be scheduled to be deployed on the Sensor devices.
Under the Setup page, is where you create the admin domains and child admin domains,
view the alert notifications, configure Manager Disaster Recovery (MDR) pair, E-mail and
Proxy server settings, etc.
The Help button is also available within the UI and it provides rapid access to Online help
topics. When on a particular page in the console, in the Threat Explorer for example,
clicking on the ? will bring up a new window showing related help information regarding
the page you are on.

Online Help is accessed two ways:

• Overall Help: Click the question mark icon, located top right of the menu bar.
• Context-sensitive Help: Click the question mark icon on an active page.

You navigate the Help system using the Contents tree in the left pane, the Index tab, or
Search tab. You can view information online and optionally print selected topics.
Tip: If you are new to NSP or need a refresher, the Ten Steps to using Network Security
Platform is a helpful resource.
The primary function of a Sensor is to analyze traffic on selected network segments and to
respond when an attack is detected.

The Sensor examines the data packets (including header and data portion) that cross the
network, looking for patterns and behavior that indicate malicious activity. It responds with
countermeasures if it detects an attack. Examples of responses are:
• Generate alerts and packet logs.
• Reset TCP connections.
• Scrub malicious packets.
• Block packets.
• Quarantine a system.

McAfee NSP offers both virtual and physical Sensors.

Enterprises are moving towards virtual IT infrastructures such as private and public cloud,
virtual data centers for servers, and virtual machines for clients. A Virtual IPS Sensor is
McAfee’s virtual next-generation IPS product. It is a virtual instance of the NS-series
software, which can be installed as an appliance on a VMware ESX server. Though primarily
designed to protect virtual networks, you can deploy a Virtual Sensor to protect physical
networks as well.

The Virtual IPS Sensor is available as an OVA image.

A Virtual Sensor supports most of the features that are supported by physical Sensors.
Except for the fact that you deploy Virtual Sensors in a virtual environment, the process of
configuring and managing them is similar to that of physical Sensors. Customers can
deploy Virtual Sensors to protect various network architectures. Though protecting virtual
networks has its unique challenges, there is no compromise on security with respect to
Virtual Sensors. It protects networks similar to a physical Sensor.

The VM100 Sensor supports a maximum throughput of 100 Mbps.

The VM600 Sensor supports a maximum throughput of 600 Mbps.
McAfee offers multiple Sensor platforms providing different bandwidth and deployment
strategies. This slide displays the available I-Series appliances.

Sensors are equipped with multiple monitoring and response ports. A single multi-port
Sensor can monitor many network segments in any combination of deployment modes. By
default, the Sensor ports are internally wire-matched in pairs (that is, 1A and 1B, 2A and 2B,
3A and 3B, and so on) to monitor traffic in full-duplex pairs. The two detection ports work
together to monitor traffic flowing in both directions.

The Sensor’s behavior is governed by security policies (Rule Sets) applied to the Sensor, its
ports (interfaces), or sub-interfaces (Virtual IPS).

Communication between Sensors and the Manager is over secure channels. These
channels provide link privacy using encryption and mutual authentication, using public key
authentication.
Let’s take a look at the available sensor models. The Sensor portfolio includes scalable
appliances to support deployments of all sizes and complexity. McAfee has an Sensor built
for every customer’s particular needs, whether it be for performance from 10/100 Fast
Ethernet all the way up to 10Gigabit Ethernet networks. Deployment of NSP requires
specific knowledge of the network's security needs. The M-1250, M-1450, M-2750/2850,
and M-2950 are generally suitable for branch office and perimeter deployments. The M-
3050, and above, are powerful enough for deployment in the core network. Customers
should always refer to the McAfee Device Administration Guide to determine which Sensor
model best suits their environment.

The M-Series Sensors are rack-mountable appliances that are equipped with Fast Ethernet
ports (or interfaces) for real-time monitoring at wire speeds. The Sensor’s VxWorks
operating system is complemented with a hardened Linux OS, which supports the
management CLI through the console port or via SSH and provides management functions
to the monitoring and decoding processors. The Linux shell is separated from the traffic
processing and inspection engine and is completely isolated from the monitor ports so it
cannot be exploited from the monitored segments. Communication between Sensors and
the Manager is over secure channels. These channels provide link privacy using encryption
and mutual authentication using public key authentication.
The high-port density NS-Series Sensors are designed for high bandwidth links, to provide
IPS/IDS capability with an aggregate performance of up to 20 Gbps on NS-9200 and 10
Gbps on NS-9100, while monitoring segments in the full duplex mode (tap or in-line).
All Sensors contain the following components:
Monitoring Ports
• The monitoring ports are the ports through which network traffic flows for analysis.
Response Ports
• In SPAN or Tap mode, response ports can be used to send Transmission Control
Protocol (TCP) resets back to the attacking host, some Sensors can reconfigure firewall
settings via the response port.
Management Port
• The Sensor communicates with the Manager using the management port.
Administrators can connect to the Sensor’s Command Line Interface (CLI) remotely
over Secure Shell (SSH). The management port is a standard Ethernet port to which
you must bind an IP address before it can be used.
Console Port
• The console port provides direct access to the Sensor CLI over a standard RS-232
cable.
The figure of the M-2750 provides an example of the Sensor components. The M-2750 is a
two rack-unit (2U) box equipped with the following ports:
• Twenty GBIC Monitoring ports, which can monitor Gigabit Ethernet segments
transmitting up to 600 Mbps of sustained traffic.
• One Response port, which, when operating in SPAN or Tap mode, allows the sensor to
inject response packets back into the network (via a switch or router).
• One 10/100 Management port, which is used for secure communication with the
Manager server. Communication between the sensor and the Manager uses secure
channels that provide link privacy using encryption, and also mutual authentication
between sensors and the Manager using public key authentication. This port is a
normal Ethernet network interface with an assigned IP address.
• Built-in internal Taps, which are used with the 10/100 ports to provide stealth mode
monitoring functionality and forgo the need of an external Tap or connection to a
SPAN port or hub. When a pair of 10/100 ports are configured to monitor a network
segment in peer mode, their internal Tap allows a network segment to be connected
directly to the sensor. One port receives/transmits from Device A (such as, a firewall,
router, switch) and the other port receives/transmits from Device B.
• You can also change dynamically from internal Tap mode to in-line mode. The internal
Tap is fail-open, meaning that should the sensor fail physically while running in
internal Tap mode, the connection is not disrupted; the network traffic will continue to
flow unimpeded.
• One power supply, with optional redundant power supply.
• Port 10A is used for failover.
Displayed here is an example Sensor deployment. Placing the NSP at the perimeter blocks
attacks from getting into the network. You can place the appliance in front of the firewall or
behind it. An NSP placed internally can protect VLAN traffic and contain outbreaks and
attacks to a particular segment by quarantining a network segment. At the core, the M-
series appliances offer the high bandwidth and availability to protect the data center and
core network devices.

NSP offers flexible network deployment options: In-Line, Port Clustering, high-availability,
SPAN, and Tap modes.

Sensors, by default, are configured to operate in in-line mode. The operating mode can be
changed via the Network Security Platform user interface.

Often products are deployed in SPAN mode, because it merely requires connecting the
Sensor and reconfiguring a setting on the switch.

Other modes of Sensor deployment—In-line mode or Tap mode—involve connecting the

sensors within the flow of traffic, which requires some network downtime.
The NSP offers flexibility in Sensor deployment. Sensors can be deployed in a variety of
topologies and network security applications, providing industry-leading flexibility and
scalability. Key deployment options are:
• Multi-port Sensor deployment: A single multi-port Sensor can monitor many network
segments in any combination of deployment modes.
• Flexible deployment modes: Every port on the Sensor supports the following
deployment modes:
• In-line (default)
• SPAN or hub
• Tap
• Virtualization: Virtual Sensors (also known as sub-interfaces) enable you to further
segment a port (interface) on a Sensor into many Virtual Sensors. This allows you to
use one Sensor to monitor multiple network segments.
• High-availability (in-line mode only): Using an identical pair of Sensors (same model,
software image, signature set) deployed redundant the in-line mode, the NSP provides
high availability with no administrator intervention.
• Port clustering: An interface group, also known as port clustering, combines the traffic
processed on separate Sensor interfaces into a single logical interface for state and
intrusion analysis.
• Large Sensor deployments: Scalable deployment options.
When deployed in-line, the Sensor is placed directly in the path of a network segment so
that all traffic must pass through the Sensor for inspection.

Benefits of this mode are:

• Protection and prevention: The Sensors function like an adaptive firewall and drop
malicious packets, based on defined detection policies.
• Packet scrubbing: The Sensors scrub (normalize) traffic to take out and remove any
ambiguities in protocols that the attacker may be using to try to evade detection.
• Processing at wire-speed: The Sensors process packets at wire rates to avoid
dropping packets and reduce bottlenecks.
• High-availability: When redundant Sensors (identical Sensor pairs) are deployed, the
Sensors support stateful fail-over. This is recommended to prevent a single point of
failure.

Important: In-line is the only mode that lets you prevent attacks from reaching the target.
When in SPAN or hub mode, the Sensor is connected to the Switch Port Analyzer (SPAN)
port of a switch or to a port on a hub. The SPAN port forwards all incoming and outgoing
traffic within the switch to a predetermined port where the Sensor is attached for
monitoring. This is also known as port forwarding or port mirroring.

When monitoring SPAN ports and hubs, traffic is typically half-duplex. Only one monitoring
port is required.

McAfee recommends cabling the Fast Ethernet ports with fail-closed dongles if deploying
in SPAN or Hub mode.
SPAN Considerations
• Sensors configured in SPAN mode do not prevent attacks from reaching their target.
• It is very easy to saturate a SPAN port.
• A SPAN port really only operates in a half-duplex mode (transmit to the Sensor only), so
the maximum bandwidth the port can handle is 100Mbps (when using a Fast Ethernet
port), and when you exceed the 100Mbps limit of the port, you are not copying all the
packets seen on the switch.
• You can assign a response port to more than one monitoring port. However, knowing to
where in the network the response ports are connected will make for the best response
system.
When in tap mode, the Sensor is hardwired to a network device known as a tap. The tap
makes an exact copy of traffic on full-duplex Ethernet segments, and sends this
information to the Sensor for analysis. The tap splits the full-duplex link into separate
transmit and receive channels. To monitor both channels, the Sensor requires transmit and
receive interfaces.

The benefits to using Sensors in tap mode are:

• Monitor uplinks passively: Taps cause no latency in network traffic. It essentially
sniffs traffic as it passes.
• No need for SPAN ports: On most switches, the SPAN port operates in half-duplex
mode, so the maximum bandwidth a Fast Ethernet port can handle is 100Mbps
before it begins dropping packets. Another issue is that there are a limited number of
SPAN ports supported on most switches, and there is typically a lot of competition
for them (for example, for RMON probes, sniffers, etc.).
• Traffic continues to flow if the tap fails: Completely passive and fault tolerant, taps
provide fail-safe operation with no impact on network connectivity or performance.
Taps fail open, meaning that a failed sensor permits traffic to continue to flow
unimpeded.
The downside of tapped mode is that, unlike in-line mode, you cannot prevent attacks. Tap
mode is passive. The Sensor essentially sees malicious traffic as it passes, so sensing an
attack in tap mode triggers a response post-attack.
With a high-availability configuration, Sensors failover pairs (same model, software image,
signature set) are deployed. One Sensor is designated as the primary (active) device, while
the other is designated as the secondary (standby) device. Traffic is copied and shared
between the two devices so they are synchronized at all times; however, the primary device
performs normal network functions. The secondary device takes control if the primary
device fails. This is know as a failover or switchover.

Both Sensors see all traffic packets (when both are operational); however, only one Sensor
in the pair raises an alert if an attack is detected.

Important: High-availability is only supported when the Sensors are in-line. McAfee
recommends a high-availability configuration to ensure reliability and to prevent
disruption in operations.
Sensor ports can fail-open or fail-closed. Similar to firewall operation, the fail-open/fail-
closed configuration determines if the Sensor lets traffic pass if a port or Sensor fails. The
default is fail-closed. Fail-open applies only to Sensors deployed in-line.
• Fail-open: Ports configured to fail open allow traffic to continue to flow, preventing a
bottleneck. Monitoring ceases, however, which may allow bad traffic to impact network
systems.
• Fail-closed: Ports configured to fail closed do not allow traffic to continue to flow. All
traffic stops at the Sensor, causing downtime and a potential bottleneck.
Fail-Open Bypass Switch
A bypass switch, also known as a fail-open kit, is required for a fail-open configuration.
With the bypass switch in place, normal Sensor operation supplies power to the switch
through a control cable. While the Sensor is operating, the switch is on and routes all traffic
directly through the Sensor. When the Sensor fails, the switch automatically shifts to a
bypass state.
Some Sensors require an external Fail-Open Kit to support a fail-open configuration.
Fail-open operation for GE ports requires use of the optional Bypass Switch provided in the
Gigabit Fail-Open Bypass Kits (sold separately).

See KB50316 – Network Security Platform Sensor interface configuration deployment

guide.

Continued on the next page.

Fast Ethernet ports do not Fail-Open when the M-2850/M-2950 Sensor is powered off.

Problem
Sensors M-2850 and M-2950 that meet the following criteria will not fail open when the
Sensor is powered down:
• Have a single power supply
• Use the Fast Ethernet ports (ports 7 through 10)
• Are configured as In-Line Fail-Open
This will cause any traffic passed through these ports to be blocked.

NOTE: The M-2850 and M-2950 Sensors that include dual power supplies will not
encounter this issue. This is true regardless of whether or not the second power supply is
connected to a power outlet.

Solution
To resolve this issue, insert a redundant power supply into the secondary power slot
and plug it in to the power outlet.
During normal Sensor in-line fail-open operation, the Active Fail-Open Kit sends a
heartbeat signal (1 every second) to the monitoring port pair. If the Active Fail-Open Kit
does not receive 3 heart beat signals within its programmed interval, the Active Fail-Open
Kit removes the Sensor’s monitoring port pair from the data path, and moves the Sensor to
the bypass mode, providing continuous data flow.

While the Sensor is in bypass mode, traffic passes directly through the switch, bypassing
the Sensor.

When normal Sensor operation resumes, you may or may not need to manually re-enable
the monitoring ports from the Manager interface, depending on the activity leading up to
the Sensor’s failure.
You can access the AFO kit via the kits Web GUI by opening a browser and pointing it to the
IP address of the AFO Kit. (Default login is McAfee/McAfee)

Using a DB-9 RS232 programming cable, connect a PC that is running the HyperTerminal
to the Bypass Switch. This will allow you to set the Bypass Switch parameters.

NOTE: For information on the CLI commands, see NetOptics Documentation.

You should be familiar with the terms Virtual IDS (VIDS), Virtual IPS (VIPS), and sub-
interfaces. These terms all refer to a concept more generally known as virtualization.
Virtualization (sub-interfaces) is an intermediate-to-advanced configuration option. As an
overview, virtualization provides scanning granularity, allowing customers to tailor a single
Sensor solution as if it was a multiple-Sensor solution.

With virtualization, customers can apply different scanning policies to different types of
traffic flowing through the same interface. Valid interface types are:
• Dedicated: Virtualization is disabled.
• VLAN (Virtual LAN): The Sensor applies policies according to VLAN tags.
• Bridge VLAN: The Sensor changes the VLAN tag of the traffic to the a specified tag.
• CIDR (classless inter-domain routing): The Sensor applies policies according to the IP
address of one or more hosts.

Each interface and sub-interface maintains a unique denial-of-service (DoS)/distributed

denial of service (DDoS) profile. This is helpful in situations where one host tends to have
traffic patterns that are significantly different from the rest of the hosts sharing the
interface.
Port clustering is used when a company has two different active traffic paths to and from
the Internet that pass through two different Sensor interfaces. If a single communication
flow is divided across paths, each interface receives and analyzes only part of the
conversation, which can result in false positives and false negatives.

Port clustering, referred to as Interface Groups in the Manager interface, enables

customers to group multiple ports on a single Sensor for traffic monitoring. This strategy is
particularly useful for asymmetrically-routed networks where send and receive traffic does
not always take the same path.

You cluster ports when you want the traffic across multiple interfaces to be analyzed as if it
were a single interface. When you create an interface group that contains both interfaces,
the sensor is allowed to receive and properly analyze the entire communication.
You can deploy a single Sensor to monitor the several external and internal points of
exposure of an enterprise network. This includes the web presence, corporate Internet
access for employees, employee remote access, extranet connections, and internal attacks
on critical department servers, such as finance and human resources.
NSP can protect the entire enterprise by placing Sensors in the appropriate places in the
network. The figure is a high level example of a possible topology.
• At the Perimeter: We block external attacks from getting into the network. You can
place it in front or behind the firewall, as well as protect any Demilitarized Zone (DMZ)
servers from malicious attacks.
• Internally: Through the Sensor’s ability to protect VLAN traffic (Virtual IPS), the
customer can define different policies of protection depending upon the group’s needs
with one device. If Engineering encounters an attack, for example, the Sensor can
quarantine the problem to just that segment.
• At the Core: With the M-Series capable of up to 10 Gigabit performance and 10GigE
connections, you can protect critical core servers in the data center and protect the
high-speed backbone.
Because the Sensors are multi-port devices, each Sensor can accommodate multiple
polices using the Virtual IPS feature. This reduces the number of Sensors required to cover
a particular network.
To install a new Sensor, the customer should have the appropriate rack space and power in
place. Once you unpack the Sensor, install the slide rails, add ears to the Sensor and mount
it. More than one person should assist since some Sensors are very heavy. There is a quick
start guide that covers all the steps in getting the Sensor initially up and running.

After a Sensor is in place, additional information is needed to complete the install,

including how do you want the monitoring ports to connect, and to what devices. Basic
network configuration information such as name, IP address, secret key for establishing
trust to the manager must all be established and configured on the system before it will
communicate over the network, and until then console access to the Sensor is required.
The NSP is built with growth in mind. The NSP can manage multiple Sensors, and the
Sensor infrastructure can scale in performance from 100 Mbps to multi gigabits per second
for monitoring network segments. McAfee gives alternatives in connectivity from branch
offices to internal network segments to the very core of the data center.

The size of the network and performance/bandwidth requirements determine the number
and type 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 greater
number of Sensors with performance/bandwidth capabilities than a small branch office
with a single access point and few network machines.
This graphic depicts how to gradually deploy a new Sensor in a network. Customer should
fully understand how the Sensor functions in the network with the company’s applications
and traffic so that they can build policies that block real threats and not necessary traffic.
The path to Intrusion Prevention is based on first building the trust and comfort that the
Intrusion Detection is working.

Customers can increase their confidence that the system is working correctly by starting
with only detecting attacks, and increasing the prevention of attacks by slowly working
towards broad prevention. The NSP implementation modes allow for this smooth process
to progress to a complete Intrusion Prevention Solution.

For Phase 2/Phase 3 the customer can also use "IPS Simulation Mode" which will not
actually block but will tell if it WOULD have blocked. This allows customers to determine if
the "block" would have impacted any valid network traffic/applications.

Refer to the NSP Installation Guide for more details on a phased deployment.
The process of setting up a Sensor is described here, at a high level.
Before you begin, establish a Sensor naming scheme.
1. Position the Sensor.
• Unpack the Sensor and place on a sturdy, level counter top.
• Attach the provided rack mounting ears to the Sensor.
2. Mount the Sensor in a supported rack. Sensors are either 1RU or 2RU, depending on
model.
3. Install any additional hardware; for example, Fail-Open Kit (if required) or redundant
power supply (optional).
4. Cable the Sensor.
• Ensure the Sensor is powered OFF before attaching cables.
• Cable the Sensor to communicate with the console machine to be used to initialize
the Sensor, then cable the Sensor to the Manager server. Last, cable the Sensor
detection and response ports.
5. Power on the Sensor to start initialization.
6. Launch an application such as HyperTerminal or PuTTY, then run the CLI setup wizard
to configure network configuration settings.
7. Verify network connectivity. Also verify that the appropriate ports are open ports on
routers or other devices between the Sensor and Manager that are needed for trust
establishment and actual communications.
The following parameters should be configured on the Sensor:
• Sensor Name: Appears as part of CLI login prompt for example, EastTower-1450 Login.
It is good practice to make the name as descriptive as possible.
• Username and Password: Security benefits to changing the default password are
obvious. The root username (admin) cannot be changed.
• Sensor IP address and mask: Needed for Manager network connection to the sensor.
• Shared Secret Key: Establishes a trust relationship between the sensor and the
Manager. It must be the same for Sensor and Manager. Since the default is none, this
should be changed to protect against a security breach. The secret key value can
consist of up to 25 characters of ASCII text, printable characters in the ASCII 32
through ASCII 126 range. The shared key value is case-sensitive (for example,
IDSkey123). The sharedsecret, sensor name, sensor IP are combined to create a DES
56-bit key, used to encrypt communications with the Manager.
• Manager IP address: Provides more security for the connection. If it is left at the
default, it will accept any Manager server.
• Gateway IP address: Is necessary for communication between the Sensor and Manager,
if they are on different networks.

The setup command can be used to start a setup wizard that prompts for basic
configuration settings.
The status command can be used to verify configuration.
It is a common practice to physically cable the monitoring ports only after the Sensor has
been fully configured.

Many administrators cable the console and management ports, use those connections to
configure the solution, and only physically introduce the Sensor into the scanning process
once the proper scanning policies are in place, the monitoring ports have been configured,
the latest signature set has been downloaded, and so on.

Also, in the most security-conscious environments, or those with congestion problems, a

private network is often used to connect the Sensor management ports to the Manager.
This is another best practice in terms of cabling the Sensors.
HyperTerminal and PuTTY are terminal emulation programs that let you connect to other
machines; for example, management consoles, Telnet sites, other computers, and so on.
They provide an alternative communication method to a direct connect to the Sensor.
Sensor Name
You cannot change a Sensor’s name after it is configured so establish a naming scheme
prior to deployment. McAfee recommends that customers establish a naming scheme that
is meaningful, is easily recognizable to other users, and supports uniqueness. As an
example, if deploying Sensors at a university, you might name the Sensors according to
their location on the campus: Sensor1_GarrisonHall, Sensor2_SuttonHall, and so on.
Another options is naming them by their purpose; for example, Sensor1_Core,
Sensor1_Perimeter, Sensor2_Perimeter, and so on.

Shared Secret Key

The shared secret key is required to establish a trust relationship between the Sensor and
the Manager. It is configured on the Sensor during its initial setup and then entered in the
Manager later.

Alert: After the Sensor is installed, to change its name you must uninstall and then re-
install with the new name. You will lose all previous configuration data during this process.
It is important to know that the sensor must be added in the UI first, before going
attempting to establish trust via command line through the sensor. This is because the
trust between the sensor and the manager is initiated by the sensor. This is a common
Support call.

You can add Sensors in the Manager using the Add and Remove Devices page or Add
Device Wizard option. Both options are accessed from the Global tab on the Devices page.
When you log in to a new Sensor that has not been previously configured, run the CLI
Setup Wizard. If not prompted automatically, execute the setup CLI command. You can run
the wizard from an administrative console (direct connect) or remotely using an application
such as HyperTerminal or PuTTY.
This section describes how to run the CLI Setup Wizard using a terminal emulator.

You’ll first log into the device, then start the CLI Setup wizard.

NOTE: If not prompted automatically to run the CLI setup wizard, execute the setup CLI
command.
Next, you’ll be prompted to enter a password and Sensor name. Make the name as
descriptive as possible; for example, based on location or purpose.
In the next step, you will enter in the IP type and address you want it to have.

Note that IPV4 and IPV6 are supported.

Next, enter in the subnet mask and the IP address of the Manager. You must enter the IP
address of the Primary Manager.
You can also define the Secondary Manager, if appropriate; otherwise, bypass this step.

In the next step, you’ll configure the Sensor default gateway.

In the last step, you’ll be prompted to enter in the shared secret key. Remember, the
shared secret key entered in the Manager must match the one you enter here exactly. This
is what establishes the trust relationship between the Sensor and the Manager.
Testing network communication between the Manager and the Sensor should take place
before starting with an installation.

For troubleshooting purposes, you can try to ping the Manager from the Sensor to
determine if the configuration settings to this point have successfully established the
Sensor on the network. At the Sensor’s command prompt, type: ping <manager IP
address>.

If the ping is successful, continue with the following steps. If not, use the show command to
verify the configuration information and check to ensure that all information is correct.

The customer also needs to verify that required ports are open. This includes routers or
other devices between the Sensor and the Manager needed for trust establishment and
actual communication between the two.

NOTE: UDP 8500 flows from Manager to sensor. All others are Sensor-to-Manager.
Let’s take a look at the process involved for establishing trust.

The Sensor initiates all communication with the Manager server until secure
communication is established between the two devices. Later, configuration information is
pushed from the Manager to the Sensor.

The Manager does not poll the network to discover the Sensor. This is why the Sensor’s
and Manager’s shared secret key must match.

NOTE: Periodically, the Sensor polls the Manager for date and time on this channel. This
channel is always active unless disconnected or uninstalled from CLI. If there is error in
communication, then the channel is closed, and the above steps are repeated.
The figure illustrates how the alert channel trust relationship is established.
1. The Sensor sends a TCP connection request to the Manager on port 8502. The Sensor
sends its name with the initial message.
2. The Manager acknowledges the message.
3. The Sensor sends a request to the Manager to obtain the SNMPv3 username and
secrets.
4. The Manager responds with details.
5. The Sensor sends an Exchange Complete acknowledgement to the Manager.

The Manager can now send SNMP commands to the Sensor over UDP port 8500. DES/AES
and MD5 /SHA are used as encryption/hashing algorithms for this channel. The Manager
can also receive alerts from the Sensor. The Manager acknowledges each alert.

The alert channel is always active unless disconnected or uninstalled from the CLI. If there
is an error in communication, the channel is closed, and the steps above are repeated.
If this is the first time an alert channel is established, the Packet Log channel is also
established.
The figure illustrates how the packet log channel trust relationship is established.
1. The Sensor sends a TCP connection request to the Manager on port 8503. The Sensor
sends its name with the initial message.
2. The Manager acknowledges the message.
3. The Sensor can now send packet logs to the Manager.
4. The Manager acknowledges each packet log.

The Manager initiates Signature and Image downloads on the SNMP command channel
(UDP port 8500 on the Sensor). The actual data transfer is initiated by the Sensor over TCP
port 8504 using a proprietary File Transfer protocol.

The SNMP channel is encrypted using the Data Encryption Standard (DES), FIPS PUB 46-2.
This standard is issued by the National Bureau of Standards
(www.itl.nist.gov/fipspubs/fip46-2.htm).

For more information, also refer to these articles in the McAfee Knowledge Center,
https://support.mcafee.com.

KB53064: Protocol sequence between the Sensor and Manager when creating a new
trust
KB55587: Encryption methods used for Sensor-to-Manager communication
On the Sensor CLI, the status command (shown here) and show command (displayed on
the following page) provide administrative information on the Sensors. The show
command provides configuration details, while the status command provides information
on Sensor communication, trust and general health. This information can be helpful when
troubleshooting. You get to see if there is trust established, and if the alert and log
channels are up and functioning properly.
The figure provides an example of the show command response. Very useful information
is displayed here for troubleshooting. Here we get to see what software version the Sensor
is running, what IP address it has for the Manager, the Sensor’s IP address, and much more.
The signature set is pushed to the Sensor during its initial setup. After the setup is
complete, a quick way to verify the signature set is current is using the Manager Dashboard
or Updating pages on the Manage tab.
• Dashboard:
 Manager Summary: Displays details, such as software version, and signature set
version.
• Devices page (Global tab - Deploy Device Software page): Displays current software
version and if a new version is available.
• Manage page (Updating folder): View important information regarding the update and
upgrade of the software and signature sets.
After the Sensor is added to the Manager, you can view and modify its configuration from
the Devices tab on the Devices page. The tasks are organized in the following folders,
which you expand to view and select options.
• Summary: Displays the current configuration for the selected Sensor. The information is
read-only.
• Policy: Used to modify assigned policies, rules, and exception for the selected Sensor.
• Setup: Used to manage basic parameters for the selected Sensor, such as configuration
of monitoring ports, time zone, name resolution and proxy server (if used), logging, an
alerting. It is also used for remote access, NTBA Integration, decryption, port clusters and
reserved VLAN settings.
• Maintenance: Used to upgrade (or downgrade) the Sensor software, import/export a
configuration from a file, shut down, and reboot the selected Sensor.
• Troubleshooting: Used to perform a generate and upload a diagnostics trace file to the
Manager for forwarding to McAfee support, and move a device in and out of Layer 2
bypass mode. It is also used to specify types of attack definitions to include in the IPS
policies used by this device, perform performance monitoring and packet capturing.
• Deploy Configuration Changes: Used to deploy configuration changes to the device.
• IPS Interface: Used to modify assigned policies, rules, and exception for the selected
interface pair.
Let’s start with the Summary page. The Summary page (Devices page > Devices tab),
provides read-only information for the selected device (Sensor).
For the selected device, verify the Name, IP address, subnet mask, and default gateway IP
address are the same as what was set through the CLI.
NOTE: Fields marked with an asterisk (*) indicate either an absence of data or that they
have been retrieved from the database because the device is inactive.
As the slide states, in version 8.2, many simplifications have been made to policy
management including the deprecation of exception objects, whose functionality has been
replaced by Ignore Rules. Customers can use this page to maintain exception objects for
pre-8.2 devices until they have been upgraded and can take advantage of the new Ignore
Rules. We’ll discuss and dive into IPS policies in more detail later in the course.
Use the Setup pages to manage the basic parameters for the Sensor, such as:
• Physical ports: Manage the physical ports on this device.
• Name Resolution: Enable name resolution, and configure DNS server details.
• Time Zone: Adjust the time zone for the entire device.
• Proxy Server: Configure a proxy server, if it is required for Internet connectivity.
• NTBA Integration: Collect and export Layer 7 data to an Network Threat Behavior
Analysis (NTBA) appliance and control which Layer 7 data is collected on this device
and potentially exported to the NTBA Appliance, if NTBA is deployed.
• ATD Integration: It deployed, the ATD integration can provide an IOC report for system
administrators to find out and remediate infected endpoints.
• Application Identification: Enable application identification on monitored traffic.
• Quarantine: Configure settings for each inline Sensor monitoring port.
• Logging: Configure firewall access logging.
• Remote Access: Configure Terminal Access Controller Access-Control System Plus
(TACACS+) to leverage a central user database for Sensor CLI authentication.
• Decryption: Enable SSL decryption, as well as import and manage certificates.
• Advanced: Configure essential processing of traffic, and configure port clusters to
enable multiple Sensor ports to be grouped together for the effective monitoring of
asymmetric environments, and much more.
The Physical Ports page is used to manage the physical ports (Monitoring, Response, and
Management) for the selected Sensor. Changes made on this page take will take effect
immediately.
Many features now require name resolution to function properly. The requirement
depends on the device and feature; for example, Sensors use DNS to resolve host names in
firewall access rules, NTBA Appliances use it to resolve host names for reporting purposes,
and both use it to perform GTI lookups.

Use this page to define DNS settings. The DNS Suffixes field can take a space-separated list
of domains, which will be attempted in the order provided. Fields marked with an asterisk
(*) are required.

Guidelines
You can configure the DNS server details at an domain level or at a device level. The DNS
server at the admin domain, by default, applies to:
• All the corresponding child domains.
• All the Sensors in this domain. This includes any interfaces delegated to other
domains.
• All the Sensors in the corresponding child domains.
• If required, you can override the DNS server details at a child admin domain level and
also at each Sensor level.

Continued on the next page.

GTI File Reputation
Name resolution must be enabled on devices that will be using the GTI File Reputation
malware engine. This is discussed in more detail later in the course, along with Global
Threat Intelligence integration.

DNS Flood attack

Sending a flood of DNS requests to a Server constitutes a DNS Flood attack. Since DNS
uses UDP, no hand-shake process is involved. A flood of DNS requests can tie down the
resources of a DNS infrastructure and create a DoS condition. DNS servers like other
Internet resources are prone to DoS attacks. DNS uses UDP queries for name resolution
and so a full circuit is never established (as contrasted with TCP) DoS attacks are difficult
to trace and block.

DNS flood works by sending a flood of rapid DNS requests from multiple machines,
thereby giving the server more traffic than it can handle resulting in slower response time
for legitimate requests.

Syslog Forwarding
If you choose the Sensor to forward the logs to a syslog, then the Sensor uses the DNS
servers that you configured in the Name Resolution page for the Sensor. Make sure the
Sensor management port is able to reach the DNS servers by pinging them from the
Sensor CLI.
The Maintenance pages options include:
• Deploy Device Software: Upgrade or downgrade the software running on the selected
device.
• Import Configuration: Import a new configuration for this device from a file. This
enables you to overwrite the current configuration on a saved (exported) Sensor or
NTBA Appliance configuration file.
• Export Configuration: Export the configuration for this device to a file. This enables
you to save the configuration of a Sensor (including NTBA Appliance configuration
settings of the Sensor) into a single file for later application to the same Sensor or
another Sensor of the same model. This helps to avoid duplication of work when it
comes to configuring Sensors. This feature is also useful if you plan on restoring the
configuration back on the same Sensor or its replacement.
• Shut down: Turn off a device with no restart.
• Reboot: Rebooting a device shuts all of its processes down and then restarts them. You
can reboot a device from the Manager or from the device's CLI. By default, when you
reboot a device, it restarts the entire system.
The Upgrade action, on the Deploy Device Software page, enables an on-demand
download of the latest or earlier software updates for a Sensor or NTBA Appliance from the
Manager. All the software versions, that are applicable to the device and are available in the
Manager are listed. From this, you can choose the version that you want to push to the
device. These versions are the ones that you downloaded from the update server onto the
Manager.
The Troubleshooting pages options include:
• Diagnostics Trace: Generate and upload a Diagnostics Trace file to the Manager and to
export a Trace file from the Manager. A Diagnostics Trace file is an encrypted archive
containing essential device debugging information and logs. Uploaded files are stored
on the Manager file system in the following location: < Install Dir > \ temp \ tftpin \ <
Sensor Name > \ trace \
• Layer 2 Bypass: Enable this device to bypass the scanning process if critical faults
occur and to enable ARP spoofing.
• Attack Compilation: Specify the types of attack definitions that should be included in
the IPS policies used by this device. The most common reasons to use this option are
to isolate performance issues that may be caused by a specific attack type and to
optimize an IPS Sensor by ensuring that it only uses specific attack types.
• Performance Monitoring: Monitor the load on the devices configured in the Manager,
using collected metrics and thresholds.
• Denial of Service: Use this page to manage DoS Profile learning, view status and
filtering options.
• Packet Capturing: Configure packet capture, open, and export packet capture files
(PCAPs) stored on the Manager.
On the Deploy Pending Changes page, you can configuration and policy changes to the
device.

When you make any configuration changes, or policy changes on the Manager, or a
new/updated signature set is available from McAfee, you must apply these updates to the
devices (such as Sensors and NTBA Appliances) in the environment, for the changes to take
effect.

NOTE: In order to Deploy Pending Changes, you can only update online devices. Make sure
it is discovered, initialized, and connected to the Manager.

NOTE: Callback Detectors is the new name for Botnet Detectors in previous releases.
The IPS Interfaces page is used to manage interface properties; for example, view/change
policy assignments, DoS profile, and sub-interfaces. Note that before you can create a sub-
interface you must change the interface type to CIDR or VLAN, and define CIDR blocks or
VLAN IDs, respectively.