Print Download PDF Send Feedback



Alternative Methods to add and delete SNORT Protection Rules

These alternative methods on the Management Server let you can add and delete SNORT protection rules:

Adding SNORT Rules

The applicable command accepts two arguments:

The command returns:

Upon success:


Upon failure:

1 along with several parameters describing the error upon failure


The server returns:

Upon success:

Status code 200

Upon failure:

The appropriate status code


POST {{server}}/v1.2/add-threat-protections

Content-Type: application/json

X-chkp-sid: {{session}}


"package-path" : "/path/to/community.rules",

"package-format" : "snort"


Deleting SNORT Protections

The applicable command accepts one argument "package-format", which always takes the string value "snort".

The command returns:

Upon success:


Upon failure:

1 along with several parameters describing the error upon failure


With the request headers Content-Type set to application/json and X-chkp-sid set to the unique session identifier returned by the login request. The argument package-format must be sent in the request body.

The server returns:

Upon success:

Status code 200

Upon failure:

The appropriate status code


POST {{server}}/v1.2/delete-threat-protections

Content-Type: application/json

X-chkp-sid: {{session}}


"package-format" : "snort"


Creating SNORT Rule Files

You can write your own SNORT rules and then import them to a Check Point Management Server to become IPS protections . For more information about SNORT, see

Check Point supports SNORT 2.9 version and lower.

SNORT rules use signatures to define attacks. A SNORT rule has a rule header and rule options.

The name of the imported SNORT protection is the value of the msg field in the original SNORT rule.

SNORT Rule Syntax:

<Action> <Protocol> <Address> <Port> <Direction> <Address> <Port> (msg:"<Text>"; <Keyword>:"<Option>";)

SNORT rules have two logical parts: Rule Header and Rule Options.

<Action> <Protocol> <Address> <Port> <Direction> <Address> <Port>



alert tcp any any -> any any (msg:"Possible exploit"; content:"|90|";)


Supported Snort syntax:

These are the generally supported syntax components. There are some limitations.




Specifies the original length of the content that is specified in a protected_content rule digest


Lets you write rules with Perl-compatible regular expressions.


alert tcp any any -> any 80 (content:"/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)


Lets rules track states during a transport protocol session. Used in conjunction with conversation tracking from the Session preprocessor.


alert tcp $HTTP_SERVERS any -> $EXTERNAL_NET 21 (msg: "Does not match state in FTP path"; flow: established, to_server; content: "targetfile"; nocase; fast_pattern; flow bits: isset,INFTPPATH;no_match;)


Tests a byte field for a specific value (with operator).


alert udp $EXTERNAL_NET any -> $HOME_NET 123 (msg: "Header length longer than maximum"; content: "length|3d|"; byte_test: 4, >, 1024, 1, relative;)


Lets you write rules that skip over specific portions of the length-encoded protocols and perform detection in very specific locations.


alert udp any any -> any 123 (msg: "Check for 0001 after 0123"; content: "|30 31 32 33|"; byte_jump: 4,4, relative; content: "|30 30 30 31|"; distance: 1; relative;)


Verifies that the payload has data at a specified location.


alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg: "\r\n\r\nHas 300 byte after"; flow: established, to_server; content: "|0a 0d 0a 0d|"; isdataat: 300,relative; sid:11111111;)


Does not block traffic even if the rule matches. Used with the “flow bits” key word to set a flag without performing a block.


alert tcp $HTTP_SERVERS any -> $EXTERNAL_NET 21 (msg: "Does not match state in FTP path"; flow: established, to_server; content: "targetfile"; nocase; fast_pattern; flow bits: isset,INFTPPATH;no_match; sid: 55555555;)


The $FWDIR/log/SnortConvertor.elg file on the Management Server contains is updated with the debug messages from the last SnortConvertor run import of SNORT rules.

To find failed rule debugs in this file, search for: Failed to convert rule

Unsupported SNORT Syntax

This syntax is not supported and will not convert:

