Knowledge Base

Getting Started

Configuring NP-View Server

Getting Started

Once NP-View Server is installed, the application will start automatically. Note that NP-Live has been Rebranded to NP-View Server.  Several of the instructions still correctly refer to NP-Live as we migrate the installation services to the new product names.

If the Linux Administrator wishes to start and stop the application, two helper scripts have been included to aid in these tasks:

  • Stop : sudo /opt/np-live/stop_NP-Live.sh
  • Start : sudo /opt/np-live/start_NP-Live.sh

NP-View Docker IP Conflict

+
If NP-View Docker is using IP addresses that conflict with addresses used on the local area network, the IP addresses used by Docker can be changed as follows:

Create a docker network with the subnet you would like to use:
sudo docker network create --driver overlay --subnet x.x.x.x/x NP-Live_external

Navigate to the np-live install directory (default /opt/np-live):
cd /opt/np-live

Add the following config to local-settings.yml (tab indented to reflect table below):
networks:    
  NP-Live_external:  
    external: true

Replace all instances of the default network in docker-compose.yml to NP-Live_external:
sudo sed -i 's/- default$/- NP-Live_external/g' docker-compose.yml

Stop and start the app:
sudo sh ./stop_NP-live.sh && sudo sh ./start_NP-live.sh

#Note: docker commands (and the start/stop NP-live scripts) will require sudo unless you are the root user or your user is part of the docker group

Version mismatched between two compose files : 3.4 and 3.1

+
When starting NP-View Server, if this error is received, the version number in /opt/np-live/local-settings.yml needs to be at “version: ‘3.4’”. If not at version 3.4, please replace the contents of the local-settings.yml file with the code listed in the Setting the NP-Live Virtual Appliance Time Zone section and set your application time zone accordingly. This file is sticky and will remain after future upgrades. After the update, start the server using the above command.

Upon initial start, the Welcome screen shows the configuration wizard to guide the Administrator through the remaining configuration steps which include:

  1. Authentication
  2. Licensing
  3. Users

Configure Authentication

The following authentication options are available to configure in NP-View Server.

  • Active Directory / LDAP
  • Radius
  • Local

Active Directory or LDAP

For Active Directory or LDAP authentication we use LDAPv3 TLS over port 389.  If the communication returns an exception, we attempt unencrypted communication. We do not support LDAPS.  Before starting, note that setup requires a dedicated Credential Binding Account (LDAP Administrator). The Credentials Binding Account must be included in at least one of the system groups for NP-View Server to query and link the users.

An example of a properly configured LDAP screen on NP-View is below:

The setup page will allow for the definition of three system groups using a Distinguished Name.  A Distinguished Name (often referred to as a DN or FDN) is a string that uniquely identifies an entry in the Directory Information Tree. The format of a DN is: CN=groupname,OU=grouptype,DC=subdomain,DC=example,DC=com.  Your domain needs to match the DC specified in your DN. For an example DN like above, the domain would be: ‘subdomain.example.com’.

For example:

ldap_group_admin = 'CN=NP-Live Admin, OU=Permissions, DC=ad, DC=np, DC=test'
ldap_group_write = 'CN=NP-Live WorkspaceAdmin, OU=Permissions, DC=ad, DC=np, DC=test'
ldap_group_read = 'CN=NP-Live Viewer, OU=Permissions, DC=ad, DC=np, DC=test'

group_translation = {'Administrator' : ldap_group_admin,
'WorkspaceAdmin' : ldap_group_write,
'Viewer' : ldap_group_read}

Reminder:   The three CN names must be unique or roles will be overlapped in NP-View resulting in features being disabled.

To find the DN on Windows, open a Windows command prompt on your Active Directory server and type the command: dsquery group -name "known group name".

Users assigned to NP-View must login once to get setup within the NP-View database for sharing and transferring of workspaces.  No users exist until after the first login.

Troubleshooting Active Directory Setup

If an error is returned when configuring Active Directory, the steps to troubleshoot are:

Step 1: From your Active Directory server, type the command below in a terminal after replacing the “CN=…” portion with the Distinguished Name of the group you’d like to check:

dsget group "CN=groupname,OU=grouptype,DC=subdomain,DC=example,DC=com" -members

Verify that the output shows the expected list of user(s) in that group. If it doesn’t, check your Active Directory group and user configuration.

Step 2: From your Active Directory server, type the command below in a terminal after replacing the “CN=…” portion with the Distinguished Name of the group you’d like to check, and also replacing USERNAME with your actual username:

dsquery * -Filter "(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=groupname,OU=grouptype,DC=subdomain,DC=example,DC=com)(sAMAccountName=USERNAME))"

If the output is empty, verify that your user in Active Directory has the attribute sAMAccountName set. If not, set it and try the command again. Verify also that the sAMAccountName value matches your AD username value. You can also try to enter the username in the NP-View Active Directory configuration form with the format USERNAME@DOMAIN.

If the output shows the expected list of groups for that user, but NP-View still generates an error, then contact the NP support team.

Radius

Radius authentication requires your server address and secret. Once input, the user can test their connection using their personal login credentials for verification.  Note that for Radius authentication, all users are assigned to the Administrator group.

Welcome: How would you like to authenticate users

Local Authentication

NP-View Server provides an internal mechanism for the administration of users.  During setup, the screen will require the user to setup the Administration account by inputting a user ID and password.  This account will be assigned to the Administrator role and will have access to all system features. An example of a properly configured Local Auth screen on NP-View is below:

User Management

NP-View Server provides a User Management function for users assigned to the the Administrator role. It can be accessed in the user menu at the top right of the screen either on the workspace page or from within a workspace.

User Management – Active Directory or LDAP

Clicking User Management will open a window that shows the LDAP setup information. The left half of the screen allows the user to change the NP-View LDAP settings.  LDAP Auth credentials are required to update the information.  The optional email field override is used as the default email address for the Notification Manager if no email address is provided as part of the LDAP credentials.

The right half of the user management screen allows for the testing of each LDAP user and will retrieve their LDAP settings for review.

User Management – Local Authentication

Clicking User Management will open a window that shows the user related information associated with this account, their account details, and their account permissions.

From this window Administrators can edit (pencil icon), delete (x icon) or add user accounts (create new user button).

A user’s ID should be the user’s email address (this will be used for notifications) and an administrator-defined password.  Each user will need to be assigned to a role which will provide the user with system wide access.

  1. Administrator – Has access to all users, workspace and system administration functions including managing users and license functions.
  2. WorkspaceAdmin – Has access to all workspace administration functions.
  3. Viewer – Has read only access to the system.

Reset Authentication

The Administrator can also reset the authentication method entirely by selecting the “Reset authentication system” link. “Reset authentication” only resets the authentication and does not remove any workspaces or data.  Note that workspaces are assigned to user id’s.  If the authentication method (or user id format) is changed, the workspaces will no longer be available to users.  The administrator or workspace admin must utilize the transfer workspace function to assign the legacy workspace to the new user id’s.

Password Reset

  • Workspace Admin or Viewer user groups:  Contact your Administrator who can manually reset your password through the User Management function on the system menu (upper right corner).
  • Admins: connect through SSH to the NP-View server and remove the file db/auth_provider.cfg inside the NP-View application folder (by default: /opt/np-live).
  • Refresh the NP-View web page to show the Welcome screen and reconfigure the authentication.

License and Terms

The Administrator can Show, Upgrade or Renew their license. Licensing terms and legal disclosures are available from the system menu where user management is found.

Configure License Key

After the authentication, the Welcome screen will guide the Administrator through reviewing the EULA and adding the license key. The license key should have been sent to you by email and also posted on the Network Perception portal. If you haven’t received a key, please send a request to support@network-perception.com. Renewed or upgraded license keys can only be installed from the home screen (not from within a workspace) by members of the Administrator group.

Additional Configuration Features

Configure Automatic Updates

NP-View Server can automatically download new releases and update itself if you select “Automatically check for updates”.  Alternatively, you can select “Update NP-View” from the upper right menu or update offline using the following steps:

  1. Download the latest release from the Network Perception portal.
  2. Copy the release file to the NP-View Server using SCP or WinSCP
  3. Connect to the NP-View Server shell using SSH and execute the release file with the command sudo sh NP-View_server_installer.sh

Configure Shutdown and Startup Options

To speed performance on startup, NP-View terminates background processes that are running when the system is gracefully shutdown and clears out all tasks and jobs.  If any processes remain upon startup, they are also terminated. To change the configuration,

  • stop the NP-View Server application.
  • in the docker-compose.yml file for the manager change cancelTasksStartup=True to cancelTasksStartup=False
  • in the docker-compose.yml file for the manager change clearRqStartup=True to clearRqStartup=False Note that the previous setting must also be set to True for this operation to work.
  • start the NP-View Server application.

Configure User Timeout

The system can be configured automatically time out a user after a period of idle days.  The default is set to 30 days. To change the configuration,

  • stop the NP-View Server application.
  • in the docker-compose.yml file for the webserver\environment service, change sessionLengthDays=30 to any positive floating point number representing elapsed days. For Example:
    • 0.5 = 12 hrs
    • 1.5 = 36 hours
    • 30 = 720 hrs.
    • If set to 0, user timeout will default to 30 minutes.
  • start the NP-View Server application.

Timeout for connectors is 1 day and cannot be changed. Also, the timeout value is not static and will be overwritten by the next software update. Prior to restarting after an update, the timeout needs to be reset to the value of choice.

Configure Devices within a Custom View

