FSM FAQ

Q0: What are the supported firewall types? Are all features supported on all firewall types?

The detailed list of supported features and firewall versions is here

Q1: Does FSM require 1 or 2 device license(s), in order to manage firewalls clusters (or pairs)?

FSM requires 2 device licenses, in order to manage both members of a firewall cluster/pair, if you decide to do so.

If you decide to import each member of the cluster into the FSM Inventory, each member will be identified by its cluster member IP address, and not the cluster IP (which is the same for both members, and therefore non unique), and will require a device license.

However, depending on the vendors that you use, it might be more or less interesting to import both members.

Our recommendation is as follows:

For Check Point firewalls, we generally recommend to import only one of the cluster members, because configurations are usually pretty synchronized, across the cluster members.
For Cisco and Netscreen firewalls, we generally recommend to import both cluster members, because configurations might actually be different; unless you are pretty sure that the policies on both the members are the same

Q2: What are the FSM system requirements?

They are described here

Q3: Is the PathFinder product available?

This product is not being sold anymore, but the piece that understands the path and connectivity along it, is in FSM, as a feature called Packet Tracer.

The visualization piece of PathFinder is not in FSM.

We recommend evaluating FSM and look at Packet Tracer and make an opinion about how critical the diagram (lack of), is.

The main value, i.e. the connectivity along the path, is preserved and enhancemend in FSM, via the Packet Tracer function.

Q4: FSM and the ASA multi-context

In ASA multi-context firewalls, there is one admin context and multiple user contexts. The admin context only specifies the interface assignments to each user context, no firewall rule/object definition. The user context contains the firewall rules/object definition and works as a separate firewall. FSM only analyzes the user context.

The admin context also has one special interface for firewall management purpose. The FSM connector can access each user context directly or access the user context through the admin context, i.e. connecting to the admin context via the management interface, then switch from the admin context to the user context.

Basically, the FSM connector uses the admin context as a jumper.

FSM treats each user context as a separate firewall. Each user context consumes one license seat.

FSM does NOT analyze the admin context. The admin context config does NOT consume any license seat.

Q5: How does Firewall Security Manager collect and store data?

Firewall Security Manager uses the configuration files of supported firewall devices to perform analysis. The configuration files are imported from the local host's filesystem and must be obtained from the firewall device independently of Firewall Security Manager.

For help on obtaining configuration files you can also download the Firewall Security Manager Data Collection Guide.

Q6: How do I use Firewall Security Manager to find and clean up unnecessary rules?

Firewall Security Manager identifies unnecessary rules as those rules whose functionality is covered by one or more preceding or succeeding rules in the rule base. Removing these rules will not have any impact on the behavior of the firewall. Firewall Security Manager flags these unnecessary rules in the Redundant and Shadowed Rules section of the Firewall Cleanup and Optimization report. Redundant rules are rules that have the same rule action as the rules that cover it. Shadowed rules are rules that have a different action than the rule or rules that cover it. This could indicate a potential misconfiguration since the intent of the rules is in conflict.

Firewall Security Manager identifies rules that are made redundant or shadowed by one or several rules, each of which covers only a portion of the redundant rule. Redundant rules either both precede and following a given rule.

A rule may be made redundant by rules that either precede or follow it. We have noticed that more than 50% of the redundant rules actually are covered by rules that follow it. This might typically happen when there are a lot of specific rules and then a general rule that covers all the specific case and more is added to the rule base.

The Redundant and Shadowed Rules section of the Firewall Cleanup and Optimization report shows the unnecessary rules and the rules that cover them. Each individual rule that is unnecessary is identified with a comment. For example, "Redundant to <10, 20>" or "Shadowed by <40, 50>". The number in the comment refers to the rule number (or line number) of the access list statement in the rule base that covers the redundant or shadowed rule.

You may also wish to eliminate Disabled rules and/or Time inactive rules listed under the corresponding section header in the Rule Cleanup and Optimization report.

Note: There are instances where you may not want to remove a rule, despite the fact that it is redundant because it is covered by a rule below it. The reason is that the redundant rule may be inserted for a purpose, i.e. to log packets to specific destination specified in the rule, to perform application inspection, or to improve performance. In such cases, leave the rule as is.

Q7:How do I use Firewall Security Manager to find and clean up unnecessary objects?