The conversion will change the behavior of these macros and syntax.

These combinations of keywords and modifiers are implemented differently in the IPS blade as Snort protection rules than in SNORT Rules. Best Practice - Test them before activating them in a production environment.

Optimizing IPS

IPS is a robust solution which protects your network from threats. Implementation of the recommendations in this chapter will help maintain optimal security and performance.

During the tuning process, keep in mind that Check Point bases its assessment of performance impact and severity on an industry standard blend of traffic, which places greater weight on protocols such as HTTP, DNS, and SMTP. If your network traffic has high levels of other network protocols, you need to take that into consideration when you assess the inspection impact on the gateway or severity of risk to an attack.

Managing Performance Impact

A Check Point Security Gateway performs many functions in order to secure your network. At times of high network traffic load, these security functions may weigh on the gateway's ability to quickly pass traffic. IPS includes features which balance security needs with the need to maintain high network performance.

Bypass Under Load

To help you integrate IPS into your environment, enable Bypass Under Load on the Gateway to disengage IPS activities during times of heavy network usage. IPS inspection can make a difference in connectivity and performance. Usually, the time it takes to inspect packets is not noticeable, but under heavy loads it may be a critical issue. IPS allows traffic to pass through the gateway without inspection, and IPS then resumes inspection after gateway's resources return to acceptable levels.

Best Practice - Because IPS protections are temporarily disabled, apply Bypass Under Load only during the initial deployment of Threat Prevention. After you optimize the protections and performance of your Gateway, disable this feature to make sure that your network is protected against attacks.

To bypass IPS inspection under heavy load:

  1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

    The gateway window opens and shows the General Properties page.

  2. From the navigation tree, click IPS.
  3. Select Bypass IPS inspection when gateway is under heavy load.
  4. To set logs for activity while IPS is off, in the Track drop-down list, select a tracking method.
  5. To configure the definition of heavy load, click Advanced.
  6. In the High fields, provide the percentage of CPU Usage and Memory Usage that defines Heavy Load, at which point IPS inspection will be bypassed.
  7. In the Low fields, provide the percentage of CPU Usage and Memory Usage that defines a return from Heavy Load to normal load.
  8. Click OK to close the Gateway Load Thresholds window.
  9. Click OK.
  10. Install Policy.

Tuning Protections

This section shows you how to tune protections to suit your needs.

IPS Policy Settings

The IPS Policy settings allow you to control the entire body of protections by making a few basic decisions. Activating a large number of protections, including those with low severity or a low confidence level, protects against a wide range of attacks, but it can also create a volume of logs and alerts that is difficult to manage. That level of security may be necessary for highly sensitive data and resources; however it may create unintended system resource and log management challenges when applied to data and resources that do not require high security.

Best Practice - adjust the IPS Policy settings to focus the inspection effort in the most efficient manner. Once system performance and log generation reaches a comfortable level, the IPS Policy settings can be changed to include more protections and increase the level of security. Individual protections can be set to override the IPS Policy settings.

For more information on IPS Policy, see Automatically Activating Protections.

Note - A careful risk assessment should be performed before disabling any IPS protections.

Focus on High Severity Protections

IPS protections are categorized according to severity. An administrator may decide that certain attacks present minimal risk to a network environment, also known as low severity attacks. Consider turning on only protections with a higher severity to focus the system resources and logging on defending against attacks that pose greater risk.

Focus on High Confidence Level Protections

Although the IPS protections are designed with advanced methods of detecting attacks, broad protection definitions are required to detect certain attacks that are more elusive. These low confidence protections may inspect and generate logs in response to traffic that are system anomalies or homegrown applications, but not an actual attack. Consider turning on only protections with higher confidence levels to focus on protections that detect attacks with certainty.

IPS Network Exceptions can also be helpful to avoid logging non-threatening traffic.

Focus on Low Performance Impact Protections