The system can be configured to allow for more devices within a custom view.  The default is set to 25 devices. To change the configuration:

  • stop the NP-View Server application.
  • in the docker-compose.yml file for the
    • services : manager : environment, change devCountLimit=25 to a positive integer.
    • services : bgmanager : environment, change devCountLimit=25 to a positive integer.
    • services : webserver : environment, change devCountLimit=25 to a positive integer.
  • start the NP-View Server application.

Note: The limit is not static and will be overwritten by the next software update. Prior to restarting after an update, the limit needs to be reset to the value of choice. Note: NP has only tested the system to the default limit. Raising the limit is at the user’s risk as unintended consequences including data loss and the system exhausting system resources may occur.

Configure A Static IP Address on your Linux Server

To set a static IP address for your NP-View Server, follow the instructions in this document.

Updating NP-View Server

This section describes how to update the NP-View Server application and the underlying components if the OVF was used for the initial installation.

Updating the NP-View Server Application

To update an existing NP-View Application, the steps are:

  1. Download the latest release Linux Installer Release (not the .OVF) from the Dragos Portal and copy it onto your NP-view server using SCP (or WinSCP from a Windows client)
  2. Login onto the NP-View server using SSH (or Putty from a Windows client)
  3. Get root permissions using the command: sudo -i
  4. Prior to installing the new version, it is recommended to make a backup of your database (see below)
  5. Execute the new NP-View release file using the command: sh NP-View_installer.sh  (where NP-View_installer.sh is the name of the new release file downloaded in step 1).
  6. Follow the guided steps of the installer, which will automatically start NP-View once the update is complete.
  7. Connect to the user interface of NP-View using your web browser and check in the bottom-left corner of the home page that the version number matches the new release

Updating the NP-View Application to version 5 and above

Prerequisites

  • Please update your current version of NP-View to version 4.3.5. Both Server and Desktop must be on this version before starting your upgrade.

For NP-View Server:

  • Verify there is sufficient disk space for the upgrade (3x size of Redis db).
  • If not follow log cleanup procedure listed in KB (~250MB possible).
  • If still insufficient space, disk space will need to be added before upgrade.
  • Verify all users are logged out of the system to not lose data during update.

Back-Up NP-View database

NP-View Desktop

  1. Copy the 4.3.5 database folder to a safe location. This will allow you to keep a back up 4.3.5 in the case you would want to revert back to 4.3.5some text
    • C:\Users\<name>\AppData\Roaming\NP-View\db
  2. Download NP-View from the portal and install.
  3. Starting the application may take longer than usual as a one-time database maintenance operation is being performed.

NP-View Server

Option 1:

  1. SSH as the root user to Terminal of NP-View server
    • ssh root@<ip-of-guest-os>
    • If needed sudo -i or sudo su will give you admin privileges once you are logged in.
  2. Move to the NP-View (np-live) app directory
    • cd /opt/np-live
  3. Stop NP-View
    • sh ./stop_NP-Live.sh
  4. The db directory contains all of the NP-View data. Create a tarball of the directory
    • tar -czf np-view-v4.3.5-db-backup.tar.gz db
  5. Move the file to a safe location.
    • Note: This file will allow you to revert back to 4.3.5.

Option 2 (This option is only available if your server is a VM):

  • Your server admin can take a snapshot image of the server as a restore instance. This tends to be easier and quicker for most of the customers that we have worked with.

Once you have a back up and have updated to 4.3.5, please download version 5+ and follow the instructions listed in the above section "Updating the NP-View Server Application".

NP-View Server Migration

Prerequisites

  • Follow the instructions above to update the NP-View CentOS server to the latest NP-View version.
  • Create a VM using the latest version of the NP-View Server OVF.
  • Both Servers need to be running to perform the migration.
  • Users should be logged out of NP-View and close any active session before restoring.

CentOS Migration to Ubuntu for NP-View Server

  1. Use backup and restore script.
    • sudo -i (This should take you to the root folder)
      • Enter credentials if prompted.
    • To run shell script: /opt/NP-Live/NP-View_backupand_restore.sh
      • There will be 3 options when using the script.
        • Backup
        • Restore
        • Exit
    • The script will check disk space when creating the backup.
    • The script will notify you if the storage is full and stop running.
  2. Move the CentOS tar file to the Ubuntu server’s root directory.
    • sudo -i (This should take you to the root folder)
    • Enter credentials if prompted.
    • To run shell script: /opt/NP-Live/NP-View_backupand_restore.sh
      • Select restore
      • The script gives a final warning before running.
      • The script checks if the docker containers are running.
  3. Once the script is completed it will notify you.
    • Connect to the web interface and verify data is transferred.
    • If you are unable to connect to the web interface restart NP-View service once the upgrade is complete.

Get Version API call

To check the version update your server URL to the following

https://<np-view_server_address>/version