Firewall Security Manager identifies all address and service objects that have not been used in any of the ACL and NAT rules within the firewall. Unused objects are determined by analyzing the membership hierarchy of group objects used in a rule. The sections Unused Network Objects, Unused Network Group objects, Unused Service Objects and Unused Service Group Objects in the Firewall Cleanup and Optimization report list all the unused objects in the firewall configuration.

Q8:How do I use Firewall Security Manager to get usage data about my firewall rules?

Firewall Security Manager aggregates the rule usage data from firewall logs or access list hit counts. This means that you can use daily or weekly logs over an extended period of time to get an accurate picture of rule usage. Firewall Security Manager uses this data to present a report showing the most used rules, unused rules and an optimized rule order for better firewall performance. The aggregated rule usage data can be found in the Most Used Rules, Unused Rules and Optimized Rule Order sections of the Firewall Cleanup and Optimization report.

For Check Point and Juniper NetScreen firewalls, the firewall logs are used for determining rule usage. Any rule which has a tracking option and is not found in the firewall log data is marked as unused.

For Check Point firewalls, Rule UID in the firewall log data is used to identify the used rules in the firewall rule base. For Netscreen firewalls, policy ids in the firewall syslog data is used to identify the used rules in the firewall rule base.

For Cisco PIX/ASA/FWSM firewalls, access list hit counts are used for determining rule usage. Any rule that has a hit count of zero is considered as unused. The access list hit counts can be obtained by using the command "show access-list". The access list hit counts are reset when the firewall is restarted. The hit counts can also be reset explicitly using the command clear access-list [id] counters.

If SolarWinds NCM system is being used as the source of importing firewall configuration data, Firewall Security Manager automatically downloads the access list hit count from the firewall using Orion NCM system.

Q9:How do I use Firewall Security Manager to optimize my rulebase for better performance?

Firewall Security Manager combines the rule usage data from the firewall logs with the rule order dependency analysis to compute an optimized rule order that improves the performance of the firewall. Rules are reordered based on usage and taking into account order dependencies. Order dependent rules are those rules that overlap with each other and have opposite actions (for example permit and deny). The optimized rule order preserves the original firewall behavior.

You should run Firewall Security Manager to determine the optimized rule order after you have completed rule cleanup involving unnecessary or unused rules.

Order dependent rules are listed in the Rule Order Dependencies section of the Firewall Cleanup and Optimization report. The new optimized rule order can be found in the Optimized Rule Order section of the report.

Q10:How do I use Firewall Security Manager to find ACL rules that match a given service, source, or destination address in my firewalls?

Using the Rule Search feature in Firewall Security Manager, you can quickly search for ACL rules across multiple firewalls by using service, source, and destination. Source and destinations can be ip address ranges or object names. The search value for a service can be an object name, or a port value, a port range for TCP/UDP services, or a protocol range. If any of the 3 search parameter(s) is omitted, they will not be used in the search.

The search feature provides an option for a partial or an exact match of the search parameter values, with an exact match being the default.

A partial match is very useful to search for occurrences of a specific address, service, or object in a rule. This is very useful when the service is part of an object definition, and you do not know the object name.

An exact search is useful if you are searching for rules that contain the entire input as is or as part of a larger aggregation such as a group object. For example, when you are searching for a range value or "Any", you may not want to see rules that match partially with the range value used in the search and instead find rules that exactly contain all your search values.

You can also restrict the search to return only allow or deny rules.

The results are presented in a uniform tabular view for all firewall types.

Q11:How do I use Firewall Security Manager to find ACL rules that refer to a service or address object in my firewalls?

Using the Rule Search feature in Firewall Security Manager, and enter the service or address object appropriately. You may further narrow your search by specifying other address and/or service parameters as well, and you can also search across multiple firewalls in a single step. If any of the three parameter are omitted, then they are not used in the search. You can also restrict the search to return only allow or deny rules.

The search results will also include rules that refer to the object groups that contain the object names specified in the search. This will give the ability to understand the full impact of the object that you are looking for, on the ACL rules.

Q12:How do I use Firewall Security Manager to quickly find the member and containing object hierarchy of a service or address object?

Using the Object Search feature in Firewall Security Manager, you can use a service or address object name to quickly search objects across multiple firewalls in the inventory. The searching for the objects using the object name will be done using a prefix match i.e., you do not need to specify the complete object name when searching for objects, which is helpful if the object name is long or you are not sure of its complete name. The search will return all objects matching the object name including any object groups containing the object in the member hierarchy.

