Print Download PDF Send Feedback

Previous

Next

Configuring Advanced Threat Prevention Settings

In This Section:

Threat Prevention Engine Settings

SNORT Signature Support

Optimizing IPS

Using the Whitelist

Threat Indicators Overview

Manually Uploading Threat Indicator Files through SmartConsole

Uploading Threat Indicator Files through the CLI

Using Anti-Bot and Anti-Virus with VSX

Using Threat Extraction with VSX for Mail Support

Using Threat Extraction with VSX for Web

Threat Prevention CLI Commands

Threat Prevention Engine Settings

This section explains how to configure advanced Threat Prevention settings that are in the Engine Settings window, including: inspection engines, the Check Point Online Web Service (ThreatCloud repository), internal email whitelist, file type support for Threat Extraction and Threat Emulation and more.

To get to the Engine Settings window, go to Manage & Settings > Blades > Threat Prevention > Advanced Settings.

The Threat Prevention Engine Settings window opens.

Fail Mode

Select the behavior of the ThreatSpect engine if it is overloaded or fails during inspection. For example, if the Anti-Bot inspection is terminated in the middle because of an internal failure. By default, in such a situation all traffic is allowed.

Check Point Online Web Service

The Check Point Online Web Service is used by the ThreatSpect engine for updated resource categorization. The responses the Security Gateway gets are cached locally to optimize performance.

Connection Unification

Gateway traffic generates a large amount of activity. To make sure that the amount of logs is manageable, by default, logs are consolidated by session. A session is a period that starts when a user first accesses an application or a site. During a session, the gateway records one log for each application or site that a user accesses. All activity that the user does within the session is included in the log. For connections that are allowed or blocked in the Anti-Bot, Threat Emulation, and Anti-Virus Rule Base, the default session is 10 hours (600 minutes).

To adjust the length of a session:

  1. Go to Manage & Settings > Blades > Threat Prevention > Advanced Settings > General > Connection Unification > Session unification timeout (minutes).
  2. Enter the required value.
  3. Click OK.

Configuring Anti-Bot Whitelist

The Suspicious Mail engine scans outgoing emails. You can create a list of email addresses or domains whose internal emails are not inspected by Anti-Bot.

To add an email address or domain whose internal emails are not scanned by Anti-Bot:

  1. Go to the Manage & Settings > Blades > Threat Prevention > Advanced Settings > Anti-Bot.
  2. Click the + sign.

In this window, you can also edit or remove the entries in the list.

Selecting Emulation File Types

You can select the file types that are sent for emulation for all the Threat Prevention profiles. Each profile defines an Inspect or Bypass action for the file types.

To select Threat Emulation file types that are supported in Threat Prevention profiles:

  1. In SmartConsole, select Manage & Settings > Blades.
  2. From the Threat Prevention section, click Advanced Settings.

    The Threat Prevention Engine Settings window opens.

  3. From the Threat Emulation Settings section, click Configure file type support.

    The File Types Support window opens.

  4. Select the file types that are sent for emulation. By default all file types are sent for emulation.

    The Emulation supported on column shows the emulation environments that support the file type.

  5. Click OK and close the Threat Prevention Engine Settings window.
  6. Install the Threat Prevention policy.

Configuring Advanced Engine Settings for Threat Extraction

Advanced engine settings let you configure file type support and mail signatures for the Threat Extraction.

To configure file type support:

  1. Click the Manage & Settings view > Blades > Threat Prevention > Advanced Settings.

    The Threat Prevention Engine Settings window opens.

  2. In Threat Extraction, click Configure File Type Support.

    The Threat Extraction Supported File Types window opens.

  3. From the list select the file types which the Threat Extraction blade supports.
  4. Click OK.