Backing up the NP-View Server Database Manually

  1. Stop the NP-View Server (you can use the script /opt/np-live/stop_nplive.sh)
  2. From the NP-View Server folder (by default: /opt/np-live/, run the command: tar -zcf db_backup_$(date '+%Y_%m_%d').tgz db (this command may take few minutes to complete)
  3. Run the new release installer, which will update the containers and then launch NP-View Server

Updating Linux Ubuntu and Docker

(Version 5 and up installation with the OVF)

We will be providing update packages for Ubuntu and Docker. Please go to the following page for more information:

https://www.network-perception.com/kb/ubuntu-and-docker-update-packages

Updating Linux CentOS Ubuntu and Docker

CentOS is now EOL as of June 30, 2024. We highly recommend customers to transition to Ubuntu.

If the OVF was used for the initial installation, that package included the CentOS 7 operating system and Docker. These applications must be updated separately from the NP-View Server Application using the below instructions. The instructions cover NP-View Servers that have internet access and those that do not have internet access.

Updating when the NP-View server has internet access:

– stop NP-View
cd /opt/np-live/
./stop_NP-Live.sh

– run all updates
yum update -y

– reboot server
reboot

Updating when the NP-View server does not have internet access:

If NP-View server is installed in an environment that does not have internet access, a separate Centos 7 server with Docker that has internet access is required to create the update package. All commands below are case sensitive.

Network-Perception uses this mirror for CentOS updates and this mirror for Docker updates

Centos 7 that is online:

– make sure you are root
sudo su -

– create packages directory
cd /root/
mkdir packages
cd packages

– download all packages
yum list installed | awk {'print $1; }' | tail -n +3 | xargs yumdownloader

– you should see docker included in the output list.

– compress archive (capital -C is important)
tar czf /root/packages.tar.gz *.rpm -C /root/packages/

– Copy packages.tar.gz to the offline server. The user can use the below command to scp:
scp packages.tar.gz root@ipAddress:/root/

Centos 7 that is offline running NP-View:

– make sure you are root
sudo su -
– stop NP-View
cd /opt/np-live/
./stop_NP-Live.sh

– create directory and extract the archive
cd /root/
mkdir packages/
mv packages.tar.gz packages/
cd packages/
tar -xf packages.tar.gz

– install all updates:
yum -y localinstall *.rpm

– reboot server
reboot

– now everything is up to date on the offline server.

If you get any docker swarm errors:

– make sure you are root
sudo su -

– leave and join swarm cluster
docker swarm leave --force && docker swarm init

Product Tutorials

1. Network Mapping

Network mapping provides the Networking Team (Network Engineer, Network Security) with capabilities that allow users to:

  • Visualize an accurate topology of the network architecture
  • Identify and label critical cyber assets and critical network zones
  • Easily review which devices are protecting which network zones

Visualize Topology

NP-View can be used to discover your network topology and the underlying control plane, including layer-2 and layer-3 configurations. Without leaving the topology map, you can review many aspects of the network’s design including Firewalls, Routers, Switches, Gateways, Networks, VPNs, Hosts and more.

Critical Assets and Zones

Each asset can be tagged with categories and criticalities as well as grouped into zones making it easy to review which devices are protecting which network zones.

Details On-demand

Selecting a node in the topology map will interactively display an information panel with detailed data about that node.

2. Firewall Ruleset Review

Firewall ruleset review provides Network Engineers, Network Security, and Compliance Analysts with functionality for:

  • Easy review of firewall access rules and object groups using the Access Rules and Object Groups reports.
  • Automatic identification of configuration risks using the Risks and Warnings report.
  • Validating recent policy modifications as part of a configuration change review process using the Change Tracking report.

How to Review Access Rules

An independent review of firewall policies has to be periodically conducted to ensure that network access rules are correctly implemented and documented. It is important because lack of access rule review leads to unexpected network access vulnerabilities.

  • Frequency: each time firewall policies are changed, and at least once a quarter
  • How to do it:
    • Step 1: given a workspace populated with network device configurations, open the Access Rule table from the main menu (top left)
    • Step 2: leverage the “Column Search” feature or the “Compare” feature to show the rules in scope of your verification
      • For instance, filter the “Device” column to only show rules for a specific device, or filter the “Binding (ACL)” column to only show rules bound to a specific interface, or use the “Compare” feature to only show rules added or removed recently
    • Step 3: review values for the source, destination, service, binding, risk, and description of each rule in scope
      • The “Description” column captures comment, description, or justification from the device configuration
      • The “Risk” and “Risk Criticality” columns are populated by NP-View during the automated risk analysis
    • Step 4: to identify rules that are not justified, sort the table by “Description”. Empty values will be shown at the bottom.
    • Step 5: to document your review process, double click on the “Comment” or “Comment Status” cells to add your own comment. The comment status can be either “Verified” or “To Review” or “To Revise”
    • Step 6: to save an evidence of your review process, export the table to Excel using the export options in the top right corner of the table

Access Rules Table

The Access Rules report provides the users with complete details on each Access Rule with the ability to add justifications and actions.

Object Groups

The Object Groups report provides the users with complete details on each Object Group with the ability to add justifications and actions.

Risks and Warnings

As modifications are made to the network, the Network Perception default Policies and Requirements identify potential risks.  The Risks and Warnings report provides the users with a summary of the potential risks and their criticality with the ability to add actions and comments.

Change Tracking

As modifications are made to the network and the updated configuration files are imported, the changes are logged in the Change Tracking table.

tracking table
3. Segmentation Verification

Segmentation verification provides the Networking Team and Audit Team with capabilities that allows users to:

  • Assess correctness of network segmentation
  • Identify risky network connectivity paths
  • Understand exposure of vulnerable assets

Network Segmentation Accuracy

NP-View be used to verify the accuracy of your network segmentation.

The connectivity matrix which is available from the device info panel can be used to verify open ports between devices.

Inbound and outbound connections can be verified for each network using the highlight paths function.

Identifying Risky Connectivity Paths

Using industry best practices, Network Perception automatically identifies potential risks related to network configurations. Using the Network Perception  Connectivity Path analysis, the user can review each of the highlighted risks and make a judgment on action.

organization table

Exposure of Vulnerable Assets – Vulnerability Analytics

NP-View provides your security team with a single pane of glass for reviewing network vulnerability exposure. With the addition of scanner data or data from a vulnerability data service, vulnerabilities can be tracked across your network.

Topology Display of Vulnerabilities

When scanned data has been added to a workspace, and a topology view is built that also includes that scan data, nodes on the topology of that view will be marked with a shield indicating the presence of vulnerabilities.

These shields can be toggled on and off using the topology settings menu.

Device Panel Display of Vulnerabilities

Firewalls, Gateways, and Hosts may contain vulnerability and service information imported from scans. Clicking on any of these nodes in a View that contains vulnerability information, will display it in the info panel that opens over the main menu.

Clicking on the Vulnerabilities link will present a pop out with the vulnerability details.

4. Audit Assistance

Performing a regular review of your compliance metrics is important for your organization.  Performing the review manually is time consuming and tedious. Audit assistance provides the Compliance Team (Auditor, Compliance Officer, Compliance Analyst, and Consultants) with capabilities that allow users to:

  • Verify compliance with cybersecurity regulations and best practices through Policy Review.
  • Seamlessly store evidence for compliance review with Change Tracking.
  • Easily prepare compliance reports using the Audit Assistants listed below:

Workspace Report (Standard)

The Workspace Report assistant is available within each workspace and will generate a report for a specific view that includes detailed information about configuration files that were imported and parsed including:

  • Configuration assessment report including risk alerts
  • Ports and Interfaces
  • Access rules
  • Object groups
  • Path analysis

Industry Best Practice (Premium)

The Best Practice assistant requires a license to activate. This report is available within each workspace to generate a report for a specific view that includes the following topics:

  • Parser Warnings and potential misconfigurations
  • Unused Object Groups
  • Access Rules missing a justification
  • Unnamed nodes
  • NP Best Practice Policies on access rules and CiS Benchmarks that have identified potential risks
  • ACL’s with no explicit deny by default rule

NERC CIP Compliance (Premium)

The NERC CIP assistant requires a license to activate this function and guides the user through the steps required to create a report covering CIP-005 requirements. The NERC CIP audit assistant is only available within a NERC-CIP workspace and allows audit teams to classify BES cyber assets as High, Medium, and Low based on the standards. We have added a category for untrusted (Internet, Corp, etc.) to tag non BES assets. NP-View allows compliance teams to collect and report evidence related to the following requirements:

  • CIP-002 – BES Cyber System Categorization; impact rating and 15-month review
  • CIP-003 – Security Management Control; cyber security policy
  • CIP-005 – Electronic Security Perimeter; remote access management
  • CIP-007 – System Security Management; ports and services
  • CIP-010 – Change Management and Vulnerability; configuration change management, configuration monitoring, vulnerability assessment

A demo workspace for the NERC CIP audit assistant is included with the software.  To see the audit assistant in action, follow these steps:

  1. Click on the demo workspace to build the topology.
  2. Create a custom view by selecting all of the firewalls, right click, Create View from Selection and give it a name.
  3. Once the view is generated, select Manage Zones from the left manu and click on the Auto Generate Zones button.
    • Red zones represent your high criticality assets.
    • Orange zones represent your medium criticality assets.
    • Yellow zones represent your low criticality assets.
    • Gray zones represent your untrusted assets.
  4. On the left menu, select Summary Reports and the NERC-CIP Compliance Report
  5. Click through the wizard, the defaults will represent the selections suggested by the auto group function.
  6. Click Generate Report to view the report in a new tab.

Feature Documentation

Policy Manager

Overview

The policy manager is used to execute predefined policies and requirements that trigger risk messages or format designated table reports, based on string matching logic. Default Policies and individual Requirements can be “Enabled or Disabled” by clicking the toggle button.  Policies and Requirements are global in nature and changes made when in one workspace will apply to all workspaces.  For example, if a Policy, Requirement, or Device is deactivated in one workspace, that update will apply to all workspaces. Risk Policies are run when new data is imported into NP-View.  Table Highlight Policies are run when a modal report is opened.

Key Concepts

Using the policy manager requires the understanding of a few concepts:

Requirement A requirement contains Regex logic to trigger a message or formatting action for one use case.

Policy A policy is a collection of related requirements and does not have any logic associated with it, it is a means for categorization. Policies can be enabled or disabled.

Risks and Warnings Requirements Trigger alert messages based on Regex logic. Individual policies can be enabled or disabled and assigned to one or more devices.

Table Highlighting Requirements  Formats the color of cells and text based on Regex logic.  Highlighting is report specific.

Default Risks & Warnings Policies

Risk and Warnings messages, which can be found in the Risks & Warnings and Access Rules table reports, are generated using Policies and Requirements located in the Policy Manager.  Default Policies and Requirements are automatically assigned to all devices when they are first imported, and run when network device configuration changes are identified.

The following default Risk alert Policies policies are provided for all Compliance modules:

  • Default Parser Risk Policy – triggers from logs generated during parsing of device configuration files
  • Default Access Rule Risk Policy – triggers from access rules

Default Policies and Requirements

+
Policy Requirement Risk Severity
Default Parser Risk Policy Unnecessary EIGRP Network Low
Broadcast traffic permission Low
Traffic to multicast group Low
Empty Field Low
Unused ACL’s Low
Unused group Low
Mixed any and not any Low
Unassigned interface Low
Missing interfaces Low
Rule following schedule Low
Default Access Rule Risk Policy Any in all fields High
Any in source Medium
Any source binding Medium
Any source IP Medium
Any destination Medium
Any destination binding Medium
Any in destination IP Medium
Any TCP Service Medium
Any UDP Service Medium
Any Service Open Medium

Default CiS Benchmark Risk Policies

CiS Benchmarks are provided as part of the Best Practices Module. CiS Benchmarks provide a powerful set of secondary policies to help identify risks within your network.  CiS Benchmarks are disabled by default and must manually be enabled and assigned to devices. As noted, changes to Risk related Policies, Requirements or Devices apply to all workspaces. CiS Benchmark Policies and Requirements can be deactivated but not edited or deleted.

  • CiS Benchmark for Check Point
  • CiS Benchmark for Cisco
  • CiS Benchmark for Juniper
  • CiS Benchmark for Palo Alto

CiS Benchmark for Check Point Firewall

+

The below requirements were derived from the CiS Check Point Firewall Benchmark v1.1.0 – 06-29-2020.

Requirement Risk Severity
Ensure ‘Login Banner’ is set Low
Ensure CLI session timeout is set to less than or equal to 10 minutes Low
Ensure Check for Password Reuse is selected and History Length is set to 12 or more Low
Ensure DHCP is disabled Low
Ensure DNS server is configured Low
Ensure Deny access after failed login attempts is selected Low
Ensure Deny access to unused accounts is selected Low
Ensure Disk Space Alert is set Low
Ensure force users to change password at first login after password was changed from Users page is selected Low
Ensure Host Name is set Low
Ensure IPv6 is disabled if not used Low
Ensure Maximum number of failed attempts allowed is set to 5 or fewer Low
Ensure Minimum Password Length is set to 14 or higher Low
Ensure NTP is enabled and IP address is set for Primary and Secondary NTP server Low
Ensure Password Complexity is set to 3 Low
Ensure Password Expiration is set to 90 days or less Low
Ensure Telnet is disabled Low
Ensure Warn users before password expiration is set to 7 days or less Low
Ensure Web session timeout is set to less than or equal to 10 minutes Low
Ensure Radius or TACACS+ server is configured Low
Logging should be enabled for all Firewall Rules Low

CiS Benchmark for Cisco ASA 8.x, 9.x Firewall

+

The below requirements were derived from the CiS Cisco Firewall Benchmark v4.1.0 – 01-16-2018. Supporting ASA 8.x and 9.x.

Requirement Risk Severity
Ensure ‘Domain Name’ is set Low
Ensure ‘Failover’ is enabled Low
Ensure ‘HTTP session timeout’ is less than or equal to ‘5’ minutes Low
Ensure ‘Host Name’ is set Low
Ensure ‘LOGIN banner’ is set Low
Ensure ‘MOTD banner’ is set Low
Ensure ‘NTP authentication key’ is configured correctly Low
Ensure ‘Password Policy’ is enabled Low
Ensure ‘Password Recovery’ is disabled Low
Ensure ‘SNMP community string’ is not the default string Low
Ensure ‘SSH session timeout’ is less than or equal to ‘5’ minutes Low
Ensure ‘TACACS+RADIUS’ is configured correctly Low
Ensure ‘console session timeout’ is less than or equal to ‘5’ minutes Low
Ensure ‘local username and password’ is set Low
Ensure ‘logging with timestamps’ is enabled Low
Ensure ‘logging’ is enabled Low
Ensure ActiveX filtering is enabled Low
Ensure DHCP services are disabled for untrusted interfaces Low
Ensure DOS protection is enabled for untrusted interfaces Low
Ensure Master Key Passphrase is set Low
Ensure email logging is configured for critical to emergency Low
Ensure explicit deny in access lists is configured correctly Low
Ensure ‘trusted NTP server’ exists Low
Ensure Enable Password is set Low
Ensure Java applet filtering is enabled Low
Ensure Logon Password is set Low
Ensure known default accounts do not exist Low

CiS Benchmark for Juniper JunOS 15.1 Firewall

+

The below requirements were derived from the CiS Cisco Juniper Benchmark v2.1.0 – 11-23-2020. Supporting JunOS v15.1.

Requirement Risk Severity
Forbid Dial in Access Low
Ensure VRRP authentication-key is set Low
Ensure proxy-arp is disabled Low
Ensure EBGP peers are set to use GTSM Low
Ensure authentication check is not suppressed Low
Ensure loose authentication check is not configured Low
Ensure RIP authentication is set to MD5 Low
Ensure BFD Authentication is Set Low
Ensure BFD Authentication is Not Set to Loose-Check Low
Ensure SNMPv1/2 are set to Read Only Low
Ensure “Default Restrict” is set in all client lists Low
Ensure AES128 is set for all SNMPv3 users Low
Ensure SHA1 is set for SNMPv3 authentication Low
Ensure Accounting of Logins Low
Ensure Accounting of Configuration Changes Low
Ensure Archive on Commit Low
Ensure NO Plain Text Archive Sites are configured Low
Ensure external AAA is used Low
Ensure TCP SYN/FIN is Set to Drop Low
Ensure TCP RST is Set to Disabled Low
Ensure Minimum Session Time of at least 20 seconds Low
Ensure Lockout-period is set to at least 30 minutes Low
Ensure login message is set Low
Ensure local passwords require multiple character sets Low
Ensure at least 4 set changes in local passwords Low
Ensure local passwords are at least 10 characters Low
Ensure External NTP Servers are set Low
Ensure Strong Ciphers are set for SSH Low
Ensure Web-Management is not Set to HTTP Low
Ensure Web-Management is Set to use HTTPS Low
Ensure Web-Management is Set to use PKI Certificate for HTTPS Low
Ensure Session Limited is Set for Web-Management Low
Ensure Telnet is Not Set Low
Ensure Reverse Telnet is Not Set Low
Ensure Finger Service is Not Set Low
Ensure Log-out-on-disconnect is Set for Console Low
Ensure Autoinstallation is Set to Disabled Low
Ensure Hostname is Not Set to Device Make or Model Low
Ensure Password is Set for PIC-Console-Authentication Low

CiS Benchmark for Palo Alto 9

+

The below requirements were derived from the CiS Palo Alto Firewall 9 Benchmark v1.0.0 – 03-23-2020.

Requirement Risk Severity
Ensure ‘Idle timeout’ is less than or equal to 10 minutes for device management’ is set Low
Ensure ‘Login Banner’ is set Low
Ensure ‘Minimum Length’ is greater than or equal to 12 Low
Ensure ‘Minimum Lowercase Letters’ is greater than or equal to 1 Low
Ensure ‘Minimum Numeric Letters’ is greater than or equal to 1 Low
Ensure ‘Minimum Password Complexity’ is enabled Low
Ensure ‘Minimum Special Characters’ is greater than or equal to 1 Low
Ensure ‘Minimum Uppercase Letters’ is greater than or equal to 1 Low
Ensure ‘New Password Differs By Characters’ is greater than or equal to 3 Low
Ensure ‘Permitted IP Addresses’ is set for all management profiles where SSH, HTTPS, or SNMP is enabled Low
Ensure ‘Permitted IP Addresses’ is set to those necessary for device management Low
Ensure ‘Prevent Password Reuse Limit’ is set to 24 or more passwords Low
Ensure ‘Required Password Change Period’ is less than or equal to 90 days Low
Ensure ‘Service setting of ANY’ in a security policy allowing traffic does not exist Low
Ensure HTTP and Telnet options are disabled for all management profiles Low
Ensure HTTP and Telnet options are disabled for the management interface Low
Ensure System Logging to a Remote Host Low
Ensure alerts are enabled for malicious files detected by WildFire Low
Ensure redundant NTP servers are configured appropriately Low
Ensure that a Zone Protection Profile with an enabled SYN Flood Action of SYN Cookies is attached to all untrusted zones Low
Ensure that a Zone Protection Profile with tuned Flood Protection settings enabled for all flood types is attached to all untrusted zones Low
Ensure that the Certificate used for Decryption is Trusted Low
Ensure valid certificate is set for browser-based administrator interface Low
Syslog logging should be configured Low

Risks Walkthrough

To better understand how to use the policy manager, let’s walk through an example using Risks & Warnings Policies and Requirements.

In the above image we can see the policy manager window open. The Risks & Warnings Policies tab has been selected. Below there is a dropdown that contains all the default policies available. The Default Access Rule Risk Policy has been selected.

Policy Details

When a Policy is selected we see its details on the right side of the window. Risks & Warnings Policies are device-specific and it is on this page where we can change what devices the policy applies to.  If we change whether or not the Policy is enabled, or the devices included, the Policy will run on next data import or by resetting and rerunning all risk policies. Resetting and rerunning will clear all existing risks and run all the enabled Requirements within that Policy.

Requirement Details

On the left hand side, below our chosen Policy, we can see the Requirements that are included in this Policy and an icon indicating whether or not they are enabled.

In the above image we can see then information for a default Requirement, “Any Service Open”.  looking at the details for this requirement we can see its name, its details, and the logic being used to trigger the Risk alert message. This requirement is an example of compound logic being used. This risk will only trigger if all three conditions are met. Conditions have four elements.

Requirement Conditions

Apply To This is the Table_Column that the logic test will be applied

Apply When If the string is found or not found

String What information the requirement is looking for in the specified table_column

Operator Used to build compound logic using and/or

Risks & Warnings Output

When a risk requirement is met, a risk alert will be generated and posted to the Risks & Warnings table as shown below:

The Access Rules table report will also display the highest criticality risk for each access rule as shown below:

Now that we know where the text comes from – let’s find out where the coloring comes from.

Table Highlighting Walkthrough

Table Highlighting Policies and Requirements work in almost the same way as Risks & Warnings, with a few key differences. The main being that it formats cells and texts instead of producing an alert message.

Access rules Default Policies and Requirements

+
Rule Name Text Match Action
Action – Allow or Permit or Accept or Trust Action = Allow or Permit or Accept or Trust ‘Action’ cell = None, Text = Green
Action – Deny or Drop Action = Deny or Drop ‘Action’ cell = None, Text = Red
Binding (ACL) – Any ACL = Any and Action = not (deny, drop, false, ignored) ‘Action’ cell = None, Text = Red
Destination – Any Destination = any and Action = not (deny, drop, false, ignored) ‘Destination’ cell = None, Text = Red
Destination Binding – Any Dst Binding = any and Action = not (deny, drop, false, ignored) ‘Dst Binding’ cell = None, Text = Red
Enabled – True Enabled = True ‘Enabled’ cell = None, Text = Green
Enabled – False Enabled = False ‘Enabled’ cell = None, Text = Red
Enabled – Not Analyzed Enabled = Ignored ‘Enabled’ cell = None, Text = Gray
Risk – High Risk Criticality = High ‘Risk’ cell = White, Text = Red
Risk – Medium Risk Criticality = Medium ‘Risk’ cell = White, Text = Yellow
Risk – Low Risk Criticality = Low ‘Risk’ cell = White, Text = Blue
Risk – None Risk Criticality = not (High, Medium, Low) ‘Risk’ cell = None, Text = Gray
Risk Criticality – High Risk Criticality = High ‘Risk Criticality’ cell = Red, Text = White
Risk Criticality – Medium Risk Criticality = Medium ‘Risk Criticality’ cell = Yellow, Text = Black
Risk Criticality – Low Risk Criticality = Low ‘Risk Criticality’ cell = Blue, Text = White
Risk Criticality – N/A Risk Criticality = not (High, Medium, Low) ‘Risk Criticality’ cell = None, Text = Gray
Service – Any Enabled = true, Action = not (deny, drop), Service = ‘any to any’ and not (Ping, ICMP) ‘Source’ cell = None, Text = Red
Source – Any Source = Any, Action not (deny, drop), Enabled = not (true, ignored) ‘Source’ cell = None, Text = Red
Source Binding – Any Src Binding = Any, Action not (deny, drop), Enabled = not (true, ignored) ‘Src Binding’ cell = None, Text = Red

Connectivity Paths (Interactive Service Ports)

+
Rule Name Text Match Action
Apple Remote Desktop (ARD) Port = 3283 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Database Clients (Microsoft SQL) Port = 1433 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Database Clients (MySQL) Port = 3306 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Database Clients (Oracle SQL) Port = 1521 : 1525 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Database Clients (PostgreSQL) Port = 5432 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
File Explorer (NFS) Port = 2049 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
File Explorer (SMB) Port = 445 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
File Transfer Protocol (FTP) Port = 20 : 21 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
MIB Browser (SNMP) Port = 161 : 162 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Microsoft Endpoint Mapper (EPMAP) Port = 135 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Remote Desktop (RDP) Port = 3389 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Secure Shell (SSH) Port = 22 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Team Viewer Client Port = 5938 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Terminal Emulator (Telnet) Port = 23 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Trivial File Transfer Protocol (TFTP) Port = 69 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
UNIX r-commands (rlogin, rcp, rsh) Port = 512 : 514 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Virtual Network Computing (VNC) Port = 5900 : 5901 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Web Browser (HTTP, HTTPS) Port = 80, 443, 8000, 8080 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Windows Remote Management Service (WinRM-HTTP) Port = 5985 : 5986 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
X-Server Port = 6000 : 6063 ‘Port’ cell = None, Text = Yellow‘Protocol’ cell = None, Text = Yellow
Any Port = Any ‘Port’ cell = None, Text = Red ‘Protocol’ cell = None, Text = Red

Policy Details

On the default Policy page for Table Highlighting we can see that these Policies do not require device selection.

Requirement Details

Selecting a default Requirement for this Policy shows us the requirement details.

For a Table Highlight requirement there are a few more options that are used to target the logic for the action. First, we choose the target Table and Column that will receive the Highlighting Action. Then we choose the table and column where we want the logic to run.

Requirement Conditions

Compliance Type Table Highlighting requirements can be set to run only on certain compliance frameworks

Table The target table that the highlighting will be applied to if the logic is found.

Column The target column within the previously chosen target table, that the highlighting will be applied to if the logic is found

When String The string the requirement is searching for

Is found or not found

In Column Table_Column where the requirement is searching for the designated string

Operator And/ or for building compound logic

Highlighting Action If the conditions for the logic are met this is how the cell will be colored and how the text will be colored.

Highlighting Output

When the modal report is opened that contains a highlight policy, the rules will be automatically applied and the table highlighted accordingly.

Risk Alert Reset

Sometimes there may be a reason to need to reset the risk alerts. For this, Administrator or Workspace Admins have access to a rest function on the Risks & Warnings Policies Overview page.  This action will reset all Risks and Warnings information for this workspace. After, all enabled risk policies and requirements for this workspace will be rerun.

Because Policies will be rerun after reset, at least one policy must be enabled at time of reset. Only Risks and Warnings data will be affected.

Risks & Warnings Report

This article will focus on the Risks & Warnings Report.

NP-View uses reports to present network information related to the open workspace.  These reports are available to all users and can be accessed from the main menu. For more information visit the Workspace Reports Overview article.

Accessing the Table

The Risks & Warnings Report can be accessed in two ways. with each way presenting a different data set.

  1. From the main menu: All Risks & Warnings for all devices in the current view.
  2. From the topology: Only Risks & Warnings for the selected device in the current view. Found by clicking a Firewall/ Router/ Switch > its info panel will open > and the user can select Risks Or Warnings from the Data for this Device section.

*From the main menu

 *From the info panel

What are Risks & Warnings?

Risk and Warnings are messages generated by default Policies and Requirements in NP-View. These messages are a way of automatically detecting and notifying users of risky or problematic situations on your network. They look for certain criteria, and when found trigger the designated alert. Policies and Requirements are located in the Policy Manager (accessed from the main menu).

NP-View provides sets of default Policies and Requirements that are automatically assigned to all devices when they are imported, and run when network device configuration changes are identified.

Understanding Risks & Warnings Messages

When a potential risk or warning is identified, it will be logged logged in the Risks and Warnings report with a time and date stamp.

Every potential risk is assigned and listed with

  • “type”
    • Risk or Warning
  • Criticality
  • Workspace the risk or warning was identified in
  • Device name
  • Description of the risk
  • Status (New, Confirmed, Resolved, False Positive, Will Not Fix or Fixed). Status definitions are below.

Risk Triage, Status, and Life Cycle

For new risks or warnings, users are expected to

  1. Review each item
  2. Determine if the issue needs to be addressed
  3. Then manually change the status accordingly. To change the status, double click on the status bean, change the status and click the save button.

Status Definitions:

  • new: new risk or warning identified in the most recent data load.
  • confirmed: risks or warnings that are acknowledged by the user as a valid problem to address.
  • resolved: risks or warnings that are closed by the user because the problem has been addressed.
  • false positive: risks or warnings that are closed by the user because they are not a valid problem to address.
  • will not fix: risks or warnings that are closed by the user because it was decided to not address them.

Example: Upon subsequent data updates, the system will adjust the status if required. For example:

  • If the user marks a risk as Resolved and on the next network update the risk is still identified, the status will automatically be changed to Confirmed.
  • If upon the next update the risk is no longer identified, the status will be changed to Fixed.  Fixed items are removed from the list after a period of 7 days.

Commenting on Rules from Risks & Warnings Table

New in NP-View 5.0, the Risks table connects Risks and Warnings directly with the applicable Access Rule. Not only can the status of the Risk be updated, but a comment or justification can be left on the associated rule without ever leaving the Risks & Warnings table.

1. Open the Risks & Warnings table

2. Navigate to the Risk or Waring of your choice

3. In the “Description” column click the plus sign and open the popover for the full description

4. Click the link that says see rule

5. A filtered rules table displaying the relevant rule will open at the bottom of the window for you to investigate and/or make comments on

Risks & Warnings Columns

  • Time: (RISKWARNING_TIMESTAMP) Date and Time the potential risk was identified and logged.
  • Type: (RISKWARNING_TYPE) Risk or Warning.
  • Criticality: (RISKWARNING_CRITICALITY) High, Medium or Low as defined by the identifying policy and requirements.
  • Workspace: (RISKWARNING_WORKSPACE) Name of the workspace containing the potential risk or warning.
  • Device: (RISKWARNING_DEVICE) Name of the device containing the potential risk or warning.
  • Description: (RISKWARNING_DESCRIPTION) Description of the potential risk or warning from the policy manager
  • Status: (RISKWARNING_STATUS) Current status as defined above.

Routes Report

When was it introduced?

  • Beginning with NP-View Version 5.0 (release notes) users will now have access to a new feature called the Routes Report.

What does it do?

  • Displays all information available for the Routes on the selected Device.

Where is the Routes Report located?

Available from a selected Firewall’s Information Panel

Rule Usage Analysis (Server)

The Rule Usage feature helps network admins identify rules for potential elimination due to lack of use. This feature only applies to Palo Alto NGFW (not Panorama).  Rule Usage Analysis (aka Hit Count) requests additional Access Rule usage information from firewalls using the connector. When setting up a new connector, the user will have the ability to enable the extraction of rule usage information:

Note that existing connectors will not be affected and cannot be edited to enable hit count data retrieval.

From the NGFW, we extract four values for each access rule:

  • First Hit – Timestamp of first rule usage
  • Last Hit – Timestamp of last rule usage
  • Hits Updated – Timestamp of last data refresh
  • Hits – Usage count

The information is presented as additional columns in the Access Rules Table.  The four columns are disabled by default and will need to be enabled by the user using the menu at the top right.

Once enabled, the hit count data will be displayed in the Access rules table:

Supported Devices & Data

Firewalls, Routers, Switches

The following table is a comprehensive list of supported devices. The instructions provided in the table can be used to manually extract data from the device for import. While we do our best to support the below devices, it is impossible for us to test the parsers with every possible device configuration combination. If errors occur during device import, Network Perception is committed to working with our customers to resolve their specific parsing issues.

Note that Network Perceptions device support policy follows that of the manufacturer.  When a manufacturer ends support for a product, so does Network Perception.  End of support devices are not removed from NP-View but will not be upgraded if issues arise.

Supported Devices with Vendor Partnership

The devices in this list are actively tested in our lab to support the most current versions of the manufacturer software. Network Perception has an active partnership with these vendors for software and support.

Vendor Type/Model/OS Configuration files needed
Check Point R81 / R81.10 / R81.20 including Multi-Domain Security and Virtual Router support (VRF) We support the database loading using the NP Check Point R80 Exporter (PDF documentation, video). Zip File Shasum: 5d22b182d773c020fd2a58838498b8be8221468e Exporter Tool Shasum: cc3131da37362da1291fa4a77cd8496fcb010596
Cisco
  • ASA Firewall (9.8 and up) including multi-context and Virtual Router Forwarding (VRF).
  • FTD Firewall (7.1.x, 7.2.x)
  • IOS Switch (15.7 and up) including Virtual Router Forwarding (VRF).
  • ISR (IOS-XE 17.6.x and up)
  • We do not support Application Centric Infrastructure (ACI) or NX-OS
For a Cisco IOS device, the sequence would be:
  • enable (to log into enable mode)
  • terminal length 0 (it eliminates the message between screens)
  • show running-config
For a Cisco ASA, the sequence would be:
  • enable
  • terminal pager 0
  • show running-config
For FTD, see additional instructions below
Fortinet FortiGate Firewall, FortiSwitch (FortiOS 7.0.x, 7.2.x) To get a config capture from the CLI using Putty (or some similar SSH) client, here is the process:
  • Turn on logging of the CLI session to a file
  • In the CLI of the FortiGate, issue these commands in sequence:
  • config system console
  • set output standard
  • end
  • show full-configuration
  • Turn off logging
Palo Alto Next Gen Firewall (PanOS 10.x, 11.x) including multiple virtual firewalls (vsys) and virtual routers (vrf). We do not support SD-WAN See additional instructions below

Supported Devices with no Vendor Partnership

The devices in this list are actively tested in our lab to support the most current versions of the manufacturer software.

Vendor Type/Model/OS Configuration files needed
Dell – Edge Gateway Ubuntu Core (IP Tables) see additional instructions below
Dell – PowerSwitch OS10 show running-configuration
Dell – SonicWall SonicOS (5.9.x, 6.5.x) “From GUI, Go to Export Settings, then Export (default file name: sonicwall.exp)” see additional instructions below
FS Switch (FSOS S5800 Series; Version 7.4) show running-config Note that FS configs are Cisco like and not tagged specifically as FS. We do our best to identify the device type but may display the device as Cisco in NP-View
Nvidia Mellanox (Onyx OS) show running-config Note that Nvidia configs are Cisco like and not tagged specifically as Nvidia. We do our best to identify the device type but may display the device as Cisco in NP-View
pfSense Community Edition 2.7.2 Diagnostics > Backup & Restore > Download configuration as XML
Schweitzer Ethernet Security Gateway (SEL-3620) SEL Firmware: from “Diagnostics”, click on “Update Diagnostics” and copy the text OPNsense: from ‘System > Configuration > Backup’ export .XML backup file Note: IPTables from OPNsense are not supported in NP-View.
Siemens – RUGGEDCCOM ROX Firewall RX1000-RX5000 (2.x) admin > save-fullconfiguration. Choose format “cli” and indicate file name

Historical Devices

The devices in this list were developed based on customer provided configuration files.  We are no longer actively developing these parsers but they are supported for break/fix and require customers sanitized config files to assist with the debug of issues.

Vendor Type/Model/OS Configuration files needed
Dell PowerConnect Switch console#copy running-config startup-config (instructions)
Nokia Service Router (SR7755; TiMOS-C-12.0.Rx) admin# save ftp://test:test@192.168.x.xx/./1.cfg
↳Alcatel-Lucent Service Aggregation Router (SAR7705; TiMOS-B-8.0.R10) admin# save ftp://test:test@192.168.x.xx/./1.cfg
Berkeley Software Distribution (BSD) Firewall (Open, Free and Net; 3 series) ifconfig -a > hostname_interfaces.txt See additional instructions below
Extreme Switch (x400, x600; XOC 22.6) save configuration
Hirschmann Eagle One Firewall (One-05.3.02) copy config running-config nv [profile_name]
HP / Aruba ProCurve Switch (2600, 2800, 4100, 6108) show running-config
NetScreen Firewall (ISG, SSG) get config all
Linux BSD IP Tables Firewall iptables-save See additional instructions below
NETGEAR Smart managed Pro Switch (FS/GS-Series; 6.x) CLI: show running-config all Web UI: Maintenance > Download Configuration
Siemens ROS Switch (RSG2-300; 4.2) config.csv
↳Scalance X300-400 Switch cfgsave
Sophos Firewall (v16) Admin console: System > Backup & Firmware > Import Export
VMware NSX Firewall GET https://{nsxmgr-ip}/api/4.0/edges/ (XML format) Learn more about vCenter and VSX
WatchGuard Firewall (XTM 3300, XTM 850) Select Manage System > Import/Export Configuration

Additional Instructions

Collecting Data from the Device Console

+

Collecting configuration information from the device console can be an easy way to get the device data.

Following the below rules will help ensure success when importing the files into NP-View.

Note that not all data can be retrieved from the console. Please review the section for you specific device for additional instructions.

  1. Run the command from the console.
  2. Copy the text to a plain text editor. Do not use Word or any fancy text editor as it will inject special characters that we cannot read.
  3. Review the file and look for non text characters like percent encoded text or wingdings like characters. These will break the parser.
  4. Save the output of each command in a separate file and name it after the device so that NP-View can properly attribute the files. For example: firewall1_config.txt, firewall1_arp.txt, firewall1_route.txt
  5. For Palo Alto files, there are specific naming requirements, please see the Palo Alto section for additional information.
  6. Some config files contain very long strings. Line wrapping due to the window size of the terminal will break the parser. If using a terminal like Putty, please ensure the terminal is set to maximum width.
config system console
set output standard
end

Finally, if you encounter a parsing error when loading the files and want to upload the files to Network Perception using the portal, please sanitize all files at the same time so that we can keep the data synchroized across the files.

Berkeley Software Distribution (BSD)

+

BSD has three firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF FreeBSD

  • Packet Filtering (PF): Rules located in file /etc/pf.conf
  • IP Firewall (IPFW): Default rules are found in /etc/rc.firewall. Custom firewall rules in any file provided through # sysrc firewall_script=”/etc/ipfw.rules”
  • IP Filter also known as IPF: cross-platform, open source firewall which has been ported to several operating systems, including FreeBSD, NetBSD, OpenBSD, and Solaris™. Name of the ruleset file given via command ipf -Fa -f /etc/ipf.rules

OpenBSD

NetBSD

BSD and similar systems (e.g., Linux) will use the same names for interfaces (eth1, eth2, em1, em2, carp1, carp2, etc.). The parser might be confused if the user imports interface files and packet filter configs from different systems at the same time resulting in a combined system instead of individual devices. To prevent this, the user should group all files by host, making sure to name the ifconfig file after the hostname (i.e. host1_interfaces.txt).

Free BSD Example

Below is an example of a 2 host FREE BSD system containing FW1, host1 and host2. The user should import the files in each section as a separate import. fw1 – first data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., FW1.txt’)
  • obsd_fw1_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”. Text before “_interfaces” will be used to name the device. In tis example ‘obsd_fw1’)
  • hostname.carp1
  • hostname.carp2
  • hostname.hvm2
  • hostname.hvm3
  • hostname.hvm4
  • table1
  • table2

