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 ruleClosed 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 IPSClosed Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). database.

Step

Instructions

1

Import existing SNORT rules from a file.

2

  1. Snort Protection names are Snort imported: <value of the 'msg' field in the original SNORT rule>. See Creating SNORT Rule Files, (see Creating SNORT Rule Files).

  2. Snort Protections get these attributes automatically:

    • Performance Impact - High

    • Severity - High

    • Confidence Level - Low or Medium

3

Delete the existing SNORT rules

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 ServerClosed 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.

Step

Instructions

1

Connect with SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. to the Security Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. that manages the applicable Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. or Security ClusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing..

2

Open the applicable policy.

3

From the left navigation panel, click Security PoliciesClosed Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection..

4

In the top section of Threat Prevention, click Policy.

5

In the bottom section Custom Policy Tools, click IPS Protections.

6

From the top toolbar, click Actions > Snort Protections > Import Snort rules.

7

Select the file with the SNORT rules and click Open.

The tool converts the rules to Check Point syntax and updates the protections database.

SmartConsole shows the converted SNORT rules as IPS protections whose names start with Snort imported.

8

Publish the SmartConsole session.

9

Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

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

Step

Instructions

1

Connect with SmartConsole to the Security Management Server that manages the applicable Security Gateway or Security Cluster.

2

Open the applicable Policy.

3

From the left navigation panel, click Security Policies.

4

In the top section Threat Prevention, click Policy.

5

In the bottom section Custom Policy Tools, click IPS Protections.

6

From the top toolbar, click Actions > Snort protections >
Delete all snort protections.

7

Publish the SmartConsole session.

8

Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

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 ServerClosed 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.

Step

Instructions

1

Connect with SmartConsole to the Multi-Domain Server to the MDS context.

2

From the left navigation panel, click Multi-Domain > Domains.

3

Right-click on the Global Domain and select Connect to domain.

4

From the left navigation panel, click Security Policies.

5

Open the applicable global policy.

6

In the top section Threat Prevention, click Policy.

7

In the bottom section Custom Policy Tools, click IPS Protections.

8

From the top toolbar, click Actions > Snort Protections > Import Snort rules.

9

Select the required file with the SNORT rules and click Open.

The tool converts the rules to Check Point syntax and updates the protections database.

Important - SmartConsole shows the converted SNORT rules as IPS protections whose names start with Snort imported.

10

Publish the SmartConsole session.

11

Close the SmartConsole connected to the Global Domain.

12

From the left navigation panel, click Multi Domain > Global Assignments.

13

Reassign the Global Policy to the Local Domains.

14

Connect with SmartConsole to the applicable Domain Management Server that manages the applicable Security Gateway or Security Cluster.

15

Install the Threat Prevention Policy on the applicable Security Gateway or Security Cluster.

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

Step

Instructions

1

Connect with SmartConsole to the Multi-Domain Server to the MDS context.

2

From the left navigation panel, click Multi Domain > Domains.

3

Right-on the Global Domain and select Collect to domain.

4

From the left navigation panel, click Security Policies.

5

Open the applicable global policy.

6

In the top section Threat Prevention, click Policy.

7

In the bottom section Custom Policy Tools, click IPS Protections.

8

From the top toolbar, click Actions > Snort Protections > Delete all Snort protections:

9

Publish the session.

10

Close the SmartConsole connected to the Global Domain.

11

From the left navigation panel, click Multi Domain > Global Assignments.

12

Reassign the Global Policy to the Local Domains.

13

Connect with SmartConsole to the applicable Multi-Domain Server that manages the applicable Security Gateway or Security Cluster.

14

Install theThreat Prevention Policy on the applicable Security Gateway or Security Cluster.

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.

Step

Instructions

1

In IPS Protections, right-click a SNORT protection and select Edit.

Note - The SNORT protection names start with Snort imported.

2

Right-click the profile and select Edit.

3

In the Main Action area, select Override with.

4

From the drop-down menu, select the required action.

5

Click OK.

6

Click Close.

7

Publish the SmartConsole session.

8

Install the Threat Prevention Policy.

The images here follow the example described above. If you are on a different profile, or want a different action, change steps 2 or 4 accordingly.

Alternative Methods to add and delete SNORT Protection Rules

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

:

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
:
  • mgmt_cli add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json
  • add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json
  • mgmt add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

    Note - The --format json part is optional. By default, the output is presented in plain text.

  • A post request must:

    • Be sent to the following URL: https://<ip-address-of mgmt-server>:<port>/web_api/v1.2/add-threat-protections

    • Have the request headers Content-Type set to application/json and X-chkp-sid set to the unique session identifier returned by the login request.

    • Have the Content-Type arguments package-format and package-path in the request body.

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:

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
: 
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 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.

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

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

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

  • 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).

Keyword

Description

length

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

pcre

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";)

flowbits

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;)

byte_test

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;)

byte_jump

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;)

isdataat

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;)

no_match

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

Example:

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;)

  • 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.)

    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

  • pcre modifiers: 'G', 'O', 'A'

  • pcre regular expression with lookahead assertion: ?!

  • Using byte_test keyword with operator not in: <,>,=,&,^

  • http_method is not supported if it is the only http modifier type in the Snort Rule

  • Protocols: icmp, ip. (all is interpreted as UDP and TCP protocols)

  • Snort Rule without content keyword

  • All PORT macros, except HTTP_PORTS

  • Specification of source port (only any is supported)

  • Specification of destination port "any" (you must specify an exact destination port number, or a range of destination port numbers).

  • Specification of IP Addresses - Enforced on all IP Addresses

  • HOME_NET macro - Interpreted as any IP Addresses

  • EXTERNAL_NET macro - Interpreted as any IP Addresses

  • HTTP_SERVERS macro - Interpreted as any IP Addresses

These combinations of keywords and modifiers are implemented differently in the IPS blade as Snort protection rules than in SNORT Rules.

Test them before activating them in a production environment.

rawbytes content, or B pcre modifiers with http_uri content or U pcre modifiers

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>;

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;)

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.

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