To configure mail signatures:

  1. In the Threat Prevention Engine Settings window > Threat Extraction, click Configure Mail Signatures.

    The Threat Extraction Mail Signatures window opens.

    Use this window to configure text for:

    • Mail signatures for attachments with potential threats extracted

      The first signature is always attached to mail that has had threats extracted.

      A link to the original files is added if the email recipient is allowed to access it.

    • Mail signatures for unmodified attachments

    Predefined field codes can be inserted into the signature text, such as:

    • A link to the file before it was modified by the blade.

      The link opens the UserCheck Portal. The portal shows a list of attachments the recipient can download.

    • Reference ID.

      Use this ID to send the recipient the file. You can also find the ID in the logs.

      On the gateway, run the command: scrub send_orig_email.

  2. Click OK.

Configuring File Type Support

To configure file type support:

  1. In the Threat Prevention Engine Settings window Threat Extraction, click Configure File Type Support.

    The Threat Extraction Supported File Types window opens.

  2. From the list select the file types which the Threat Extraction blade supports.
  3. Click OK.

Configuring Mail Signatures

To configure mail signatures:

  1. In the Threat Prevention Engine Settings window > Threat Extraction, click Configure Mail Signatures.

    The Threat Extraction Mail Signatures window opens.

    Use this window to configure text for:

    • Mail signatures for attachments with potential threats extracted

      The first signature is always attached to an email that had threats extracted.

      The second signature is added to the first if the email recipient has access to the original file.

    • Mail signatures for unmodified attachments

      You can insert predefined field codes into the signature text, such as:

      • A link to the file before it was modified by the blade.

      The link opens the UserCheck Portal. The portal shows a list of attachments the recipient can download.

      • Reference ID.

      Use this ID to send the file to the recipient. You can also find the ID in the logs.

      On the gateway, run the command: scrub send_orig_email.

  2. Click OK.

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, it becomes a part of the IPS database.

You can perform these actions on a Check Point Management Server:

  1. Snort Protection names are Snort imported: <value of the ‘msg’ field in the original SNORT rule>. See Creating SNORT Rule Files.
  2. Snort Protections get these attributes automatically:
    • Performance Impact - High
    • Severity - High
    • Confidence Level - Low or Medium

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. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To import SNORT Protection rules to the Security Management Server:

  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 of Threat Prevention, click Policy.
  5. In the bottom section Threat 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.

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

  8. Publish the 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.

Deleting SNORT Protection Rules from the Security Management Server

To delete SNORT protection rules from the Security Management Server:

  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 Threat Tools, click IPS Protections.
  6. From the top toolbar, click Actions > Snort protections > Delete all snort protections.

  7. Publish the 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 Server. Then assign Global policy to the Domain Management Servers. This downloads the new SNORT protections to the Domain Management Servers.

To import SNORT rules to the Multi-Domain Server:

  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 Domainand 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 Threat 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 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

To delete SNORT protection rules from the Multi-Domain Server:

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

To override the profile settings for a specific SNORT protection:

  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 session.
  8. Install the Threat Prevention Policy.

Note - 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 can add and delete SNORT protection rules:

Adding SNORT Rules

The applicable command accepts two arguments:

The command returns:

Upon success:

0

Upon failure:

1 along with several parameters describing the error upon failure

Examples:

The server returns:

Upon success:

Status code 200

Upon failure:

The appropriate status code

Example:

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

Examples:

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

Example:

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

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>

<keyword>:"<option>"

Example:

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

Where:

Supported Snort syntax:

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

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.

Example:

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.

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

byte_test

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

Example:

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.

Example:

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.

Example:

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

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

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.

SSL Services

In addition to the conventional metadata service options, checkpoint 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> are as follows:

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 checkpoint and will not be supported by other Snort engines.

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

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

SecureXL

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

CoreXL

For Security Gateways running on multi-core hardware, CoreXL lets 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.30 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.

Configuring Whitelist Files

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.

To add a file to the Whitelist:

  1. Select Threat Prevention > Advanced > Whitelist Files.

    The Whitelist Files page opens.

  2. Click New.

    The New File Exception window opens.

  3. Enter parameters for the new file exception:
    • Name
    • Comment (optional)
    • MD5 signature
    • Select a color (optional) - the default is black
  4. Click OK.

