Working with SNMP Management Tools

In This Section: The Need to Support SNMP Management Tools The Check Point Solution for SNMP Special Consideration for the Unix SNMP Daemon Configuring Security Gateways for SNMP Working with SNMP Monitoring Thresholds

The Need to Support SNMP Management Tools

SNMP management tools are used to monitor the activity of various devices on the network. Because system administrators prefer to work with familiar tools, they might be more comfortable getting status information for Check Point products with their regular SNMP Network Management Station (NMS).

The Check Point Solution for SNMP

Check Point addresses this issue by running SNMP agents on Security Gateways. These Security Gateways need to respond to requests from an SNMP Management Station.

In the standard client-server relationship, the network SNMP Management Station is the client and the SNMP agent within the Check Point product acts as the server.

Understanding the SNMP MIB

SNMP management systems consist of an SNMP management station and the managed devices, such as bridges, routers, or network servers. SNMP agents constitute the software elements that interface with the device being managed. The agents relate to the configuration and performance characteristics of a managed device as separate identifiable objects. These objects are arranged in an hierarchical namespace, a tree-like database structure known as a Management Information Block, or MIB. Check Point has a registered MIB sub-tree with the Internet Assigned Numbers Authority (IANA). The MIB:

1. Gives structure to the data in the registered Check Point tree, assigning a unique number to a Check Point Security Gateway. The number, a string of integers separated by decimal points, is the OID or Object Identifier.
   • For Check Point, the root of the registered Object Identifier (OID) is 1.3.6.1.4.1.2620. The notation is: Check point OBJECT IDENTIFIER:: ={enterprises 2620}. For example, the MIB on the management station resolves a string such as 1.3.6.1.4.1.2640.1.1 to: iso.org.dod.internet.private.enterprises.checkpoint.products.fw.
   • The object definitions for Check Point are located in the Check Point MIB. The Check Point MIB can be read by any third party SNMP Management Station once the MIB has been imported.
2. Provides name resolution, resolving the OID integer string to a user-friendly name. For example, if an administrator wants to know the version number of a particular firewall, the administrator selects "version number" as the property of the managed device and the MIB maps "version number" to an integer string before sending the information request to the agent.

   Note - The SNMP management station can read but not modify the object definitions for Check Point products.

Handling SNMP Requests on Windows

When the Security Management server is installed, a special Check Point dynamic link library (DLL) is listed in the Windows registry. The SNMP service running on the Operating System loads this DLL. The SNMP service listens in the standard way on port 161 for incoming SNMP requests from the SNMP Network Management Station. The Check Point DLL extends the Windows SNMP service to identify those status requests directed at Check Point products. The relevant data is then retrieved by the DLL and sent to the SNMP management station.

Note - The Check Point SNMP agent is an extension of the Windows SNMP agent. If you have not installed the standard Windows SNMP agent, you cannot use the Check Point SNMP agent.

Handling SNMP Requests on Unix

For the Unix platform, a special Check Point SNMP daemon, called cpsnmpd, is installed. This daemon provides status information on Check Point specific objects. This daemon is not run by default. The daemon is enabled or disabled through cpconfig. Once enabled, the daemon runs with other Check Point processes. The SNMP Network Management Station queries the daemon for status information. The daemon retrieves the information, and replies.

Note - While the Check Point daemon is SNMP compliant, the daemon listens on port 260 instead of 161. The standard Unix SNMP daemon loads before the Check Point daemon and binds to port 161. If the regular daemon is not running, cpsnmpd binds to both ports (161 and 260). If both ports are occupied by a previous process, the Check Point daemon will not run. Further, if the Check Point daemon receives a request for an unrecognized OID, it does not forward this to the standard SNMP Unix daemon.

Handling SNMP Requests

SNMP support is fully integrated in SecurePlatform:

• Net-SNMP Support for full OS-MIB-II.
• Monitoring of Check Point Status Information (AMON) through SNMP.
• SNMP V.2 and V.3 Support.

For additional information about SNMP and SecurePlatform refer to the SNMP Support section in the R77 SecurePlatform Administration Guide.

SNMP Traps