The results will be presented in a Tree table uniform for all firewall types showing the complete hierarchy of object groups down to the lowest level with the ability to expand and view any member object definition in the hierarchy. All the objects that matched the name are highlighted in bold in the results tree including the cases where the objects appear as members in an object group. This quickly lets you get to the objects you are looking for while at the same time having information about object groups refer to the object you are looking for.

Q13:How do I use Firewall Security Manager to quickly find all service objects and object groups that match a port range?

Using the Object Search feature in Firewall Security Manager, you can use a service port range to quickly search service objects across multiple firewalls in the inventory. The search will return all service objects matching the port range including all object groups containing the matched service object in the member hierarchy. All the service objects that matched the port range are highlighted in bold in the results tree including the cases where the objects appear as members in an object group. This quickly lets you get to the objects you are looking for; while at the same time having information about object groups refer to the object you are looking for.

The search has an option to return objects that match only part of the port range. By default only objects that match the complete port range are returned.

Q14:How do I use Firewall Security Manager to quickly find all address objects and object groups that match an ip address or a subnet?

Using the Object Search feature in Firewall Security Manager, you can use an ip address subnet mask to quickly search address objects across multiple firewalls in the inventory. The search will return all address objects matching the ip address mask including all object groups containing the matched address object in the member hierarchy. All the address objects that matched the ip address mask are highlighted in bold in the results tree including the cases where the objects appear as members in an object group. This quickly lets you get to the objects you are looking for; while at the same time having information about object groups refer to the object you are looking for.

The search has an option to return objects that match only part of the ip address mask. By default only objects that match the complete ip address mask are returned.

Q15: What are the FSM recommendations related to performance and maximum scalability?

We recommend using 64 bit operating system to support large files for the FSM database to account for the growth in the size of the database.

Multi-core processor help in simultaneous requests to Change advisor, LicenseManager and FireBird services on the shared database server.

The objects that grow in the shared database, as the number of devices and history increases, are:

rules,
objects and canonical scheme definition for the current version of each firewall (fixed for each firewall),
compressed versions of each configuration as user update firewalls (grows for each new version),
rule and object modification history for each rule and object modification (grows for each modification),
change ticket information and packet tracer result data (grows per ticket).
modified configurations of blocking devices as well as the change script, if Packet Tracer is utilized

Q16. Is FSM an add-on to NCM?

FSM and NCM are separate products. Both can be run standalone, without the other.

But they are integrated to each other and obviously very complementory.

Running both delivers a very good coverage of the "Network Configuration & Change Management" - NCCM - fonctional space.

This table illustrates the complementarity and the combined coverage:

This whitepaper describes Firewall Analytics (FSM) and Configuration Management (NCM), in general terms, and more preciselly the integration between FSM and NCM.

Q17. How to change FSM database password?

The following procedure describes how to change the database password of your FSM server and remote FSM clients

Launch an FSM client on the Server's machine. Note that there is always a local client installed with the server, whether you installed explicitely or not
Go to the Window > Preferences > Change Firebird Password page and change the password.
Go to each remote client machine and re-run the Client installer (choose advanced install) and enter the SharedDb password during installation.

Q18a. What are the FSM log files (FSM 6.3.x and before)

1. Installation logs. Get these logs if FSM installation fails, or FSM client fails to launch

XP/2003

C:\Documents and Settings\All Users\AthenaInstall-<installation-date>.log

C:\Documents and Settings\All Users\AthenaServiceInstall.log

Win7/Vista/2008 (please note ProgramData is a hidden folder)

C:\ProgramData\AthenaInstall-<installation-date>.log

C:\ProgramData\AthenaServiceInstall.log

2. FSM Client core logs. Get this log if FSM client fails to import/update devices, or perform queries, or generate reports

C:\Program Files\SolarWinds\AthenaFirePACServer\logs\firepac-core.log (or AthenaFirePACClient depending on whether or not the client is located with the server)

3. FSM Connector logs. Get this log if FSM client fails to import/update devices.

C:\Program Files\SolarWinds\AthenaFirePACServer(or AthenaFirePACClient)\logs\deviceconnector.log - if FSM client fails to import/update devices using FSM direct connector
CPMI connector log - if FSM client fails to import/update Check Point firewalls using CMPI connector

