www.network-perception.com Open in urlscan Pro
35.152.119.144  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Dragos Acquires Network Perception
KNOWLEDGE BASECUSTOMER PORTAL
Product
Solutions

Network VisibilityNetwork AuditingNetwork SegmentationNERC-CIP
Resources

BlogWhite PapersCase StudiesProduct WalkthroughAll Resources
Company

AboutPressPartnershipsContact Us
Request Demo


Main
>
Supported Devices & Data
>
Firewalls, Routers, Switches


FIREWALLS, ROUTERS, SWITCHES

Updated
November 5, 2024

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

 * Packet Firewall (PF): Rules located in file /etc/pf.conf

NetBSD

 * NetBSD Packet Filter (NPF) for Packet Filter (PF): Rules located in file
   /etc/npf.conf
 * IP Filter (IPF): Use /etc/ipf.conf to allow the IPFilter firewall

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.


RELATED


SUPPORTED DEVICES & DATA


ARTICLES

Connectors
Configuring Connectors (legacy)
Auxiliary Data
Firewalls, Routers, Switches
Connectors
Configuring Connectors (legacy)
Auxiliary Data
Table of Contents
Supported Devices with Vendor Partnership

Supported Devices with no Vendor Partnership

Historical Devices

Additional Instructions

Requesting Support for New Devices

Solutions
NP-View
Network Visibility
Network Auditing
Network Segmentation
NERC-CIP Compliance
Resources
Blog
White Papers
Case Studies
Product Walkthrough
All Resources
Company
About
Partnerships

© 2024 Network Perception. All Rights Reserved.

Privacy PolicyTerms of ServicePCI Compliance
×
We Value Your Privacy
Settings
NextRoll, Inc. ("NextRoll") and our 19 advertising partners use cookies and
similar technologies on this site and use personal data (e.g., your IP address).
If you consent, the cookies, device identifiers, or other information can be
stored or accessed on your device for the purposes described below. You can
click "Allow All" or "Decline All" or click Settings above to customise your
consent regarding the purposes and features for which your personal data will be
processed and/or the partners with whom you will share personal data.
NextRoll and our advertising partners process personal data to: ● Store and/or
access information on a device; ● Create a personalised content profile; ●
Select personalised content; ● Personalised advertising, advertising
measurement, audience research and services development; ● Services development.
For some of the purposes above, our advertising partners: ● Use precise
geolocation data. Some of our partners rely on their legitimate business
interests to process personal data. View our advertising partners if you wish to
provide or deny consent for specific partners, review the purposes each partner
believes they have a legitimate interest for, and object to such processing.
If you select Decline All, you will still be able to view content on this site
and you will still receive advertising, but the advertising will not be tailored
for you. You may change your setting whenever you see the Manage consent
preferences on this site.
Decline All
Allow All
Manage consent preferences