To edit attribute of a file from the Whitelist:

  1. Select Threat Prevention > Advanced > Whitelist Files.

    The Whitelist Files page opens.

  2. Select a file.
  3. Click Edit.
  4. In the file properties window that opens, make necessary changes.
  5. Click OK.

To remove a file from the Whitelist:

  1. Select Threat Prevention > Advanced > Whitelist Files.

    The Whitelist Files page opens.

  2. Select a file or multiple files.
  3. Click Delete.
  4. Click Yes to confirm.

Threat Indicators Overview

Threat Indicators lets you add feeds to the Anti-Bot and Anti-Virus engines, in addition to the feeds included in the Check Point packages and ThreatCloud feeds.

You can add indicator files in two ways:

An Indicator is a 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.

An Observable is 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.

Threat Indicators demonstrate an attack by:

Indicators are derived from intelligence, self-analysis, governments, partners, and so on.

Supported Indicator Files

Indicator files must be in CSV or STIX XML (STIX 1.0) format:

Each record in CSV Check Point format and the STIX XML (STIX 1.0) format has these fields (files in CSV format which is not the Check Point format does not have to include all these fields, see Importing Automated Custom Intelligence Feeds):

Field

Description

Valid Values

Value Criteria

Optional

UNIQ-NAME

Name of the observable

Free text

Must be unique

No

VALUE

A valid value for the type of the observable

As provided in this table

Value of parameter

No

TYPE

Type of the observable

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

Not case sensitive

No

CONFIDENCE

Degree of confidence the observable presents

  • low
  • medium
  • high
  • critical

Default - high

Yes

SEVERITY

Degree of threat the observable presents

  • low
  • medium
  • high
  • critical

Default - high

Yes

PRODUCT

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.

Yes

COMMENT

 

Free text

 

Yes

Notes:

These are the valid values for each observable type:

Observable Type

Validation Criteria

URL

Any valid URL

Domain

Any URL domain

IP

Standard IPv4 address

IP Range

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

MD5

Any valid MD5

Mail-subject

Any non-empty text string

Mail-to

Mail-from

Mail-cc

Mail-reply-to

Can be one of these:

  • A single email address (Example: abc@domain.com)
  • An email domain (Examples: @domain.com or domain.com)

Notes:

stix:STIX_Package

stix:STIX_Header

stix:Title

stix:Description

stix:Indicators

stix:Indicator

indicator:Title

indicator:Type

indicator:Description

indicator:Observable

cybox:Object

cybox:Properties

FileObj:Hashes

cyboxCommon:Hash

cyboxCommon:Type

cyboxCommon:Simple_Hash_Value

stix:Observables

cybox:Observable

URIObj:Value

URIObject:Value

AddressObject:Address_Value

AddressObj:Address_Value

AddressObj:AddressObjectType

AddressObjet:AddressObjectType

cybox:Title

Example of a CSV Indicator File in Check Point Format

#! 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",,,,,,

"# UNIQ-NAME,VALUE,TYPE,CONFIDENCE,SEVERITY,PRODUCT,COMMENT",,,,,,

observ1,8d9b6b8912a2ed175b77acd40cbe9a73,MD5,medium,medium,AV,FILENAME:WUC
Invitation Letter Guests.doc

observ2,76700f862a0c241b8f4b754f76957bda,MD5,high,high,AV,FILENAME:essais~.swf|
NOTE:FWS type Flash file

observ7,http://somemaliciousdomain.com/uploadfiles/upload/exp.swf?info=
789c333432d333b4d4b330d133b7b230b03000001b39033b&infosize=00840000
,URL,high,high,AV,IPV4ADDR:196.168.25.25

observ8,svr01.passport.ServeUser.com,Domain,low,high,AB,TCP:80|
IPV4ADDR:172.18.18.25|NOTE:Embedded EXE Remote C&C and Encoded Data

observ9,somemaliciousdomain2.com,Domain,,low,AV,TCP:8080|IPV4ADDR:172.22.14.10

observ10,http://www.bogusdomain.com/search?q=%24%2B%25&form=MOZSBR&pc=
MOZI,URL,low,low,AB,IPV4ADDR:172.25.1.5

