System Administration

The following tasks help you maintain your SmartEvent system properly:

• Creating objects for use in filters
• Adding additional IPS Event Correlation Units and Log Servers
• Adding objects to the Internal Network
• Creating or modifying custom commands that can be run from the SmartEvent client
• Creating scripts to run as Automatic Reactions for certain events
• Modify the database settings to fit your disk space and requirements

These tasks can be performed from the Policy tab.

Modifications to the Event Policy do not take effect until saved on the SmartEvent server and installed to the SmartEvent Correlation Unit.

To enable changes made to the Event Policy:

1. Click File > Save.
2. Click Actions > Install Event Policy.

You can undo changes to the Event Policy, if they were not saved.

To undo changes: click File > Revert Changes.

Administrator Permissions Profile

You can assign a Permission Profile to an administrator for the SmartEvent database.

Configure Permission Profiles for SmartEvent in the SmartDashboard or SmartDomain Manager connected to the Security Management Server or Multi-Domain Server (SmartDashboard > Manage > Permissions Profiles > New / Edit).

You can configure these permissions:

• None - The administrator cannot see the SmartEvent Events, Reports and Policy tabs.
• Read Only - The administrator can see SmartEvent Events, Reports and Policy tab.
• Read/Write - The administrator can:
  • Use the Ticketing features in the SmartEvent Events and Reports tabs.
  • Configure the SmartEvent Policy tab.
  • Install the Event Policy.
  • Configure one or both of the these options in the Events tab:
    • Exclude from Event Definition
    • Add Exception to Event Definition
• Customized - The administrator has customized access to Check Point products. For each feature, you can choose the permissions to give the administrator.

These customized permissions are available for Events and Reports:

• SmartReporter Policy - Configure Global Properties for SmartReporter.
• SmartReporter - Configure SmartReporter.
• SmartEvent Events Database - See and manage the Events tab of SmartEvent.
• SmartEvent Policy - See and manage the events correlation on the Policy tab of SmartEvent.
• SmartEvent Reports - Users only see the Reports tab.
  • All Blades - This setting applies to all blades.
  • Application Control and URL Filtering Blades - Applies only to the Application Control and URL Filtering blades.

How SmartEvent Authenticates Administrators

When an administrator logs into SmartEvent his user name and password are verified by the SmartEvent Server. If the administrator is not defined on the SmartEvent server, the SmartEvent server attempts the login with the credentials that are defined on the Security Management Server or Multi-Domain Server.

Note - If you do not want to centrally manage administrators, and you only use the local administrator defined for the SmartEvent Server:

From the SmartEvent server command line, invoke:
cpprod_util CPPROD_SetValue FW1 REMOTE_LOGIN 4 1 1

Multi-Domain Security Management

In Multi-Domain Security Management, each Event and Report is related to a Domain. Administrators can see events for Domains according to their permissions.

A Multi-Domain Security Management Policy administrator can be:

• Locally defined administrator on the SmartEvent Server.
• Multi-Domain Server Super User defined on the Multi-Domain Server.
• An administrator with permissions on all Domains. Select the Domains in SmartEvent, in Policy > General Settings > Objects > Domains. This type of administrator can install a Policy, and can see events from multiple Domains.

Modifying the System General Settings

The following tasks help you maintain your SmartEvent system:

• Creating objects for use in filters, as described in Adding Network and Host Objects.
• Adding additional IPS SmartEvent Correlation Unit and Log Servers, as detailed in Defining SmartEvent Correlation Unit and Log Servers
• Adding objects to the Internal Network, as described in Defining the Internal Network
• Creating or modifying custom commands that can be run from the SmartEvent client, as explained in Configuring Custom Commands
• Creating scripts to run as Automatic Reactions for certain events, as detailed in Creating an External Script.

These tasks can be performed from the General Settings page of the Policy tab. The Policy tab is hidden by default, but can be revealed by selecting Policy Tab from the View menu.

Adding Network and Host Objects