IPS is designed to provide analysis of traffic while maintaining multi-gigabit throughput. Some protections may require more system resources to inspect traffic for attacks. Consider turning on only protections with lower impact to reduce the amount system resources used by the gateway.

Enhancing System Performance

Performance Pack

Check Point Performance Pack improves gateway performance. For more information on how to optimize network performance, see the R80.10 Performance Tuning Administration Guide.


For SecurePlatform gateways running on multi-core hardware, installing CoreXL on the gateway will allow the gateway to leverage the multiple cores to more efficiently handle network traffic. For more information on CoreXL and optimizing the CoreXL configuration, see the R80.10 Performance Tuning Administration Guide.

Using the Whitelist

Whitelist is a list of files that are trusted. Check Point Threat Prevention engine does not inspect trusted files for malware, viruses, and bots, which helps decrease resource utilization on the gateway.

Adding a File to the Whitelist

To configure files on the Threat Prevention Whitelist:

  1. In SmartConsole, click Security Policies > Threat Prevention > Policy > Threat Tools > Whitelist Files.
  2. Click New.

    The Whitelist File window opens.

  3. Enter the Object Name and MD5 signature for the new file exception.

    Note - To edit or remove Whitelist files, right-click the file and select the applicable option.

  4. Click OK.
  5. Install the Threat Prevention policy.

Threat Indicator Settings

Threat Indicators lets you upload Indicator files that contain sets of observables. These observables are added to the Threat Prevention policy.

Indicator – Set of observables which represent a malicious activity in an operational cyber domain, with relevant information on how to interpret it and how to handle it.

Observable – An event or a stateful property that can be observed in an operational cyber domain. For example: IP address, MD5 file signature, URL, Mail sender address.

Indicators of Compromise convey an attack campaign by:

Indicators are derived from intelligence, self-analysis and/or governments, partners etc.

To use Threat Indicators:

Indicator files must be in CSV or STIX XML format, and contain records of equal size. If an Indicator file has records which do not have the same number of fields, it will not load.

Each record in the Indicator file has these fields:



Valid Values

Value Criteria



Name of the observable

Free text

Must be unique



A value that is valid for the type of the observable

See the table below

See the table below



Type of the observable

  • URL
  • Domain
  • IP
  • IP Range
  • MD5
  • Mail-subject
  • Mail-from
  • Mail-to
  • Mail-cc
  • Mail-reply-to

Not case sensitive



Degree of confidence the observable presents

  • low
  • medium
  • high
  • critical

Default - high



Degree of threat the observable presents

  • low
  • medium
  • high
  • critical

Default - high



Check Point Software Blade that processes the observable

  • AV
  • AB

AV - Check Point Anti-Virus Software Blade (default)

AB - Check Point Anti-Bot Software Blade

Note - only the Anti-Virus Software Blade can process MD5 observables.




Free text



Notes -

  • If an optional field is empty, the default value is used.
  • If a mandatory field is empty, the Indicator file will not load.

These are the values that are valid for each observable type:

Observable Type

Validation Criteria


Any valid URL


Any URL domain


Standard IPv4 address

IP Range

A range of valid IPv4 addresses, separated by a hyphen: <IP>-<IP>


Any valid MD5


Any non-empty text string