While Check Point has Alert as one of its tracking types, you might prefer to receive alert messages through your regular SNMP Management Station in the form of an SNMP trap. An SNMP trap is notification that a certain event has occurred. Check Point offers SNMP traps as one of its tracking types. When the conditions of the trap are met, the gateway sends a log to Security Management. Security Management saves the log and sends (via port 162) an SNMP trap to the configured catcher—the SNMP Network Management station. The trap includes the text of the log file.

For example, if any machine outside of the organization tries to make an http connection to a machine within the internal network, the packet is dropped and an SNMP trap is sent:

Source	Destination	VPN	Service	Action	Track
Any	Internal_private_network	Any	HTTP	Drop	SnmpTrap

The Check Point MIB file describes the SNMP traps that are used by Security Management. The MIB file is located in:

• Windows - %CPDIR%\lib\snmp\chkpnt-trap.mib
• Other OS - $CPDIR/lib/snmp/chkpnt-trap.mib

Special Consideration for the Unix SNMP Daemon

If you need to run the standard Unix SNMP daemon on port 161, run this daemon before you start cpsnmpd, otherwise cpsnmpd will take the port.

Configuring Security Gateways for SNMP

To handle SNMP requests and traps, the various supported platforms need to be configured in slightly different ways.

Configuring Security Gateways for SNMP Requests

1. On the SNMP Management Station, import the Check Point MIB file from $CPDIR/lib/snmp/chkpnt.mib.
2. If the platform is Windows NT, verify that the Operating System is running the SNMP service. On the Unix platform, verify that port 260 is not bound to another process. If port 260 is available, run cpconfig to enable the cpsnmpd daemon.
3. In the Security Policy Rule Base:
   • Open port 161 if the platform is Windows NT.
   • Open port 260 if the platform is Unix.

   Do this only on the Security Gateways through which the SNMP packets need to pass.

   Source	Destination	If Via	Service	Action
   SNMP_Management_Station	Firewall_Modules	Any	snmp	accept

   This policy rule allows the SNMP Management Station to communicate with the Security Gateways.

4. Install the new Security Policy.

Configuring Security Gateways for SNMP Traps

To configure Security Gateways for SNMP traps, the built-in trap script has to be assigned an appropriate catcher.

To assign an appropriate catcher:

1. Open the Global Properties window, Alerts page.
2. Select the Run SNMP trap alert script option.
3. In the corresponding text box, replace internal_snmp_trap localhost with internal_snmp_trap <snmp_trap_catcher>, where the <variable> is replaced with the name of the configured catcher. For example, if the configured catcher is a machine called Alaska, the new script would read internal_snmp_trap Alaska.

   

4. For the relevant rules in the Security Policy Rule Base, set the tracking type to snmp_trap.
5. If Security Management server and the SNMP Management Station do not reside on the same network segment, open port 162 on all Security Gateways between them. This will allow SNMP traps to pass through.
6. Install the Security Policy.

Working with SNMP Monitoring Thresholds

You can configure a variety of different SNMP thresholds that generate SNMP traps, or alerts. You can use these thresholds to monitor many system components automatically without requesting information from each object or device. The categories of thresholds that you can configure include:

• Hardware
• High Availability
• Networking
• Resources
• Domain Log Server Connectivity

Some categories apply only to some machines or deployments.

Note - SNMP monitoring thresholds are supported from R75.20, R71.30, and higher.

In each category there are many individual thresholds that you can set. For example, the hardware category includes alerts for the state of the RAID disk, the state of the temperature sensor, the state of the fan speed sensor, and others. For each individual threshold, you can configure:

• If it is enabled or disabled
• How frequently alerts are sent
• The severity of the alert
• The threshold point (if necessary)
• Where the alerts are sent to

You can also configure some settings globally, such as how often alerts are send and where they are sent to.

Types of Alerts

• Active alerts are sent when a threshold point is passed or the status of a monitored component is problematic.
• Clear alerts are sent when the problem is resolved and the component has returned to its normal value. Clear alerts look like active alerts but the severity is set to 0.

Configuring SNMP Monitoring