Certain objects from the Management server are added during the initial sync with the SmartEvent server and updated at a set interval. But it is useful (or necessary) to add other Network or Host objects, for these reasons:

• If some devices or networks are not represented on the Management server, and are important to define your internal network.
• When you add sources or destinations to exclusions or exceptions in Event Definitions.
• When you select sources or destinations in a filter.

These screens are locked until initial sync is complete:

• Network Objects
• Internal Network
• SmartEvent Correlation Unit

You can make a device available to use in SmartEvent.

To make a device that is a host object available in SmartEvent:

1. From the Policy tab, select General Settings > Objects > Network Objects > Add > Host.
2. Give the device a significant name.
3. Enter its IP Address or select Get Address.
4. Select OK.

To make a device that is a network object available in SmartEvent:

1. From the Policy tab, select General Settings > Objects > Network Objects > Add > Network.
2. Give the network a significant name.
3. Enter the Network Address and Net Mask.
4. Select OK.

See Defining the Internal Network for information about how to add objects to the Internal Network definition.

Defining SmartEvent Correlation Units and Log Servers

The SmartEvent system works with Event Correlation Units that compile event information from Log Servers. Additional Event Correlation Units and their corresponding Log Servers should be configured during the initial system setup.

To define SmartEvent Correlation Unit or Log Servers in SmartEvent:

1. From the Policy tab, select General Settings > Initial Settings > Event Correlation Units.
2. Select Add.
3. Select the […] symbol and select a SmartEvent Correlation Unit from the pop-up window.
4. Select OK.
5. Select Add and select a Domain Log Server available to the SmartEvent Correlation Unit from the pop-up window.
6. Select Save.
7. From the Actions menu, select Install Event Policy.

   Note - The following screens are locked until sync is complete:

   • Network Objects
   • Internal Network
   • SmartEvent Event Correlation Units

To define SmartEvent Event Correlation Units in SmartEvent Intro:

• In a Security Management Server environment: correlation is defined automatically.
• In a Multi-Domain Security Management environment: do the previous procedure on the Multi-Domain Server.

Defining the Internal Network

To help SmartEvent conclude if events originated internally or externally, you must define the Internal Network. These are the options to calculate the traffic direction:

• Incoming – all the sources are external to the network and all destinations are inner
• Outgoing – all sources are in the network and all destinations external
• Internal – sources and destinations are all in the network
• Other – a mixture of and internal and external values makes the result indeterminate

To define the Internal Network:

1. From the Policy tab, select General Settings > Initial Settings > Internal Network.
2. Add internal objects.

   We recommend you add all internal Network objects, and not Host objects.

Some network objects are copied from the Management server to the SmartEvent Server during the initial sync and updated afterwards.

These screens are locked until initial sync is complete:

• Network Objects
• Internal Network
• Correlation Units

Offline Log Files

SmartEvent enables an administrator to view existing logs from a previously generated log file. This feature is designed to enable an administrator to review security threats and pattern anomalies that appeared in the past. As a result, an administrator can investigate threats (for example, unauthorized scans targeting vulnerable hosts, unauthorized legions, denial of service attacks, network anomalies, and other host-based activity) before SmartEvent was installed.

In the same respect, an administrator can review logs from a specific time period in the past and focus on deploying resources on threats that have been active for a period of time but may have been missed (for example, new events which may have been dynamically updated can now be processed over the previous period).

The generation of Offline logs are set in the SmartEvent > Policy tab > General Settings > Initial Settings > Offline Jobs, connected to the Security Management Server or Multi-Domain Server with the following options:

• Add enables you to configure an Offline Log File process.
  • Name acts as a label that enables you to recognize the specific Offline Line log file for future processing. For example, you can create a query according to the Offline Job name. This name is used in Event tab queries to search events that have been generated by this job.
  • Comment contains a description of the Offline Job for edification.
  • Offline Job Parameters:

    SmartEvent Correlation Unit the machine that reads and processes the Offline Logs.

    Log Server the machine that contains the Offline Log files. SmartEvent will query this Log Server to see which log files are available.

    Log File contains a list of available of log files found on the selected Log Server to be processed by the SmartEvent Correlation Unit. In this window you select the log file from which you would like to retrieve historical information.

