SNORT Signature Support

SNORT is a popular, open source, Network Intrusion Detection System (NIDS). For more information about SNORT see snort.org.

Check Point supports the use of SNORT rules as both the GUI and the SmartDomain Manager API's options.

When you import a SNORT rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session., it becomes a part of the IPS Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). database.

Importing SNORT Protection Rules to the Security Management Server

Make sure you have the SNORT rule file. It holds SNORT rules and usually has the extension: .rules.

In a Multi-Domain Security Management environment, import SNORT rules to the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server.. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To override the profile settings for a specific SNORT protection, see Action on SNORT Protection Rules, see Action on SNORT Protection Rules.

Deleting SNORT Protection Rules from the Security Management Server

Importing SNORT Protection Rules to the Multi-Domain Server

Make sure you have the SNORT rule file. It holds SNORT rules and usually has the extension: .rules.

In a Multi-Domain Security Management environment, import SNORT rules to the Multi-Domain Server Dedicated Check Point server that runs Check Point software to host virtual Security Management Servers called Domain Management Servers. Synonym: Multi-Domain Security Management Server. Acronym: MDS.. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To override the profile settings for a specific SNORT protection, see Action on SNORT Protection Rules).

Deleting SNORT Protection Rules from the Multi-Domain Server

Action on SNORT Protection Rules

The Security Gateway enforces SNORT protection rules based on the profile which is installed on the Security Gateway. For example, if the profile installed on the Security Gateway is Optimized, by default the Security Gateway does not enforce SNORT protection rules, because their performance impact is High and the allowed performance impact defined in the Optimized profile is Medium or lower.

Alternative Methods to add and delete SNORT Protection Rules

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

• mgmt_cli tool

• SmartConsole CLI

• Gaia Clish The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell).

• POST Requests

Adding SNORT Rules

The applicable command accepts two arguments:

• package-format" which always takes the string value "snort"

• "package-path" which is the path to the protections' package

The command returns:

Upon success:	0
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

Deleting SNORT Protections

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

The command returns:

Upon success:	0
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

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 snort.org.

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.

• If one SNORT rule has multiple msg strings with the same value, Management Server aggregates these values in one IPS SNORT protection.

• If you import a SNORT rule at different times, and it has the same msg string, the latest import overrides the existing IPS SNORT protection.

SNORT Rule Syntax

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

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

• SNORT Rule Header:

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

• SNORT Rule Options:

  <keyword>:"<option>"

Example:

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

Where:

• Action = alert

• Protocol = TCP

• Source IP Address = any

• Source Port = any

• Direction = ->

• Destination IP Address = any

• Destination Port (Range)= 1:65535

• Name of protection rule in IPS = Possible exploit

• Keyword = content

• Option = |90|

Supported SNORT Syntax

These are the generally supported syntax components. There are some limitations, (see Unsupported SNORT Syntax).

• Supported Content Keyword Modifiers: "nocase", "rawbytes", "depth", "offset:", "distance:", "within", "urilen"

• Supported Threshold Rule Types - Threshold, Both (Limit is not supported.)

• Supported Macros - HTTP_PORTS (Interpreted as 80 and 8080 ports.)

Note - Make sure that SNORT Rules with the same flowbits flag have the same content in the msg field. Otherwise, they will not be under the same protection.

Debugging:

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

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.

• With HTTP content or PCRE modifiers

  • http_raw_uri content or "I" PCRE modifiers

  • http_stat_msg content or "Y" PCRE modifiers

  • http_stat_code content or "S" PCRE modifiers

• Without HTTP content or PCRE modifiers

  • Two or more uses of http_header content or "H" PCRE modifiers

  • Two or more uses of http_raw_header content or "D" PCRE modifiers

• With depth or offset content and http content that is one of these on the same content keyword, or ^ (carrot) in pcre with one of these http pcre modifiers on the same pcre keyword

  • http_header content or "H" PCRE modifiers

  • http_raw_header content or "D" PCRE modifiers

  • http_stat_msg content or "Y" PCRE modifiers

  • http_stat_code content or "S" PCRE modifiers

  • http_uri content or "U" PCRE modifiers

• Use of depth or offset content, or ^ (carrot) in PCRE, without any http content, and with destination ports that are not HTTP_PORTS macro

• http_client_body content or "P" PCRE modifier

• A PCRE keyword with {} (curly braces) quantifier

• Use of both content and byte_test keywords

• http_header content modifiers or "H" PCRE modifiers enforced only on raw http data (not decoded and normalized header data)

• Use of the urilen keyword, except in a SNORT Rule that has only http_uri and "U" PCRE modifiers, or http_raw_uri content modifier and I PCRE modifiers:

  • If the SNORT Rule has only http_uri content or "U" PCRE modifiers, the size will be of the decoded and normalized buffer.

  • If the SNORT Rule has only http_raw_uri content or "I" PCRE modifiers, the size will be of the raw uri buffer.

SSL Services

In addition to the conventional metadata service options, Check Point supports additional keywords specifically for SSL traffic.

SNORT rules for SSL traffic can be defined using the metadata keyword.

In the Snort rule options add:

metadata: service <ssl service>;

Example

alert tcp any any -> any 443 (msg:"Fake SSL Certificate"; content:"|08 e4 98 72 49 bc 45 07 48 a4 a7 81 33 cb f0 41 a3 51 00 33|"; metadata: service sslHello;)

Options for <ssl service>

Service	Description
sslHello	The sslHello service will search the Client Hello or Sever Hello depending on the flow.
sslCertificate	The sslCertificate service will search the Client Certificate or Sever Certificate depending on the flow.
sslKeyx	The sslKeyx service will search the Client Key Exchange or Sever Key Exchange depending on the flow.
sslHeartbeat	The sslHeartbeat will search the SSL heartbeats.
sslCiphersuite	The sslCiphersuite will search the Cipher Suite sent by the client.

When you use the sslHello, sslCertificate, or sslKeyx services, it is necessary to define a flow direction as either "flow: to_server" or "flow: from_server".

Note - These services and content modifiers are unique to Check Point and will not be supported by other SNORT engines.