host1 – second data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., host1.txt’)
  • host1_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”. Text before “_interfaces” will be used to name the device. In this example ‘host1’)
  • hostname.em1
  • hostname.carp1

host2 – third data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., Host2.txt’)
  • host2_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”. Text before “_interfaces” will be used to name the device. In this example ‘host2’)
  • table1
  • table2

The only required files are the config file (can be named something other than pf.conf) and the ifconfig file. hostname files are optional (unless they contain description of interfaces not in the ifconfig file). Table files contain a list of IP addresses that can be manipulated without reloading the entire rule set. Table files are only needed if tables are used inside the config file. For example, table persist { 198.51.100.0/27, !198.51.100.5 }

Legacy Fortinet Support

+

Support for Fortinet through 6.2 ended September 2023. Please note that no upgrades to these parsers will be made.

Palo Alto Panorama & NGFW

+

Panorama

If Panorama is used to centrally manage policies, the access rules and object groups can be retrieved from these devices in XML format (we do not support the import of unstructured text files). If using the Panorama connector, the required files will automatically be downloaded:through 6.2 ended September 2023. Please note that no upgrades to these parsers will be made.

The Panorama file will only contain centrally managed access rules and object groups.

Locally defined access rules and object groups cannot be retrieved from Panorama and must be retrieved from each NGFW. Please follow the instructions below to export directly from the Next Gen FireWall using API.