• Edit enables you to modify the parameters of an Offline Log File process.
• Remove enables you to delete an Offline Log File process.

  Once you Start an Offline Log File process you cannot remove it.

• Start runs the Offline Log File process.

  The results of this process appear in the Events tab and are accessible by the By Job Name query or filter.

• Stop ends the Offline Log Files process.
• Stop does not delete the entire process, it only stops the process at the specific point at which it is selected. The information collected up until the process is stopped will appear in the Events tab.

With the SmartEvent Events Tab you can add offline jobs to query events generated by offline jobs.

To add the offline jobs:

1. Select the Events Tab.
2. Go to Predefined > By Job Name.
3. Double-click By Job Name.

   Every job that appears in this window is an offline job except for All online jobs.

4. Select the job you want the By Job Name to query.
5. Click OK.

Configuring Custom Commands

To add (or edit) custom commands:

1. In the SmartEvent GUI, select Actions > Configure Custom Commands.
2. To add a command, select Add…. (To edit an existing command, highlight the command and select Edit.)
3. Enter the text to appear in the right-click context menu.
4. Enter the command to run, and any arguments.
5. Configure the command to run in a SmartEvent window or in a separate Windows command window.
6. Select whether the command should appear in the context menu only when right-clicking in cells with IP address data.
7. Select OK.

Managing the Event Database

SmartEvent uses an optimization algorithm to manage disk space and other system resources. When the Events database becomes too large, the oldest events are automatically deleted to save space. In addition, events that are more than one year old are also automatically deleted.

For instructions to change maximum period and maximum database size to save past events in the Events database see sk69706

Backup and Restore of the Events Database

The evs_backup utility backs up the SmartEvent configuration files and places them in a compressed tar file. In addition, it backs up data files based upon the options selected. The files can be restored using the evs_backup_extractor script. Enclosed are two script versions, one for Windows that has a .bat suffix and one for Solaris, Linux and SecurePlatform that does not have a suffix but should have the executable permissions set.

Usage:

evs_backup [-filename file.tgz] [-EvaDb] [-EvrDb] [-Results] [-Logs] [-LogoAndScripts]
[-All] [-export] 

Additional options are:

SmartEvent High Availability Environment

The SmartEvent database keeps a synchronized copy of management objects locally on the SmartEvent Server. This process, dbsync, allows SmartEvent to work independently of different management versions and different management servers in a High Availability environment.

Management High Availability capability exists for Security Management Servers, and in a Multi-Domain Security Management environment, dbsync supports High Availability for the Multi-Domain Servers and the Domain Management Servers.

How it works

Dbsync initially connects to the management server with which SIC is established. It retrieves all the objects. After the initial synchronization it gets updates when an object is saved. Dbsync registers all the High Availability management machines and periodically tests the connectivity with the newest management server. If connectivity is lost, it attempts to connect to the other High Availability management servers until it finds an active one and connects to it.

If two management servers are active concurrently, dbsync stays connected to one management server. Dbsync does not get changes made on the other management server until a synchronization operation is done.

Log Server High Availability

In SmartDashboard, you can configure a Security Gateway, that when it fails to send its logs to one Log Server, it will send its logs to a secondary Log Server. To support this configuration, you can add Log Servers to a single SmartEvent Correlation Unit. In this way, the SmartEvent Correlation Unit gets an uninterrupted stream of logs from both servers and continues to correlate all logs.

SmartEvent Correlation Unit High Availability

Multiple correlation units can read logs from the same Log Servers. That way, the units provide redundancy if one of them fails. The events that the correlation units detect are duplicated in the SmartEvent database. But these events can be disambiguated if you filter them with the Detected By field in the Event Query definition. The Detected By field specifies which SmartEvent Correlation Unit detected the event.