observ11,http://somebogussolution.com/register/card/log.asp?isnew=-1&LocalInfo=
Microsoft%20Windows%20XP%20Service%20Pack%202&szHostName=
ADAM-E512679EFD&tmp3=tmp3,URL,medium,,AB,

observ14,172.16.47.44,IP,high,medium,AB,TCP:8080

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

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

observ34,stamdomain.com,domain,,,AB,

observ35,stamdomain.com,mail-from,high,medium,AV,

observ37,xyz.com,mail-from,medium,medium,AB,

observ38,@xyz.com,mail-from,medium,medium,AB,

observ39,a@xyz.com,mail-from,medium,medium,AB,

Example of a STIX 1.0 XML Indicator File

<stix:STIX_Package

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:stix="http://stix.mitre.org/stix-1"

xmlns:indicator="http://stix.mitre.org/Indicator-2"

xmlns:stixVocabs="http://stix.mitre.org/default_vocabularies-1"

xmlns:FileObj="http://cybox.mitre.org/objects#FileObject-2"

xmlns:cybox="http://cybox.mitre.org/cybox-2"

xmlns:cyboxCommon="http://cybox.mitre.org/common-2"

xmlns:cyboxVocabs="http://cybox.mitre.org/default_vocabularies-2"

xmlns:example="http://example.com/"

xsi:schemaLocation="

http://stix.mitre.org/stix-1 ../stix_core.xsd

http://stix.mitre.org/Indicator-2 ../indicator.xsd

http://stix.mitre.org/default_vocabularies-1 ../stix_default_vocabularies.xsd

http://cybox.mitre.org/objects#FileObject-2 ../cybox/objects/File_Object.xsd

http://cybox.mitre.org/default_vocabularies-2 ../cybox/cybox_default_vocabularies.xsd"

id="example:STIXPackage-ac823873-4c51-4dd1-936e-a39d40151cc3"

version="1.0.1">

<stix:STIX_Header>

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

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

</stix:STIX_Header>

<stix:Indicators>

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

<FileObj:Hashes>

<cyboxCommon:Hash>

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

</cyboxCommon:Hash>

</FileObj:Hashes>

</cybox:Properties>

</cybox:Object>

</indicator:Observable>

</stix:Indicator>

</stix:Indicators>

</stix:STIX_Package>

Manually Uploading Threat Indicator Files through SmartConsole

When you manually upload threat indicator files through SmartConsole, the files must be in a CSV Check Point format or STIX XML (STIX 1.0) format. The files must contain records of equal size. If an Indicator file has records which do not have the same number of fields, it does not load. See Supported Indicator Files for the required fields and observable values.

Syntax rules of CSV Indicator files in Check Point format:

To load Indicator files through SmartConsole:

  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 are used in the empty fields. Click OK. The Indicator file loads.

  9. Install Policy.

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.

Uploading Threat Indicator Files through the CLI

You can upload indicator files through the CLI in Check Point CSV format and other CSV formats, and in STIX XML (STIX 1.0) format.

The Feed's resource can be one of these:

Use these commands to upload and manage threat indicator files through the CLI:

Parameter

Description

Example

push

Push feeds now

ioc_feeds push

show

Print all existing feeds

ioc_feeds show

show --feed_name <feed> 

Print specific feed details 

ioc_feeds show --feed_name local_feed

show_interval 

Print fetching interval 

ioc_feeds show_interval 

set_interval sec

Set interval for fetching in seconds

*Feed fetching interval - the same for all feeds

ioc_feeds set_interval 1000 

show_scanning_mode 

Print scanning mode 

ioc_feeds show_scanning_mode 

set_scanning_mode 

Set scanning mode - on/off 

ioc_feeds set_scanning_mode off

add 

Add a new feed

Mandatory fields:

--feed_name <feed>

--transport <http/https/local_file/local_directory>

--resource <url/full_path>

Optional fields:

--state <true/false> (active/inactive. default - True)

