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.
Actively Supported Devices
The devices in this list are actively developed and tested to support the most current versions of the manufacturer software.
Manufacturer | Type/Model/OS | Configuration files needed |
Check Point | Gaia OS R80/R81) | We support the database loading using the NP Check Point R80 Exporter (PDF documentation, video). |
Cisco | ASA (9.x)
FTD Firepower (6.x, 7.0.x) Catalyst/ISR (IOS/IOS XE) |
show running-config on the command line terminal of each device you’d like to import. For FTD, see additional instructions below |
Dell | PowerConnect Switch | console#copy running-config startup-config (instructions) |
SonicWall | SonicOS 6.x, 7.x | “Export Settings, then Export (default file name: sonicwall.exp)” |
Fortinet | FortiOS (6.X, 7.0.X) | show full-configuration |
Juniper | Junos OS Firewall (SRX-V) / NetScreen Firewall (ISG,SSG) | show configuration
|
Linux IP Tables | Firewall | iptables-save See additional instructions below |
Palo Alto | Next Gen Firewall (9.x, 10.x) including virtual firewalls. We do not support SD-WAN | See additional instructions below |
Siemens | ROS Switch (RSG2-300; 4.2) | config.csv |
RuggedCom | ROX Firewall (RX1000-RX5000; 1.16-2.9) | admin > save-fullconfiguration. Choose format “cli” and indicate file name |
Scalance | X300-400 Switch | cfgsave |
Legacy Supported Devices
The devices in this list are not actively developed or extensively tested but are supported to resolve customer identified issues.
Manufacturer | Type/Model/OS | Configuration files needed |
Nokia | Service Router (SR7755; TiMOS-C-12.0.Rx) | admin# save
|
Alcatel-Lucent | Service Aggregation Router (SAR7705; TiMOS-B-8.0.R10) | admin# save
|
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 |
|
NETGEAR | Smart managed Pro Switch (FS/GS-Series; 6.x) | CLI: show running-config all Web UI: Maintenance > Download Configuration |
pfSense | Firewall (2.4, BSD 11.1) | Diagnostics > Backup & Restore > Download configuration as XML |
SEL-3620 | Firewall | From “Diagnostics”, click on “Update Diagnostics” and copy the text |
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 |
Experimental
Support for the following device are in various stages of development and are provided for field testing purposes. Using these devices may or may not work for your specific environment or configurations. If you find issues with these devices, please provide your feedback to support@network-perception.com
Manufacturer | Type/Model/OS | Configuration files needed |
Amazon Web Service | Security Groups & Network Access Control Lists | aws ec2 describe-security-groups aws ec2 describe-instances |
Azure Cloud | Resource Groups (e.g., VM, VNets, Subnets, NICs, NSGs, etc.) | Azure Cloud Shell (PowerShell 2.1.0): Export-AzResourceGroup |
Google Cloud Platform | Firewall rules, Instances, Subnets, Routes, VPN Gateways, VPN Tunnels | Firewall rules (`gcloud compute firewall-rules list --format=json`) |
Stormshield | Industrial Firewall, SN, SNi (4.2.4) | autobackup.sh or setup auto backup via console Configuration > System > Maintenance |
Additional Instructions
Berkeley Software Distribution (BSD)
Berkeley Software Distribution (BSD)
BSD has three firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF
- 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
- Packet Firewall (PF): Rules located in file /etc/pf.conf
- 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 }
Palo Alto NGFW & Panorama
Panorama
If Panorama is used to centrally manage policies, the access rules and object groups can be retrieved from the running configuration XML file (we do not support the import unstructured text files). 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.
To download the .XML from the Panorama UI:
- Connect to the Web user interface of your Panorama device
- Go to Panorama > Operations > Export, and select “Export Panorama and devices config bundle” it may take a few minutes to generate the file.
- Once ready, the .XML file (e.g., Panorama_20230306.tgz) will automatically download to your local downloads folder in .tgz format.
- Open the .tgz file using the extraction program of your choice (e.g., 7zip)
- The extracted folder will contain a compressed .tar file (e.g., Panorama_20230306.tar) which also needs to be extracted using the extraction program of your choice.
- The extracted .tar file contains a folder which contains the extracted Panorama data.
- The extracted folder will contain a compressed .tar file (e.g., Panorama_20230306.tar) which also needs to be extracted using the extraction program of your choice.
- Import all of the extracted non 0 byte .XML files using the NP-View import function.
If your system contains .VSYS, an additional "mapping_config" file is require which can only be retrieved through the CLI using the “show devices connected” command. The name of the file is “named_mapped_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 as the Panorama config.xml.
The below links are to the Panorama documentation for the required commands with examples.
Get Panorama and device bundle Configuration
Next Gen Firewall (NGFW)
The configuration information from the NGFW is contained in several .xml files, _merged_config.xml and .vsys(n)_pushed_policy.xml. There will 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 plain text files). If the files are improperly named or formatted, an error message will show that the files have parsed but are empty 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
To download the .XML:
- Connect to the Web user interface of your NGFW device
- Go to Device > Setup > Operations and select “Export Configuration Version” it may take a few minutes to generate the file.
- Once ready, the .XML file will automatically download to your local workstation.
- Import the .XML file using the import function.
The below are the required commands with examples.
Get PANos Firewall full configuration
Get Managed Firewall configuration
Get Rule Hit Count
Legacy Check Point R77 Support
Support for Check Point R77.30 ended in May of 2019. Please note that no upgrades to this parser will be supported if it fails to operate as expected. Below are the instruction for manually exporting R77 files.
Check Point R7x version store configuration information in flat files on the management server's filesystem. The file location is different when using a multi-domain environment.
When using Checkpoint R77 management server, the required files can be found here:
- /etc/fw/conf/objects_5_0.C
- /etc/fw/conf/rulebases_5_0.fws
- /etc/fw/conf/identity_roles.C (optional)
Load all of the retrieved files at the same time into NP-View.
When using a Multi Domain environment, the required pairs of objects and rule base files are typically stored in: $MDSDIR/customers/
If you have trouble locating the files, you can use the command: find / -name "rulebases_5_0.fws" -ls to locate the files.
All configs in these 3 locations are required (not just one)
- One Global Database, located in directory: /var/opt/CPmds-R77/conf
- One Multi-domain Server (MDS) database, located in directory: /var/opt/CPmds-R77/conf/mdsdb
- The contents of the Domain Management Server databases (DMS), located in directory: /var/opt/CPmds-R77//CPsuite-R77/fw1/conf/ which include:
- object
- rulebase
- /object...
Load all of the retrieved files at the same time into NP-View.
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.
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.