If the SmartEvent Server becomes unavailable, the correlation units keep the events until it can reconnect with the SmartEvent Server and forward the events.

Third-Party Device Support

New Device Support

Adding support for a log-generating device (e.g., router, Firewall, IDS, Anti-Virus, OS) to SmartEvent involves one or both of the following:

• Adding the data necessary to translate the device logs to a format that a Check Point Domain Log Server can read. This translation is called parsing, and it involves extracting the relevant log fields from the log data to create a normalized Check Point log available for further analysis.
• Adding the device logs to Event Definitions.

SmartEvent currently supports the following log formats:

• Check Point / OPSEC ELA
• Microsoft Windows Events
• Syslog messages
• SNMP traps

Devices using Check Point, ELA, or Windows Events do not require special parsing configuration. If you are adding a device using one of these formats, skip to the section Adding New Devices to Event Definitions. For details on support for Windows logs, see the section Windows Events.

Devices using the syslog or SNMP format require parsing configuration. Continue to Planning and Considerations and the parsing section relevant for your device.

Parsing Log Files

Planning and Considerations

1. Learn the exact structure of the logs the device generates with the following
   1. The vendor logging guide (if it exists), or any other documentation that specifies the different logs the device can generate and their exact structure. Documentation is important to verify that you have found all possible logs and is usually enough to start writing the parsing file.
   2. Log samples, as many as possible. It is recommended to use real logs generated from the actual devices to be used with SmartEvent. Samples are important for testing the parsing file and tuning it accordingly.
2. Consult the Syslog Parsing guide to become familiar with the Free Text Parsing Language. The document also specifies the relevant parsing files and their location on the Log Server.
3. Decide which fields to extract from the log. While the fields you want to extract differ from one device to another, devices of the same category would usually have similar log fields. For example:

   Device Type	Typical Log Fields
   Firewall, router and other devices that send connection based logs	source IP address, destination IP address, source port, destination port, protocol, accept/reject indication
   IDS / IPS, application Firewall and other devices that send attack logs	attack name/ID

4. It may also be useful to compare existing parsing files of another similar product.

Syslog Parsing

To parse a syslog file:

1. Create a new parsing file called <device product name>.C as specified in the parsing guide, and place it in the directory $FWDIR/conf/syslog/UserDefined on the Domain Log Server.
2. On the Log Server, edit the file $FWDIR/conf/syslog/UserDefined/UserDefinedSyslogDevices.C to add a line that includes the new parsing file. For example:

   : ( :command ( :cmd_name (include) :file_name ("snortPolicy.C") ) )

3. If needed, create a new dictionary file called <device product name>_dict.ini, and place it in the directory $FWDIR/conf/syslog/UserDefined on the Log Server. A dictionary translates values with the same meaning from logs from different devices into a common value. This common value is then used in the Event Definitions.
4. If you have added a new dictionary file, edit the file $FWDIR/conf/syslog/UserDefined/UserDefinedSyslogDictionaries.C on the Log Server and add a line to include the dictionary file. For example:

   :filename ("snort_dict.ini")

To test the parsing, send syslog samples to a Check Point Log Server:

1. Configure the Log Server to accept syslogs by doing one of the following:
   • Using SmartDashboard, connect to the Security Management Server and edit the SmartEvent Server network object: Go to Logs and Masters > Additional Logging Configuration and enable the property Accept Syslog messages.
   • On the Log Server, run syslog –r to register the syslog daemon.
2. After making any change in the parsing file, restart the fwd process on the Log Server (either run the commands cpstop & cpstart, or fw kill fwd & fwd –n)
3. Send syslogs from the device itself, or from a syslog generator, such as Kiwi Syslog Message Generator, available at http://www.kiwisyslog.com/software_downloads.htm#sysloggen, or Adiscon logger, available at http://www.monitorware.com/logger/.