XP/2003 - C:\Documents and Settings\<user_account>\SolarWinds\ AthenaFirePAC Server(or AthenaFirePAC)\workspace\AthenaCpmiClient.log

Win7/Vista/2008 - C:\Users\<user_account>\SolarWinds\ AthenaFirePAC Server(or AthenaFirePAC)\workspace\AthenaCpmiClient.log

4. FSM Client workspace logs. Get this log if FSM client fails to launch, or fails to import/update devices, or perform queries, or generate reports

XP/2003 - C:\Documents and Settings\<user_account>\SolarWinds\AthenaFirePAC Server(or AthenaFirePAC)\workspace\.metadata\.log
Win7/Vista/2008 - C:\Users\<user_account>\SolarWinds\AthenaFirePAC Server(or AthenaFirePAC)\workspace\.metadata\.log

5. FSM CheckPoint LEA log. Get this log if FSM client fails to collect traffic logs from Check Point LEA server

C:\Program Files\SolarWinds\AthenaFirePACServer\cpmi\Lea_<LEA_server_ip>\AthenaLogCollector.log

6. Change Advisor log. Get this log if the Change Advisor web console encounters any error

C:\Program Files\SolarWinds\AthenaFirePACServer\webservice\workspace\.metadata\.log

Q18b. What are the FSM log files (FSM 6.4 and after)

1. Installation Logs

These logs contain a detailed tracking of the installation process. Always obtain these logs when troubleshooting a problem with the FSM installation process.

Win7/Vista/2008
C:\ProgramData\FSMInstall-<installation_date>.log
C:\ProgramData\FSMServiceInstall.log

Note: the ProgramData folder is normally hidden, so it will not be visible by default. To view it you must enable hidden folders in the View tab of the Windows Explorer Folder Options dialog.

WinXP/2003
C:\Documents and Settings\All Users\FSMInstall-<installation_date>.log
C:\Documents and Settings\All Users\FSMServiceInstall.log

2. FSM Core Logs

These are the primary log files used for identifying most problems. These log files are located in the logs folder of the installation directory. The installation directory can be found in the following location if the server is installed on the host:

C:\Program Files\SolarWinds\SolarWinds FSMServer

The installation directory can be found in the following location if the remote client is installed on the host.

C:\Program Files\SolarWinds\SolarWinds FSMClient

The following log files are found in either the logs folder or the cpmi folder in the installation directory:

logs\fsm-core.log Primary FSM log file. Always obtain this log file when troubleshooting a problem with FSM
logs\deviceconnector.log Device connector log file. This log file is useful for identifying problems when retrieving device data directly from a device
cpmi\Lea_<Server_IP>\AthenaLogCollector.log Check Point log collector log file. This is useful for debugging problems with collecting log data from Check Point log servers.

3. FSM Workspace Logs

There are a number of different log files contained in the user workspace. The user workspace can be found in the following location if the server is installed on the host:

Win7/Vista/2008

C:\Users\<username>\SolarWinds\SolarWinds FSM Server\workspace

WinXP/2003

C:\Documents and Settings\<username>\SolarWinds\SolarWinds FSM Server\workspace

The user workspace can be found in the following location if the remote client is installed on the host.

Win7/Vista/2008

C:\Users\<username>\SolarWinds\SolarWinds FSM\workspace

WinXP/2003

C:\Documents and Settings\<username>\SolarWinds\SolarWinds FSM\workspace

The following log files are found in the user workspace:

.metadata\.log Primary workspace log file. Always obtain this log file when troubleshooting a problem with FSM. Note: the workspace log file is named ".log" and may appear as an unnamed file if file extensions are not shown.
AthenaCpmiClient.log Check Point CPMI connection log file. This log is useful for identifying problems when connecting to a Check Point management console using the OPSEC CPMI protocol.
<firewall_name>\AthenaCpmiClient.log
<firewall_name>\AthenaCreatePolicy.log Cisco to Check Point Migration log file. These logs are useful for identifying problems when using the Cisco to Check Point Migration feature.

4. FSM Web Service Logs

These logs are generated by the FSM Change Advisor web service. They are similar to many of the logs described above, but since they are associated with the web service instead of a client, they are located in the webservice folder of the installation directory.