Palo Alto Firewalls will ALWAYS have a V-sys even if one has not been configured it will default to vsys1.

The “mapping_config” file is required which can only be retrieved through the API using the “show devices connected” command.  The name of the file is “named_mapping_config.xml” where the named prefix needs to match the device name as shown in the UI when the running_config.xml is imported alone. All files should be imported at the same time. Please see instructions below:

The below links are to the Panorama documentation for the required commands with examples. The links provide you with commands to run directly in the Panorama CLI. The images we provided are for using Postman or web browser use.

Get API Key


Get Panorama and device bundle Configuration



Get device mapping config


Once both the “<panorama_server>_running_config.xml” and <panorama_server >_mapping_config.xml” are gathered, please import them together in NP-View.

Next Gen Firewall (NGFW)

If using the PanOS connector is used to download files, the required files will automatically be downloaded:

The configuration information from the NGFW may be contained in several .xml files, <device-name>_merged_config.xml and <device-name>.vsys(n)_pushed_policy.xml.  There can be one vsys file per virtual interface. The naming of these files is important for the parser to merge them during import.  All files from a single firewall must be imported at the same time and in .xml format (we do not support the import of unstructured text files).  If any of the files are missing, improperly named or formatted, an error message will state that ‘File parsed but ruleset and topology were empty, aborting’ meaning they could not be linked to the other associated files.