Configure the SNMP monitoring thresholds in the command line of the Security Management server. When you install the policy on the gateways the SNMP monitoring thresholds are applied globally to all gateways.

Configuring in Multi-Domain Security Management

In a Multi-Domain Security Management environment, you can configure thresholds on the Multi-Domain Server and on each individual Domain Management Server. Thresholds that you configure on the Multi-Domain Server are for the Multi-Domain Server only. Thresholds that you configure for a Domain Management Server are for that Domain Management Server and its gateways. If a threshold applies to the Multi-Domain Server and the Domain Management Server gateways, set it on the Multi-Domain Server and Domain Management Server. But in this situation you can only get alerts from the Multi-Domain Server if the threshold passed.

For example, because the Multi-Domain Server and Domain Management Server are on the same machine, if the CPU threshold is passed, it applies to both of them. But only the Multi-Domain Server generates alerts.

You can see the Multi-Domain Security Management level for each threshold with the threshold_config utility.

• If the Multi-Domain Security Management level for a threshold is Multi-Domain Server: Alerts are generated for the Multi-Domain Server when the threshold point is passed.
• If the Multi-Domain Security Management level for a threshold is Multi-Domain Server and Domain Management Server: Alerts are generated for the Multi-Domain Server and Domain Management Servers separately when the threshold point is passed.

Configuring a Local Gateway Policy

You can configure SNMP thresholds locally on a gateway with the same procedure that you do on a Security Management server. But each time you install a policy on the gateway, the local settings are erased and it reverts to the global SNMP threshold settings.

You can use the threshold_config utility to save the configuration file and load it again later.

On SecurePlatform and Linux, the configuration file that you can back up is: $FWDIR/conf/thresholds.conf

On Windows, the configuration file that you can back up is: %FWDIR%\conf\thresholds.conf

Completing the Configuration

You can complete threshold configuration and activate the settings.

To complete configuration and activate the settings:

1. On the Security Management server, install the policy on all Security Gateways.
2. For a local Security Gateway threshold policy or a Multi-Domain Security Management Multi-Domain Server environment, use the cpwd_admin utility to restart the CPD process:
   1. Run: cpwd_admin stop -name CPD -path "$CPDIR/bin/cpd_admin" -command "cpd_admin stop"
   2. Run: cpwd_admin start -name CPD -path "$CPDIR/bin/cpd" -command "cpd"

Configuration Procedures

There is one primary command to configure the thresholds in the command line, threshold_config. You must be in the Expert mode to run it. After you run threshold_config, follow the on-screen instructions to make selections and configure the global settings and each threshold.

When you run threshold_config, you get these options:

• Show policy name - Shows you the name configured for the threshold policy.
• Set policy name - Lets you set a name for the threshold policy.
• Save policy- Lets you save the policy.
• Save policy to file - Lets you export the policy to a file.
• Load policy from file - Lets you import a threshold policy from a file.
• Configure global alert settings - Lets you configure global settings for how frequently alerts are sent and how many alerts are sent.
• Configure alert destinations - Lets you configure a location or locations where the SNMP alerts are sent.
• View thresholds overview - Shows a list of all thresholds that you can set including: the category of the threshold, if it is active or disabled, the threshold point (if relevant), and a short description of what it monitors.
• Configure thresholds - Opens the list of threshold categories to let you select thresholds to configure.

Configure Global Alert Settings

If you select Configure global alert settings, you can configure global settings for how frequently alerts are sent and how many alerts are sent. You can configure these settings for each threshold. If a threshold does not have its own alert settings, it uses the global settings by default.

You can configure these options:

• Enter Alert Repetitions - How many alerts are sent when an active alert is triggered. If you enter 0, alerts are sent until the problem is fixed.
• Enter Alert Repetitions Delay - How long the system waits between it sends active alerts.
• Enter Clear Alert Repetitions - How many clear alerts are sent after a threshold returns to a regular value.
• Enter Clear Alert Repetitions Delay - How long the system waits between it sends clear alerts.

Configure Alert Destinations

If you select Configure Alert Destinations, you can add and remove destinations for where the alerts are sent. You can see a list of the configured destinations. A destination is usually an NMS (Network Management System) or a Check Point Domain Log Server.