Can be one of these:

  • A single email address (Example:
  • An email domain (Examples: or

Requirements for validation of CSV Indicator files:

Notes -

Example of a CSV Indicator File

#! DESCRIPTION = indi file,,,,,,

"#! REFERENCE = Indicator Bulletin; Feb 20, 2014",,,,,,

# FILE FORMAT:,,,,,,

"# All lines beginning ""#"" are comments",,,,,,

"# All lines beginning ""#!"" are metadata read by the SW",,,,,,


Invitation Letter Guests.doc

NOTE:FWS type Flash file


IPV4ADDR:|NOTE:Embedded EXE Remote C&C and Encoded Data





observ15,,IP,medium,medium,AV,TCP:443|NOTE:Related to Flash

observ16,,mail-to,,high,AV,"NOTE:truncated; samples have appended to
the subject the string ""PH000000NNNNNNN"" where NNNNNNN is a varying number"






Example of a STIX 1.0 XML Indicator File











xsi:schemaLocation=" ../stix_core.xsd ../indicator.xsd ../stix_default_vocabularies.xsd ../cybox/objects/File_Object.xsd ../cybox/cybox_default_vocabularies.xsd"




<stix:Title>Example file watchlist</stix:Title>

<stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Indicators - Watchlist</stix:Package_Intent>



<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-611935aa-4db5-4b63-88ac-ac651634f09b">

<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.0">File Hash Watchlist</indicator:Type>

<indicator:Description>Indicator that contains malicious file hashes.</indicator:Description>

<indicator:Observable id="example:Observable-c9ca84dc-4542-4292-af54-3c5c914ccbbc">

<cybox:Object id="example:Object-c670b175-bfa3-48e9-a218-aa7c55f1f884">

<cybox:Properties xsi:type="FileObj:FileObjectType">



<cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0" condition="Equals">MD5</cyboxCommon:Type>

<cyboxCommon:Simple_Hash_Value condition="Equals" apply_condition="ANY">0522e955aaee70b102e843f14c13a92c##comma##0522e955aaee70b102e843f14c13a92d##comma##0522e955aaee70b102e843f14c13a92e</cyboxCommon:Simple_Hash_Value>









Configuring Indicators in SmartConsole

Define network objects to hold the Indicator files.

To load Indicators:

  1. Go to Security Policies > Threat Prevention > Policy >Threat Tools > Indicators.

    The Indicators page opens.

  2. Click New.

    The Indicators configuration window opens.

  3. Enter a Name.

    Each Indicator must have a unique name.

  4. Enter Object Comment (optional).
  5. Click Import to browse to the Indicator file.

    The content of each file must be unique. You cannot load duplicate files.

  6. Select an action for this Indicator:
    • Ask - Threat Prevention Software Blade asks what to do with the detected observable
    • Prevent - Threat Prevention Software Blade blocks the detected observable
    • Detect - Threat Prevention Software Blade creates a log entry, and lets the detected observable go through
    • Inactive - Threat Prevention Software Blade does nothing
  7. Add Tag.
  8. Click OK.

    If you leave an optional field empty, a warning notifies you that the default values will be used in the empty fields. Click OK. The Indicator file will load.

To delete Indicators:

  1. Select an Indicator.
  2. Click Delete.
  3. In the window that opens, click Yes to confirm.

You can edit properties of an Indicator object, except for the file it uses. If you want an Indicator to use a different file, you must delete it and create a new one.

Using Anti-Bot and Anti-Virus with VSX

When you configure Virtual Systems to use the Anti-Bot and Anti-Virus Software Blades, make sure the Software Blade:

Note - Where applicable, make sure the routing, DNS, and proxy settings for the VSX Gateway (VSO) are configured correctly.

To enable Anti-Bot and Anti-Virus on Virtual Systems:

  1. If applicable, configure proxy settings for the VSX Gateway (VSO) or the Virtual Systems or both:
    1. From the Network Object tree, double-click the VSX Gateway (VSO).
    2. From the navigation tree, select Topology > Proxy.
    3. Configure the proxy settings, and click OK.
  2. Enable Anti-Bot and Anti-Virus on the VSX Gateway (VSO) for all Virtual Systems that use Anti-Bot and Anti-Virus:
    1. From the Network Object tree, double-click the Virtual System.
    2. In the Network Security section, select Anti-Bot and Anti-Virus.
    3. Click OK.
  3. Select the Threat Prevention and configure the policies.
  4. Install the Threat Prevention policy (and access policy if needed) on the VSX Gateway (VSO) and the relevant Virtual Systems.

Using Threat Extraction with VSX

When you configure Virtual Systems to use the Threat Extraction Software Blade, make sure that the Software Blade:

Note - Where applicable, make sure that the routing, DNS, and proxy settings for the VSX Gateway (VS0) are configured correctly.

To enable Threat Extraction on Virtual Systems:

  1. In the Gateways & Servers view, right-click the Virtual System object and select Edit.

    The Virtual System Properties window opens.

  2. On the General Properties > Network Security tab, select Threat Extraction.

    The Threat Extraction First Time Activation Wizard opens.

  3. In the Next Hop Configuration window, select Skip this configuration now, and click Next.
  4. In the Summary window, click Finish.
  5. In the VS Properties window, go to Mail Transfer Agent in the navigation tree, and select Enable as Mail Transfer Agent (MTA).
  6. Add the MTA definitions to Mail Forwarding.
  7. Click OK.
  8. Install the Standard policy on the Virtual Systems (including VS0).

Threat Prevention CLI Commands

You can run commands from the CLI (Command Line Interface) to install Threat Prevention policy and for advanced Threat Emulation management.

mgmt_cli install-policy

Description: Run this command on the Security Management Server to install the Threat Prevention policy on the specified Security Gateways.

Syntax: mgmt_cli install-policy <options>

Note: For more information, see Management API Reference.


Description: Use this command to manually send files for threat emulation. The command has to be run from expert mode. For a complete explanation of all the available parameters, run te_add_file.

Syntax: te_add_file -f=<file path> -d=<directory path>




Specifies the path to the file. You must include the file name at the end of the path.


Specifies the path to a directory. The command takes all the files in the directory and sends them for emulation.

Example: te_add_file -f=/home/admin/test.pdf

[Expert@gaia]# te_add_file -f=/home/admin/test.pdf

# Sending files... Wait for response: True

# Trying to connect to ted...

# Connected to ted...Ready to send...

# File path: /home/admin/test.pdf

# File type: pdf

# Got response from ted...


:event_id ("{000000A5-006D-0045-9D15-D6896862D148}")

:action (drop)

:confidence (high)

:done (0)

:file_path ("/home/admin/test.pdf")

:md5_string (61baabd6fc12e01ff73ceacc07c84f9a)


# Got response from ted...


:event_id ("{000000A5-006D-0045-9D15-D6896862D148}")

:action (drop)

:confidence (high)

:done (1)

:file_path ("/home/admin/test.pdf")

:md5_string (61baabd6fc12e01ff73ceacc07c84f9a)



Verdict: drop Time: 1 *

Total Files: 1

Verdicts distribution:

drop: 1

# Done 1 files in 1 seconds...Bye Bye...

Comments: ted is the Threat Emulation daemon.


Use the tecli commands to:

tecli advanced clear

Description: Resets the emulation statistics for the Security Gateway or appliance.

Syntax: tecli advanced clear

tecli cache clean

Description: Deletes all the records in the local cache.

Syntax: tecli cache clean

tecli control sizing

Description: Controls the sizing mode tool that lets you estimate the resources that Threat Emulation will use in your network.

Syntax: tecli control sizing {enable|disable|status}

Note: For more about using sizing mode, go to sk93598.

tecli debug

Description: Enable and disable debug mode for Threat Emulation.

Syntax: tecli debug {on|off|scan local {enable|disable}}




Enables debug mode


Disables debug mode

scan local enable

Enables the appliance or Security Gateway to scan local connection

scan local disable

Disables the appliance or Security Gateway to scan local connection


tecli d o or tecli debug on

tecli d s l e or tecli debug scan local enable

tecli show

tecli show commands show data and statistics about the Threat Emulation Software Blade. You can also use abbreviated parameters to run tecli show commands. These are some useful command combinations:



tecli s s

Shows emulation statistics

tecli s c i

Shows information about ThreatCloud emulation

tecli s c q

Shows the quota for ThreatCloud emulation

tecli s e e

Shows the current status of the emulation queue

tecli s u a

Shows all the parts of file emulation

tecli show cloud

Description: Shows data and statistics about your ThreatCloud account.

Syntax: tecli show cloud {identity|info|quota}




Shows data about how the Security Gateway or Emulation appliance connects to the ThreatCloud


Shows data about your file emulation in the ThreatCloud


Shows data about your ThreatCloud monthly emulation quota


tecli s c id or tecli show cloud identity

tecli s c in or tecli show cloud info

tecli show emulator

Description: Shows data about Threat Emulation queue and VMs (Virtual Machines).

Syntax: tecli show emulator {emulations|vm {synopsis|detailed|id <ID>}}




Shows the current status of the emulation queue


Shows a summary of the VMs


Shows data and details of the VMs

id <ID>

Shows data for the VM with this ID


tecli s e e or tecli show emulator emulations

tecli s e v s or tecli show emulator vm synopsis

tecli show downloads

Description: Shows data and statistics about files and rules that Threat Emulation is downloading.

Syntax: tecli show downloads {all|images|dr|sa|raw|types}




Shows the status of all downloads


Shows download status of operating system images


Shows download status of malware detection rules


Shows download status of static analysis rules


Shows download status of general Threat Emulation files


Shows the file extensions that are being sent for emulation


tecli s d a or tecli show downloads all

tecli s d i or tecli show downloads images

tecli show remote

Description Shows data and statistics about the Emulation appliance

Syntax tecli s r i or tecli show remote information

tecli show statistics

Description: Shows statistics to the Emulation appliance or Security Gateway.

Syntax: tecli s s or tecli show statistics


tecli show throughput

Description: Shows data about file emulation for each time interval.

Syntax: tecli show throughput {minute|hour|day|month}




Shows how many files completed emulation for each minute


Shows how many files completed emulation for each hour


Shows how many files completed emulation for each day


Shows how many files completed emulation for each month


tecli s t mi or tecli show throughput minute

tecli s t mo or tecli show throughput month

tecli show unit

Description: Shows all the parts of file emulation:

The output shows the number of files for each task in the emulation part.

Syntax: tecli u a or tecli show unit all


# tecli s u a


- system state (15)

- policy (15)

- file (1)

- contract (1)

- cache inquirer (1)


- duplicate (1)

- static analysis (1)

- emulator (1)

- cloud emulation (1)

- remote emulation (1)


- forensics (15)

- cache updater (15)

- threat cloud sharing (15)

- threat cloud statistics (15)

- file saver (15)

- logger (15)

- local filter counter (15)

Managing IPS gateways - CLI

You can use these CLI commands to manage IPS on your Security Gateways. You must be in expert mode to use the commands.

To see all available commands:

  1. On the gateway, go to the expert mode.
  2. Type ips and press Enter.



    ips on|off [-n]

    Enable or disable IPS on the Security Gateway.


    Empty templates table (applies fwaccel off; fwaccel on immediately). Otherwise, this command takes effect in a few minutes.

    ips stat

    Show the IPS status of the Security Gateway.

    ips bypass stat

    Show the Bypass Under Load status.

    ips bypass on|off

    Enable or disable Bypass Under Load.

    ips bypass set cpu|mem low|high <threshold>

    Set the Bypass Under Load threshold.


    Valid range is 1 to 99. Unit is percent.

    ips debug [-e filter] -o <output_file>

    Create an IPS debug file.
    Filter valid values are the same as for fw ctl debug. Consult with Check Point Technical Support.

    ips refreshcap

    Refresh the sample capture repository.

    ips stats [<ip_address> -m] [-g <seconds>] [<ip_address> <seconds>]

    Print IPS and Pattern Matcher performance statistics. Without arguments, runs on current Security Gateway for 20 seconds. This is a resource intensive command. Do not run it on a system with a high load.


    Analyzes input statistics file from Security Gateway. Give IP address of the Security Gateway. Run from the management server.


    Collect statistics for current Security Gateway.


    period in which statistics are gathered

    ips pmstats reset

    Reset pattern matcher statistics.

    ips pmstats -o <output_file>

    Print pattern matcher statistics.