An example of properly named files is below:

  • Chicago-IL-100-FW1_merged_config.xml
  • Chicago-IL-100-FW1.vsys1_pushed_policy.xml
  • Chicago-IL-100-FW1.vsys2_pushed_policy.xml

NOTE: If the NGFW is an unmanaged/standalone Palo Alto device it will not have a pushed_policy file. In this situation, the configuration .xml file can be downloaded directly from the firewall and loaded into NP-View.  The file name need not be changed when loading the file from a standalone firewall.

To manually export configuration files from an unmanaged firewall:

If the NGFW is managed by a Panorama, the API will be required to secure the necessary files:

Get API Key



Get PANos Firewall full configuration



Get Managed Firewall configuration

Virtual Routers (vrf) – Experimental Support

Virtual router (vrf) is a software-based routing framework in Palo Alto NGFW that allows the host machine to perform as a typical hardware router over a local area network. NP-View has added the experimental capability to detect Virtual Routers from Palo Alto devices (NGFW or Panorama) and present them in the Connector or Manual Import device selection screens. Virtual Routers will be treated the same as physical routers and will require a device license.

This feature is disabled by default and must be enabled prior to importing configurations containing virtual routers.

To enable the feature the NP-View Server admin will need to make a change to a system variable.

  • Stop the NP-View Server application.
  • in the docker-compose.yml file, change the enableVirtualRouters=False to enableVirtualRouters=True in three places within the file.
  • start the NP-View Server application.

For Desktop

  • Close the NP-View application.
  • In the file C:\Users\<username >\AppData\Roaming\NP-View\config.ini add enableVirtualRouters=True
  • Restart the NP-View application

Once enabled, the user will be presented with the option to select virtual routers from the connector in the device selection or upon manual import.

Legacy Palo Alto PanOS Support

+

Support for Palo Alto PanOS prior to V9.1 are no longer supported. Please note that no upgrades to parsers will be made for unsupported devices.