Troubleshooting:

If SmartView Tracker does not display the logs as expected, there may be specific problems with the parsing files:

• If there is a syntax error in the parsing files, an error message will report a failure to read the parsing files. To read a specific error message, set the environment variable TDERROR_ALL_FTPARSER value to 5 before running the process fwd -n.
• If the syslogs are displayed in SmartView Tracker with 'Product syslog', this means the log was not parsed properly, and was parsed as a general syslog.
• If the Product field contains another product (not the one you have just added) this means there is a problem with the other product parsing file. Report this to the Check Point SmartEvent team.
• If the product is reporting correctly in the log, look for all the fields you have extracted. Some of them will be in the Information section. Some fields may only be visible when selecting More Columns.

SNMP Parsing

1. Create a new parsing file called <device product name>.C as specified in the Syslog Parsing guide, and place it in the directory $FWDIR/conf/snmpTrap/UserDefined on the Log Server. In the file, use a switch command for the snmp_trap_to_cp_log_param_id field, so that each case contains OID for a specific log field (OID information may be extracted from the device MIB files, if available)

   To view an example, see the file $FWDIR/conf/snmpTrap/CPdefined/realSecure.C.

2. Edit the file $FWDIR/conf/snmpTrap/UserDefined /UserDefinedSnmpDevices.C to add lines to include the new parsing file. The value of the attribute case should be the appropriate OID for the product. Note that the product OID should contain exactly seven numeric values, separated by decimal points. For example:

   : ( :case ("1.3.6.1.4.1.2499") :command ( :cmd_name (include) :file_name ("realSecure.C") ) )

3. To test the parsing, send SNMP trap samples to a Check Point Log Server:
   1. Configure the Log Server to accept SNMP traps, as follows:
      1. On the Log Server, run the command snmpTrapToCPLog –r to register the SNMP trap daemon.
      2. On the Log Server, run the command snmpTrapToCPLog -a [ip_addr] to add the SNMP trap sender.
   2. Restart the snmpTrapToCPLog process on the Log Server after any change in the parsing file (using cpstop & cpstart or by terminating the snmpTrapToCPLog process and running snmpTrapToCPLog again from the command line)
   3. Send SNMP traps from the device itself, or from a SNMP trap generator like NuDesign Trap Sender, available at http://www.nudesignteam.com).
4. If SmartView Tracker does not display the logs as expected, there may be specific problems with your parsing files:
   1. If there is a syntax error in the parsing files, an error message will report a failure to read the parsing files. To read a specific error message, set the environment variable TDERROR_ALL_SNMP value to 5 before running the process snmpTrapToCPLog.
   2. If the SNMP traps are displayed in SmartView Tracker with 'Product snmp Trap', this means the log was not parsed properly, and was parsed as a general SNMP trap.
   3. If the Product field contains another product (not the one you have just added) this means there is a problem with the other product parsing file. Report this to the Check Point SmartEvent team.
   4. If the product is reporting correctly in the log, look for all the fields you have extracted. Some of them will be in the Information section. Some fields may only be visible when selecting More Columns.

Adding New Devices to Event Definitions

After creating the appropriate parsing file for the new product, the next step is to include the product in the SmartEvent Event Policy by adding it to the Product filters of new and existing events. This involves making changes to the SmartEvent Server database. Some of the changes are accomplished using SmartEvent client, while others require using a CPMI client (such as GuiDBedit or dbedit, or a specific client you can write for your own use).

Step 1: Create an object to represent the new device in one of the following ways:

1. Using the SmartEvent client:
   1. Right click any of the Event Definitions on the Policy tab and select Properties > Filter tab.
   2. From the Product list section, select Add > Add Product.
   3. Enter the product name as it appears in the Product field of the log.
   4. Select OK.
   5. Select OK again.
   6. Select Cancel to exit the dialog.
2. Using another CPMI client:
   1. Enter the class name: eventia_product_object and the table: eventia_products
   2. Set the name and the product_displayed_name & product_name fields, for example:

: (Snort_IDS

		:product_displayed_name ("Snort IDS")

		:product_name ("Snort IDS")

)

The resulting object is added to the file $FWDIR/conf/sem_products.C.

Step 2: Add the device to the relevant Event Definitions:

For example, if this is an IDS / IPS reporting a 'Ping of Death' attack, use the Event Definition Wizard to add a filter for the new product in the 'Ping of Death' Event Definition. You may also add existing or new fields to the product filter by selecting the property Show more fields.

1. Note that Event Definitions cannot be modified, so adding a new filter requires doing one of the following:
   • Saving the relevant Event Definitions as User Defined Events.
   • Overriding this restriction by making a change to the file $FWDIR/conf/sem_detection_policies.C. Use an editor to open the file, search for the line abacus_detection_policy_object, and set the value :user_defined to false.
2. Create new Event Definitions where needed if the requested event is not covered by existing Event Definitions. As in step 2, this is accomplished via the Event Definition Wizard. New Event Definitions appear in the User Defined Events section of the Event Policy tree.

   To move the Event Definition to another section of the tree, do the following:

   1. Use a CPMI client to edit the abacus_detection_policy_object in the table abacus_detection_policies.
   2. Edit the category field.
   3. To verify that the change has been made, view the object abacus_detection_policy_object in the file $FWDIR/conf/sem_detection_policies.C.
3. Consider adding a generic event for the new product (as in the Third Party Devices - User Configured Events section of the Event Policy tree).
   1. Create a new Event Definition based on the new product using the Event Definition Wizard.
   2. Use a CPMI client to edit the abacus_detection_policy_object in the table abacus_detection_policies.
   3. Set the property :create_exception_only for this event to true.
   4. Modify the values of the following fields as desired:
      • exception_rule_static_string_1
      • exception_rule_static_string_2
      • exception_rule_static_string_3
      • static_description_string
      • exception_list_def
      • exception_columns

To test the changes in the Event Definition:

1. Copy the modified files to the directory $FWDIR/conf on the SmartEvent Server.
2. Run cpstop & cpstart on the SmartEvent Server.
3. Close and reopen the SmartEvent client.
4. Assuming the Event Definitions are configured as expected, install Event Policy.
5. Send logs as described in the testing for parsing above, and see the generated events.

Syslog Parsing

Various third-party devices use the syslog format for logging. SmartEvent can parse and process third-party syslog messages by reformatting the raw data. This parsing process extracts relevant log fields from the syslog data and creates a normalized Check Point log which is available for further analysis.

The Parsing Procedure

The procedure occurs on the Log Server and starts with the syslog daemon. The syslog daemon that runs on the Log Server receives the syslogs and calls for their parsing. The parsing involves many parsing files, which contain the different parsing definitions and specifications, and can be found in $FWDIR\conf\syslog\. In these files there are the device-specific parsing files, which define the actual parsing and extraction of fields, according to each device specific syslog format.

The parsing starts with the syslog_free_text_parser.C file. This file defines the different dictionaries and parses the syslog. The file extracts fields which are common to all syslog messages (such as PRI, date and time), and the machine and application that generated the syslog.

syslog_free_text_parser.C uses the allDevices.C file (which refers to two files: UserDefined/UserDefinedSyslogDevices.C and CPdefined/CPdefinedSyslogDevices.C). The first (UserDefined/UserDefinedSyslogDevices.C) contains the names of the devices parsing files that the user defines. The second (CPdefined/CPdefinedSyslogDevices.C) contains devices parsing files that Check Point defines. allDevices.C goes over the device parsing files, and tries to match the incoming syslog with the syslog format parsed in that file.

After the parsing-file succeeds in the preliminary parsing of the syslog (that is, it matches the syslog format and is therefore the syslog origin), the remaining of the syslog is parsed in that file. If a match is not found, the file will continue to go over the Check Point device parsing files until it finds a match.