C:\Program Files\SolarWinds\SolarWinds FSMServer\webservice

The following log files are found in the webservice folder:

logs\deviceconnector.log Device connector log file for the web service.
logs\fsm-core.log Core log file for the web service.
workspace\.metadata\.log Web service workspace log file.
stderr.log Web service installation log file.

5. FSM License Manager Log

The License Manager log file contains entries relating to the license registration service. This log is useful for identifying problems with the License Manager java service. It is located in the licensemgr folder of the installation directory.

C:\Program Files\SolarWinds\Solar Winds FSMServer\licensemgr\stderr.log

Q19. Is the FSM evaluation limited in functionality?

Yes.

These features are allowed only on the first imported firewall (usually listed in 5th position in the Inventory window, after the 4 example devices, unless the inventory is sorted/reordered)

Structural cleanup (Rule/Object Cleanup -> Redundant and Shadowed rules Analysis)
Security Checks (Audit -> Evaluate security Checks, Compare Security Checks, Assess PCI Compliance, VPN Audit).
Compare security checks in Change Modeling and Impact Monitor is also limited as above.

The Migration & Remove Firewalls features are disabled for all firewalls.

All other functions allowed for all firewalls.

Q20. What is FSM Policy reporting based on?

FSM policy reporting is intended to help achieving optimal firewalling security and is based on all or part of the following standards:

SANS: BS ISO/ IEC 17799:2005
ISO: BS 7799.2:2002
STIG Version 7 Release 1, Version 8 Release 3
IS AUDITING PROCEDURE FIREWALLS DOCUMENT P6
NIST Special Publication 800-41
NSA Report Number:C4-040R-02, Report Number:I33-002R-06, I33-011R-2006
PCI v1.2

Q21: What Firewall Migration scenarios does FSM support?

FSM provides 2 levels of migration capabilities:

Check equivalence between 2 existing configurations from different vendors ("Migrate > Migration Validation"), as an help during a migration scenario.
In this case, the 2 configurations need to be valid configurations, with one of the 2 being the candidate to replace the other one.
This feature will indicate how different the target configuration (migrated to) is, compared to the source one (migrated from).
In this mode, all combinations between supported vendors/types are supported. See an example here
Perform the actual migration from an existing valid configuration to a target configuration from a different vendor.
In this mode the target configuration is initially empty; it will be created by FSM.
This mode supports only Cisco to Checkpoint.

What if a need a migration, different from the one supported (Cisco to Checkpoint)? The recommended procedure is as follows:

Manually convert the source config to target config – first version could be only interfaces, objects, and security rules. Note that this is a manual step that the product does not help with, in a case different from Cisco to Checkpoint migration.
Use source route rules also in target to compare the source and the target. The "Migrate > Migration Validation" report shows differences and what causes differences.
Make judgements as to whether you want to ignore or fix differences.
The report tells you what rules caused the difference (add or delete policy).
Fix the differences.

Q22: I am experiencing issues importing / processing Checkpoint configurations, what should I do?

A typical mistake is to get these files from the FW itself, instead of from the management server.

Getting these files from the devices does not work (they have a different format from the ones, named the same, sitting in the management server)

Recommendations:

Get config files from the management server not the firewall.
In Provider-1 environment, get those files from CMA folder not from MDS folder. If it’s Secure Platform, the CMA folder is usually located at “/opt/CPmds-R<version_number>/customers/<CMA-Name>/” .
Get the files exactly matching the names Objects_5_0.C and rulebases_5_0.fws

More troubleshooting info about importing configs can be found here: Import Troubleshooting

Q23: How does FSM select the firewall IP address reflected in the Inventory window (primary IP) ?

If the firewall is imported from NCM, FSM uses the NCM node primary IP as the primary IP.

If the firewall is imported from other methods, FSM uses the default route interface IP as the primary IP.

If a default route doesn't exist, FSM picks one of the external interface IPs as the primary IP (logic defining which one is not predictable)

The external interface can be determined by the translator as follows, based on the vendor:

- Cisco - an nterface with security level 0. (IOS might be done differently)

- Checkpoint- an interface marked as external

- Juniper - an interfaces assigned to untrusted zone.

The user can also manually assign an external interface in the Interfaces tab of the firewall detail view.

Q24: Is there a backup and restore procedure for the FSM database?

Yes, it's documented here