Dell Edge Gateway

+

The Dell Edge Gateway runs Ubuntu Core OS. The gateway uses IP tables to configure the local firewall. NP-View uses the following 4 files extracted from the Ubuntu server to generate the topology. This device is not a firewall but more of an application running device. It does have some security features but we suspect it would be behind a real firewall. The following data is needed to import this device.

  • iptables_rules → to get a device created, containing interfaces and rules
  • hostname_interfaces → associated with config above
  • arp_table → to get external hosts (ip + mac)
  • active_connections → to get routes

This is not a simple device to get data from, the following process must be followed:

1. Capture the iptables Filter Rules

To capture the iptables filter rules (the firewall rules that are active on the system), you can use the following command:

Show Command:

sudo iptables -L -v -n

Description:

Lists the currently active iptables firewall rules (filter rules). Includes details about chains (INPUT, OUTPUT, FORWARD), protocols, sources, destinations, and ports.

Save Command:

sudo iptables-save > ~/iptables_rules.conf

This will save the firewall (filter) rules in a file called iptables_rules.conf in your home directory.

2. Capture the Network Interface List

To capture the list of network interfaces (with IPs, MAC addresses, etc.):

Show Command:

ip addr show

Description:

Displays the list of all network interfaces on the system. Includes details about interface names (eth1, eth2, etc.), IP addresses, MAC addresses, and other interface attributes.

Save Command:

ip addr show > ~/hostname_interfaces.txt

This will save the interface details in a file called hostname_interfaces.txt in your home directory.

3. Show ARP Table

Show Command:

ip neigh show

Description:

Displays the ARP table, showing which MAC addresses correspond to which IP addresses on the network.

Save Command:

ip neigh show > ~/arp_table.txt

4. View Routing Table

Command:

ip route show

Description:

Displays the current routing table, showing default gateways, specific routes, and the interfaces used to reach specific networks.

Save Command:

ip route show > ~/routing_table.txt

5. Loading files into NP-View

Once all of the files have been retrieved, they need to be loaded into NP-View together and without any other files so they are properly associated.

Legacy Check Point R80 Support

+

Support for Check Point R80 through R80.40 ended April of 2024. Please note that no upgrades to these parsers will be made.

Cisco FTD

+

NP-View supports Cisco FTD through the output of “show running-config”command. However, it is important to note that Cisco FTD includes network filtering policies documented outside of the running configuration. This section explains where to find those policies.

As of version 6.1, Cisco FTD includes a Prefilter Policy feature that serves three main purposes:

  • Match traffic based on both inner and outer headers
  • Provide early Access Control which allows a flow to bypass Snort engine completely
  • Work as a placeholder for Access Control Entries (ACEs) that are migrated from Adaptive Security Appliance (ASA) migration tool.

The feature has 2 primary use cases:

  • For use with Tunnel Rule Types
  • For bypassing the Snort engine

These prefilter rules are part of the FTD configuration and are displayed via the “show running-config” command on the FTD. They manifest in the NP-View Access Rule table as a Permit IP with:

  • Source = any
  • Destination = any
  • Service = IP/any to any

As a result, the NP-View Rule Policy engine flags these rules as a high risk alert.

In the operation of the FTD, if a packet meets the prefilter policy, it is then evaluated by a secondary set of rules in the Snort engine or applied directly to the tunnel. The Snort rules are not part of the output of the of the “show running-config” output from the FTD. These rules are established, maintained and viewed on the FMC (management server), but are not readily available via the FTD CLI interface.

In the context of an audit during which evidence around these prefilter rules is requested, we recommend documenting that these rules are a default configuration for the system and we also recommend generating a FMC PDF Policy report to explain the flows of traffic within the FTD configuration. For more information, please refer to the Cisco FTD Prefilter Policies documentation.

SonicWall

+

We support .exp files as the default SonicWall file format for v5.9 and v6.X of the SonicOS.

The main UI allows for export of the encoded .exp file as such:

To extract the file via command line, then the command to export is

export current-config sonicos ftp ftp://[USERNAME]:[PASSWORD]@[FTP IP/URL]/sonicwall.exp

Where the username/password/FTP IP or URL must be changed. The file “sonicwall.exp” will then be saved at the FTP location. As this file is encoded, there’s no way to echo or cat the data.

Requesting Support for New Devices

The above list of supported hardware has been lab and field tested.  Newer versions generally work unless their is a major platform or API upgrade.  Please contact support@network-perception.com if you wish to get more information on parsers, request support for a particular device or are interested on co-developing a solution.

Connectors

NP-View includes a utility to automatically retrieve network device configuration files on a schedule. The connector types supported in NP-View Server are below:

Configuration Managers

For retrieving config files from network management systems. For each connector, the user can select the devices to be uploaded for monitoring.

Manufacturer Type/Model Configuration Information Required Connection Type
Fortinet FortiManager (6.4.x, 7.0.x) Hostname or IP address plus login credentials HTTPS + optional SSL server verification
Palo Alto Panorama (10.x, 11.x) Hostname or IP address plus login credentials See device selection section below for additional information HTTPS
SolarWinds Network Configuration Manager (Orion Platform HF3, NCM HF1: 2020.2.6) Hostname or IP address plus login credentials HTTPS

Direct Device Connection

For retrieving config files directly from the network device.

Manufacturer Type/Model Configuration Information Required Connection Type
Check Point R81.x Hostname or IP address plus login credentials See device selection and service account sections below for additional information HTTPS + optional SSL server verification
Cisco Adaptive Security Appliance (ASA 9.19) Hostname or IP address plus login credentials, enabling password and optional context SSH
Cisco Internetwork Operating System (IOS 15.9) Hostname or IP address plus login credentials, enabling password and optional context SSH
Fortinet FortiGate (FortiOS 7.0, 7.2) Hostname or IP address plus login credentials Note: SCP should be enabled in the configuration (instructions) SSH
Palo Alto NGFW (PanOS 10.x, 11.x) Hostname or IP address plus login credentials HTTPS

Volume Shares

For retrieving config files that are uploaded to a common collection repository.

Platform Connection Configuration Information Required Connection Type
Windows SMB Share (Samba) Hostname or IP address, share name, device name and root folder path SMB/CIFS
Linux SSH Share Hostname or IP address and folder path. Optionally an include list and exclude list can be defined. SSH

Additional Connector Information

Service Account

+

The use of service accounts is a recommended best practice when connecting to devices through connectors. The service account can be read-only and must have API privileges. When entering credentials related to an Active Directory domain, it is recommended to enter the username using the format account@domain.xyz instead of domain.xyzaccount as the backslash can cause unexpected issues.

Checkpoint

+

For the connector to work CheckPoint devices, the API setting need to be enabled in the SmartConsole.  See the image below for settings and commands to restart the API.

Device Selection (Palo Alto and CheckPoint)

+

CheckPoint and Palo Alto network management systems provide files with multiple devices. The connectors for these systems allow for the selection of individual devices to load into NP-View. The user can select the “Retrieve device list” button to be provides a selection list.

Collecting Layer 2 Data from Devices

+

Layer 2 data will automatically be downloaded by the connectors for Cisco ASA and Cisco IOS devices. If the data is manually collected, use the following commands and file naming conventions.

Cisco ASA
  1. show running-config → 'device_name'.'context_name'.txt
  2. show arp → 'device_name'_arp_table.'context_name'.txt
  3. show route → 'device_name'_route_table.'context_name'.txt
  4. show interface → 'device_name'.'context_name'.interface_table.txt
  5. show access-list → 'device_name'.'context_name'.access_list.txt

Cisco IOS
  1. show running-config → 'device_name'.txt
  2. show ip arp → 'device_name'_arp_table.txt
  3. show ip interface brief → 'device_name'_interface_table.txt

Once all of the files are collected, manually load the files from each device together and separately from other devices for proper file association.

Samba

+

Network Perception suggests the following when setting up the SMB connection.

  1. Create a read-only user in Active Directory or on the SMB server.
  2. Determine the available share (Get-SMBShare” in Windows PowerShell) or create a new one.
  3. Share the SMB folder containing the Configuration files with the read-only user. For example:

Configuration:

Lets assume that the server is at \\192.168.140.14\
  • the shared folder is named 'share'
  • and the files are in a sub folder of share called \test\NERC-CIP-EMS
  • a UNC would look like this: \\192.168.140.14\share\test\NERC-CIP-EMS
  • Per the above, the device name was set to LAB-SMB
When configuring the SMB connector, the screen would look like this:

If during the connector test, access is denied, the following settings should be verified and may need to be changed for the SMB to work as expected.

Running PowerShell as administrator

Input command Get-SmbServerConfiguration

Verify that EncryptData is set to false

If set to true, run command “Set-SmbServerConfiguration -EncryptData 0

Verify SmbServerHardeningLevel is set to 0

If not set to 0, run command “Set-SmbServerConfiguration -SmbServerNameHardeningLevel 0

Microsoft recommended default is off (0). More information about these settings can be found on the Microsoft website.

SSH and Samba for HA Groups

+

NP-View has the ability to handle HA Groups.

As a best practice, if using SSH or SNB shares, it is best to overwrite the entire folder with updated config files from the current active devices. It is also a best practice to name the HA devices similarly for comparison. For example:

Pittsburgh_FW1

Pottsbirgh_FW2

etc.

For Samba shares, a similar method should be followed.

Refer to the Samba section for details.

If you have a system for which you need a connector or if you encounter a technical issue, please contact support@network-perception.com.

Configure Connectors (new)

This document relates to NP-View Desktop and Server version 6.0 and later.