The Free Text Parsing Language

The free text parsing language enables to parse an input string, extract information, and define log fields. These log fields which show as part of the Check Point log in the Log Server. They are used in the definition of events. Each parsing file contains a tree of commands. Each command examines or parses part of the input string (sometimes it adds fields to the log as a result), and decides if to continue to parse the string (according to the success/failure of its execution).

The Commands

Each command consists of these parts:

• cmd_name - the name of the command.
• command arguments - arguments that define the behavior of the command.
• on_success (optional) - the next command executed if the current command execution succeeds.
• on_fail (optional) - the next command executed if the current command execution fails.

Sample

Try

The try command matches a regular expression against the input string.

Try Command Parameters

Try Command Sample

In the above example, we try to match the regular expression ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) that looks at the entire log (parse_from (start_position)) - parse from the start of the log). If the regular expression is matched, we add a source field.

Group_try

The command group_try executes one or more commands in one of these modes:

• try_all tries all commands in the group, and ignores the return code of the commands.
• try_all_successively tries all the commands in the group, and ignores the return code of the commands.

  Each command tries to execute from the last position of the earlier successful command.

• try_until_success tries all the commands until one succeeds.
• try_until_fail tries all the commands until one fails.

The command group_try is commonly used when it parses a "free-text" piece of a log, which contains a number of fields we want to extract. For example:

%PIX-6-605004: Login denied from 194.29.40.24/4813 to outside:192.168.35.15/ssh for user 'root'

When you look at see this section of the log, you can use this structure:

Group_try Command Sample 1

In this example, the first try command in the group_try block (for the source) is executed.

If the source, destination and user are not in a specified sequence in the syslog, use the try_all mode instead of try_all_successively.

Group_try Command Sample 2

In this example, the regular expressions in the different commands try to match more specified logs. At most, one command in the group_try block will be successful. When it is found, it is not necessary to examine the others:

Note - When you add a new device, the first try command in the parsing file must use the try until success parameter:

:cmd_name (group_try)
:mode (try_until_success)
: (
….
)

Switch

This command enables to compare the result of a specified field against a list of predefined constant values.

Switch Command Parameters

Switch Command Sample

Unconditional _try

This command is an "empty" command that allows you to add fields to the result without any conditions.

Unconditional _try Command Sample 1

A common usage of unconditional_try is with the switch command. In example 2, each message ID is attached with its corresponding message field which denotes its meaning.

Unconditional _try Command Sample 2

Include

This command enables the inclusion of a new parsing file.

Include Command Sample

add_field

Each add_field has some parameters:

• Type - The type of the add_field command. This parameter has these possible values:
  • Index - Part of the regular expression will be extracted as the field. The field_index value denotes which part will be extracted (see field_index bullet).
  • Const - Add a constant field whose value does not depend on information extracted from the regular expression. See field_value bullet.

Field_name - the name of the new field. There are some fields, which have corresponding columns in SmartConsole Logs & Monitor > Logs. This table shows the names to give these fields to show in their Logs & Monitor > Logs column (and not in the Information field, where other added fields appear):

When you name the above fields accordingly, they are placed in their correct column in Logs & Monitor > Logs. This enables them to participate in all filtering done on these columns. These fields automatically take part in existing event definitions with these field names.

Field_type - the type of the field in the log. This table shows the possible field types.

The field type of the field names in this table must be as mentioned:

• field_index or field_value - The parameter used depends on the value of the "type" field. If it is index, field_index shows. If it is const, field_value shows.

  field_index denotes which part of the regular expression is extracted, according to the grouping of the patterns. To make this grouping, write a certain expression in brackets. In this expression, the number in field_index denotes the bracket number whose pattern is taken into account.

Add_field Command Sample