--feed_action <Prevent/Detect/Ask> (default – Prevent)

--user_name <user> (prompt for password appears)

--proxy <none> – do not use proxy

--proxy <proxy:port> - override gateway proxy for feed

(if you do not specify a proxy flag - the gateway proxy is used)

--proxy_user_name <user> (prompt for password appears)

--test true
test feed fetching and parsing

Examples:

ioc_feeds add --feed_name local_feed --transport local_file --resource /home/admin/my_feed.csv

ioc_feeds add --feed_name remote_feed --transport http --resource 10.0.0.1/my_feeds/stix_feed.xml --proxy 127.10.10.1:8080 --state false –feed_action detect --user_name admin@checkpoint.com

modify 

Modify existing feed

Fields that are not mentioned stay as they were before 

ioc_feeds modify --feed_name local_feed --state true

delete 

Delete existing feed 

ioc_feeds delete --feed_name local_feed 

Examples:

Importing Automated Custom Intelligence Feeds

You can import threat indicator feeds from external sources directly to the Security Gateway. The gateway automatically pulls and enforces an indicator file, over HTTP or HTTPS, or by reading from a local file or folder. There is no need to install policy to enforce the feeds, but you must import the files on each gateway separately.

Automated custom intelligence feeds support STIX XML (STIX 1.0) files, CSV files in Check Point format, and CSV files in other formats. To import Threat Indicator files in CSV format that is different than the Check Point CSV format, follow the syntax rules provided in this section.

Syntax Rules:

Examples:

To learn more about Custom Intelligence Feeds, see sk132193.

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 for Mail Support

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

Using Threat Extraction with VSX for Web

When you configure Virtual Systems to use the Threat Extraction Software Blade, make sure that the Software Blade is enabled and configured on the relevant Virtual Systems and enabled and configured on the VSX Gateway (VS0).

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. Enable Threat Extraction web support: In the Security Policies view, go to > Threat Prevention > Threat Tools > Profiles > double-click a profile > Threat Extraction > General > Protocol, and select Web (HTTP/HTTPS).
  6. 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 IPS and advanced Threat Emulation management.

In any case of conflict between the CLI commands and the SmartConsole configuration, the CLI commands will be enforced.

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.

te_add_file

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>

Parameter

Description

-f=

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

-d=

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)

)

/home/admin/test.pdf

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.

tecli

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

Parameter

Description

on

Enables debug mode

off

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

Example:

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:

Command

Description

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}

Parameter

Description

identity

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

info

Shows data about your file emulation in the ThreatCloud

quota

Shows data about your ThreatCloud monthly emulation quota

Example:

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

Parameter

Description

emulations

Shows the current status of the emulation queue

synopsis

Shows a summary of the VMs

detailed

Shows data and details of the VMs

id <ID>

Shows data for the VM with this ID

Example:

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}

Parameter

Description

all

Shows the status of all downloads

images

Shows download status of operating system images

dr

Shows download status of malware detection rules

sa

Shows download status of static analysis rules

raw

Shows download status of general Threat Emulation files

types

Shows the file extensions that are being sent for emulation

Example:

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

Results:

tecli show throughput

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

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

Parameter

Description

minute

Shows how many files completed emulation for each minute

hour

Shows how many files completed emulation for each hour

day

Shows how many files completed emulation for each day

month

Shows how many files completed emulation for each month

Example:

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

Results:

# tecli s u a

[prepare]

- system state (15)

- policy (15)

- file (1)

- contract (1)

- cache inquirer (1)

[processing]

- duplicate (1)

- static analysis (1)

- emulator (1)

- cloud emulation (1)

- remote emulation (1)

[finalizing]

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

    Command

    Description

    ips on|off [-n]

    Enable or disable IPS on the Security Gateway.

    -n

    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.

    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.

    -m

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

    -g

    Collect statistics for current Security Gateway.

    seconds

    period in which statistics are gathered

    ips pmstats reset

    Reset pattern matcher statistics.

    ips pmstats -o <output_file>

    Print pattern matcher statistics.