After you enter the details for a destination, the CLI asks if the destination applies to all thresholds.

• If you enter yes, alerts for all thresholds are sent to that destination, unless you remove the destination from an individual threshold.
• If you enter no, no alerts are sent to that destination by default. But for each individual threshold, you can configure the destinations and you can add destinations that were not applied to all thresholds.

For each threshold, you can choose to which of the alert destinations its alerts are sent. If you do not define alert destination settings for a threshold, it sends alerts to all of the destinations that you applied to all thresholds.

For each alert destination enter:

• Name - An identifying name.
• IP - The IP address of the destination.
• Port - Through which port it is accessed
• Ver - The version on SNMP that it uses
• Other data- Some versions of SNMP require more data. Enter the data that is supplied for that SNMP version.

Configure Thresholds

If you select Configure thresholds, you see a list of the categories of thresholds, including:

• Hardware
• High Availability
• Networking
• Resources
• Domain Log Server Connectivity

Some categories apply only to some machines or deployments. For example, Hardware applies only to Check Point appliances and High Availability applies only to clusters or High Availability deployments.

Select a category to see the thresholds in it. Each threshold can have these options:

• Enable/Disable Threshold - If the threshold is enabled, the system sends alerts when there is a problem. If it is disabled it does not generate alerts.
• Set Severity - You can give each threshold a severity setting. The options are: Low, Medium, High, and Critical. The severity level shows in the alerts and in SmartView Monitor. It lets you know quickly how important the alert is.
• Set Repetitions - Set how frequently and how many alerts will be sent when the threshold is passed. If you do not configure this, it uses the global alert settings.
• Set Threshold Point - Enter the value that will cause active alerts when it is passed. Enter the number only, without a unit of measurement.
• Configure Alert Destinations - See all of the configured alert destinations. By default, active alerts and clear alerts are sent to the destinations. You can change this for each destination. When you select the destination you see these options:
  • Remove from destinations - If you select this, alerts for this threshold are not sent to the selected destination.
  • Add a destination - If you configured a destination in the global alert destinations but did not apply it to all thresholds, you can add it to the threshold.
  • Disable clear alerts - Cleared alerts for this threshold are not sent to the selected destination. Active alerts are sent.

Monitoring SNMP Thresholds

You can see an overview of the SNMP thresholds that you configure in SmartView Monitor.

To see an overview of the SNMP thresholds:

1. Open SmartView Monitor and select a Security Gateway.
2. In the summary of the Security Gateway data that open in the bottom pane, click System Information.
3. In the new pane that opens, click Thresholds.

   In the pane that opens, you can see these details:

   • General Info - A summary of the total SNMP Threshold policy.
     • Policy name- The name that you set for the policy in the CLI.
     • State - If the policy is enabled or disabled.
     • Thresholds - How many thresholds are enabled.
     • Active events - How many thresholds are currently sending alerts.
     • Generated Events - How many not active thresholds became active since the policy was installed.
   • Active Events- Details for the thresholds that are currently sending alerts.
     • Name - The name of the alert (given in the CLI).
     • Category - The category of the alert (given in the CLI), for example, Hardware or Resources.
     • MIB object - The name of the object as recorded in the MIB file.
     • MIB object value - The value of the object when the threshold became active, as recorded in the MIB file.
     • State - The status of the object: active or clearing (passed the threshold but returns to usual value).
     • Severity - The severity of that threshold, as you configured for it in the CLI.
     • Activation time - When was the alert first sent.
   • Alert Destinations - A list of the destinations that alerts are sent to.
     • Name - The name of the location.
     • Type - The type of location. For example, a Domain Log Server or NMS.
     • State - If logs are sent from the gateway or Security Management server to the destination machine.
     • Alert Count - How many alerts were sent to the destination from when the policy started.
   • Errors - Shows thresholds that cannot be monitored. For example, the Security Gateway cannot monitor RAID sensors on a machine that does not have RAID sensors. Therefore it shows an error for the RAID Sensor Threshold.
     • Threshold Name - The name of the threshold with an error.
     • Error - A description of the error.
     • Time of Error - When the error first occurred.