:command (
     :cmd_name (try)
     :parse_from (last_position)
     :regexp ("Failed password for ([a-zA-Z0-9]+) from
([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) port ([0-9]+)")
     :add_field (
        :type (index)
        :field_name (User)
        :field_type (string)
        :field_index (1)
     )
     :add_field (
        :type (index)
        :field_name (Src)
        :field_type (ipaddr)
        :field_index (2)
     )
     :add_field (
        :type (index)
        :field_name (port)
        :field_type (port)
        :field_index (3)
     )
)

The pattern for the User, [a-zA-Z0-9]+, is located in the first pair of brackets. Therefore, the field_index is one. The pattern for the Source address, [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+, is located in the second pair of brackets. Therefore, the index is two. The pattern for the port is in the third pair of brackets.

In each parsed regular expression the maximum number of brackets must be up to nine. To extract more than nine elements from the regular expression, break the expression into two pieces. The first regular expression contains the first nine brackets. The remaining of the regular expression is in the on_success command.

:command (
          :cmd_name (try)
          :parse_from (start_position)
          :regexp ("access-list (.*) (permitted|denied|est-allowed)
([a-zA-Z0-9_\([a-zA-Z0-9_\\.[0-9]+\.[0-9]+\.[0-9]+)\(([0-9]*)\) -> ")
          :add_field (
                   :type (index)
                   :field_name (listID)
                   :field_type (string)
                   :field_index (1)
          )
          :add_field (
                   :type (index)
                   :field_name (action)
                   :field_type (action)
                   :field_index (2)
          )
          :add_field (
                   :type (index)
                   :field_name (proto)
                   :field_type (protocol)
                   :field_index (3)
          )
          :add_field (
                   :type (index)
                   :field_name (ifname)
                   :field_type (ifname)
                   :field_index (4)
          )
          :add_field (
                   :type (index)
                   :field_name (Src)
                   :field_type (ipaddr)
                   :field_index (5)
          )
          :on_success (
                   :command (
                             :cmd_name (try)
                             :parse_from (last_position)
                             :regexp
("([a-zA-Z0-9_\\.[0-9]+\.[0-9]+\.[0-9]+)\(([0-9]*)\) hit-cnt ([0-9]+) ")
                             :add_field (
                                      :type (index)
                                      :field_name (destination_interface)
                                      :field_type (string)
                                      :field_index (1)
                             )
                   )
          )
)

field_value is the constant value to be added.

:command (
      :cmd_name (try)
      :parse_from (last_position)
      :regexp ("%PIX-([0-9])-([0-9]*)"))
      :add_field (
             :type (const)
             :field_name (product)
             :field_type (string_id)
             :field_value ("CISCO PIX")
      )
)

Dict_name is the name of the dictionary to use to convert the value. If the value is not found in the dictionary, the value is the result. See Dictionary.

Dictionary

The free text parser enables us to use dictionaries to convert values from the log. These conversions are used to translate values from logs from different devices, with the same meaning, into a common value, which is used in the event definitions.

Each dictionary file is defined as an .ini file. In the ini file the section name is the dictionary name and the values are the dictionary values (each dictionary can include one or more sections).

[dictionary_name]

Name1 = val1

Name2 = val2

cisco_action]          [3com_action]

permitted = accept      Permit    = accept

denied = reject         Deny      = reject

Dictionary Sample

The reference to a dictionary in the parsing file is shown in this table:

Dictionary Command Sample 2

Administrator Support for WinEventToCPLog

WinEventToCPLog uses Microsoft APIs to read events from Windows operating system event files. To see these files, use the Windows Event Viewer.

WinEventToCPLog can read event files on the local machine, and can read log files from remote machines with the right privileges. This is useful when you make a central WinEventToCPLog server that forwards multiple Window hosts events to a Check Point Log server.

To set the privileges, invoke WinEventToCPLog -s to specify an administrator login and password.

These are the ways to access the files on a remote machine:

• To define a local administrator on the remote machine that their name matches the name registered with WinEventToCPLog.
• To define the administrator registered with WinEventToCPLog as an administrator in the domain. This administrator can access all of the machines in the domain.