Connectors automate the secure retrieval of configuration files from firewalls, routers, switches, and network device configuration managers. NP-View Desktop and Server can host one or more connectors that securely retrieves configuration files manually (desktop and server) or at the specified frequency (server only).

To access the connector function, use the system menu in the upper right corner of NP-View and select 'Manage connectors'

The connector function consists of several key features.

  • Password manager to reuse and manage passwords across multiple connectors.
  • Workflow for creating groups and connectors.
  • Automated data collection and download.
  • Flexible scheduling (Server only).
  • Runtime and scheduling status (Server Only).

The connector function supports the files devices listed on the connectors page.

Add Credentials

To get started, the user must first create one or more credentials. Credentials are used to access the devices and can be used for one or more devices. This provides for the ability to manage multiple devices with one set of credentials. Click the 'Add New Credential button to display the input section. Credentials are segregated by device type. Select the device type and input the required fields.

Once filled in, select the save button and the credential will be saved and displayed in the 'Credentials' box. Clicking on the credential will allow the user to edit the credential.

At this time, Deleting a credential is not supported.

Create Groups

Once credentials have been created, the user can proceed to creating a Connector Group.

Select the '+' in the 'Groups' section to display the add groups function. Fill in the group name, notes and select a schedule (server only). For desktop, only the 'On Demand' function will be displayed.

Once saved, the user can click on the connector group name in the 'Groups' panel to enter edit mode or select the three dots to the right of the name for individual group options.

Pull to run all associated connectors and delete to remove the group. Note that only empty group can be deleted.

Scheduling Groups

Groups can retrieve data on a schedule, when setting up or editing a connector group, the user can set a schedule.

The user has multiple options for scheduling the connector; monthly, weekly, and daily with flexible day of week and time options. We recommend that connectors be run at night to provide maximum resources for processing the data. When a connector group is scheduled, the next run status will be presented in the 'Groups' panel

and on the 'Processes' tab

Add Connectors

Once a group has been created, the user can add connectors to the group. In the connectors section, select the '+' to present the add connector function.

Proceed to select the connector type and fill in the required fields.

Next fill in the optional fields.

Filling in the name of a context will only fetch the data for that one context, leaving blank will fetch all contexts.

Selecting one ore more worspaces to deliver the fetched data. If left blank, the data will be retrieved for manual download.

The user can then test the connector to verify the credentials and/or save the connector.

Once saved, the user can click on the connector name in the 'Connectors' panel to invoke edit mode. Clicking on the tree dots next to the connector name provides individual connector options.

Manual Data Pull

Data from individual connectors can be retrieved manually by selecting the 'pull' option from the menu above. When selecting pull, the connector status will proceed to 'in progress'

and the processes tab will also display the progress status.

Once data has been pulled, the user can selectively download the most current data set from the connector panel.

Deleting Workspaces

If a connector is designated to deliver data to workspace and a user deletes the workspace, the connector will automatically be updated to reflect the workspace deletion.

Configuring Connectors (legacy)

In version 6.0, a new connector function was introduced. for new connector users, it is recommended to use the new connector function. The connector access has been moved from the +Import function to the system menu.

Connectors automate the secure retrieval of configuration files from firewalls, routers, switches, and network device configuration managers. NP-View Server can host one or more connectors that securely retrieves configuration files at the specified frequency. By default, connectors are accessible through HTTPS on port TCP/8443 of the NP-View server and is isolated for security purposes.

The first time an administrator accesses the connectors, they are required to define a Connector group name and a secure passphrase. The Connector group name will be used to create the encrypted connector file store. Connector information is encrypted at rest and in transit using a passphrase protected PGP key. Only the connector owners know the passphrase and the passphrase is never stored. Once initiated, connectors run in the background collecting network information.  If the NP-View server is restarted, the connector owner is required to re-authenticate and restart the connectors. Connector owners can create multiple connector groups and each will require their own login. Once created, the user can select from the list of available connectors when logging in.

The connector page contains five main options.

Add New Connector

The buttons from left to right are:

  • + Add New Connector
  • bulk start all connectors (see bulk start parameters below)
  • bulk stop all connectors
  • delete the connector (user must be logged into the connector group to delete)
  • exit the connector group.

Add Connector

To add a new connector, select “+Add New Connector”  button and a list of available connectors is presented. Connector options are: Cloud Providers, Configuration Managers,  Direct Devices and Volume Shares

Upon selecting the Connector type to add, the user is requested to fill in connection information. Connector information varies by vendor.  The connector configuration for a Palo Alto device is as follows:

The user must enter a Connector name (no spaces), host name, and credentials.  The user can then verify the credentials are correct with the “Test credentials” button.  The user can setup the polling cycle and provide the workspaces to deliver the resultant information.

Polling Cycles are:

  • On demand
  • Daily
  • Weekly
  • Bi-Weekly
  • Monthly

Configuration Management Systems

For Configuration Management Systems and file Shares, additional information may be required.  The user can retrieve a list of files from the device and filter the results.  To include specific files, put them in the include list field.  To exclude files, put them in the exclude list field.  If both lists are used, include list filter will be applied first and the exclude list filter to the results of the include list filter. If the share is PGP encrypted, a PGP Public key will be required.

Workspaces must be added to the connector for data to be transferred and displayed in the workspace.  If workspaces are added after a connector is setup, data will not be sent to the workspace until the next scheduled import and a configuration change is identified.  Creating workspaces before connectors facilitates faster visualization of data.

Connector Tile

Once the connector is added, a tile is added to the connectors home page.

Connector tiles are sorted by the characters in their names using standard Linux conventions:

  1. whitespace
  2. integer
  3. special char
  4. uppercase [A-Z]
  5. underscore (possibly other special chars)
  6. lowercase [a-z]

From the tile, the user can:

  • manually activate the connector for a one time data pull
  • run / pause the connector
  • edit the connector
  • copy the connector
  • delete the connector.

The tile banner will show in three colors:

  • red – connector failed
  • blue – connector scheduled to run
  • gray – connector paused

Click the start / pause button to restart a failed or paused connector, note that a connector may take several minutes to change the banner color.

Connector for Forescout

+

The Connector for Forescout 8.1 and later enables integration between CounterACT and NP-View such that network device configuration files managed by CounterACT can be automatically imported into NP-View and aggregated into specific workspaces. Currently, Cisco switches are supported through the Forescout Switch Plugin.

  • Download the Forescout Extended Module for NP-Vie from https://updates.forescout.com.
  • Start your Forescout Console and login into Enterprise Manager.
  • Then open “Options”, select “Modules”, and install the fpi.

To request additional support for this connector or to request support for other devices, please contact support@network-perception.com.

Connectors + Samba (SMB) Access Error

+

This error can be caused by two communication scenarios between Linux and Window. Either SMB encryption is enabled on the Server or SPN target name validation level is enabled (or both). To check which of these features is causing the issue, Run PowerShell on the Windows Server as administrator and run the following command:

Get-SmbServerConfiguration

If EncryptData = True, it can be disabled using:

Set-SmbServerConfiguration -EncryptData 0

If SmbServerNameHardeningLevel is set to any value other than the default of 0 run:

Set-SmbServerConfiguration -SmbServerNameHardeningLevel 0

to restore the default.

Connectors fails to initiate connection to outside devices

+

In some instances, the Linux distribution is preventing the connectors (Docker) from initiating connections to outside devices. The solution is to update the firewall settings on the Linux distribution using the following commands:

# firewall-cmd --zone=public --add-masquerade --permanent
# firewall-cmd --reload
# systemctl restart docker

Configuring Read-only Access to Cisco

+

The NP-View Connector for Cisco uses a read-only SSH connection to collect the output of the show running-config command. It is best practice to create a dedicated read-only user on your Cisco devices when configuring connectors. Here are the commands to only give the minimum permissions needed for this user:

conf t
aaa authorization command LOCAL
privilege show level 2 mode exec command running-config
privilege cmd level 2 mode exec command terminal
username $USERNAME password $PASSWORD priv 2
end

Bulks Start Parameters

+

To help balance the processing load of managing multiple connectors and improve user experience on the topology map, the bulk start function can be scheduled to off hours using system parameters. The docker-compose.yml file contains two parameters for the bulk system start function in the monitor: environment: section

  • connBulkStartTime=21:00:00 # defines the start time for the connectors, format is Hours:Minutes:Seconds, 24 hour clock.
  • connBulkStartSpread=00:15:00 # defines the connector start stagger, format is Hours:Minutes:Seconds

Deleting Connectors

+

Connectors can be deleted by entering the connector group name and passphrase to gain access to the connector. The connector can be deleted by selecting the trash can in the upper right corner.

If the passphrase is forgotten, the connector can be forcefully deleted by the Linux Admin by removing the connector file from the folder

/var/lib/docker/volumes/NP-Live_np-connect/_data.

Reference

Help Center

Help Center

The Help Center can be found on the system menu on the upper right corner of the topology.

The Help Center will display warnings or errors identified during the import of device files.

The information in the help center is designed to provide information for the tech support team to help diagnose the issues.

There are many types of possible errors including:

  1. Invalid file formats (e.g., .gif or .png)
  2. Improperly formatted files (files exported as text but loaded into a word processors where extra characters are added before saving).
  3. Incomplete set of files (many devices require more than one file for import this includes Palo Alto and IP tables)
  4. Misconfigured files where rules or objects are undefined.

As every customer has a different environment and possible device configurations are endless.  We sometimes run into a situation where the parser cannot handle the device as configured.  When this happens, we request the customer to sanitize the config file on the NP Poral and upload the file for debug purposes.  Support from our customers is important for us to quickly remediate parsing issues unique to a device or specific file.

The Help Center provides a download for the error log which can be submitted to technical support through the support portal.