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 Configuring Threat Prevention Settings on VSX Gateways 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.

• Allow all connections (Fail-open) - All connections are allowed in a situation of engine overload or failure (default).
• Block all connections (Fail-close) - All connections are blocked in a situation of engine overload or failure.

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.

• Block connections when the web service is unavailable
  • When selected, connections are blocked when there is no connectivity to the Check Point Online Web Service.
  • When cleared, connections are allowed when there is no connectivity (default).
• Resource categorization mode - You can select the mode that is used for resource categorization:
  • Background - connections are allowed until categorization is complete - When a connection cannot be categorized with a cached response, an uncategorized response is received. The connection is allowed. In the background, the Check Point Online Web Service continues the categorization procedure. The response is cached locally for future requests (default).
    This option reduces latency in the categorization process.
  • Hold - connections are blocked until categorization is complete - When a connection cannot be categorized with the cached responses, it remains blocked until the Check Point Online Web Service completes categorization.
  • Custom - configure different settings depending on the service - Lets you set different modes for Anti-Bot and Anti-Virus. For example, click Customize to set Anti-Bot to Hold mode and Anti-Virus to Background mode.

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:

• Import existing SNORT rules from a file
• After import and conversion:

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

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

• mgmt_cli tool
• SmartConsole CLI
• Gaia Clish
• 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

Examples:

• From the mgmt_cli tool, run this command:

  mgmt_cli add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

• From the SmartConsole CLI, run this command:

  add threat-protections package-path "/path/to/community.rules" package-format "snort" --version 1.2 --format json

• From the Gaia Clish, run this command:

  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.

• POST Request Method

  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

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:

• From the mgmt_cli tool, run this command:

  mgmt_cli delete threat-protections package-format "snort" --version 1.2

• From the SmartConsole CLI, run this command:

  delete threat-protections package-format "snort" --version 1.2

• From the Gaia Clish, run this command:

  mgmt delete threat-protections package-format "snort" --version 1.2

• POST Request method

  A POST Request must be send to this URL:

  https://<IP-address-of-mgmt-server>:<port>/web_api/v1.2/delete-threat-protections

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.

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

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

• 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

This syntax is not supported and will not convert:

• 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 range of destination port numbers).

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

• 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. Best Practice - Test them before activating them in a production environment.

• rawbytes content, or B pcre modifiers with http_uri content or U pcre modifiers
• 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, 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:

• Manually upload the indicator files.
• Import automated Custom Intelligence Feeds.

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:

• Specific observable patterns
• Additional information intended to represent objects and behaviors of interest in a cyber-security context

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:

• SmartConsole supports CSV files only in the Check Point format.
• The CLI also supports other formats of CSV files, as long as their upload complies with the required rules (see Importing Automated Custom Intelligence Feeds).

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:

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

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:

• As of this release, STIX 2.0 (JSON file) is not supported.
• Custom Indicators CLI (load_indicators) are not supported.
• SHA1/SHA256 is not supported as a valid MD5 value.
• The supported STIX elements are:

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

• Condition Type Enum and Condition Application Enum support Equals and Any.

  <cyboxCommon:Simple_Hash_Value condition="Equals" apply_condition="ANY">

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:

• Use commas to separate the fields in a record
• Enter one record per line, or use '\n' to separate the records
• If free text contains quotation marks, commas, or line breaks, it must be enclosed in quotation marks
• To enclose part of free text in quotations, use double quotation marks: ""<text>""

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:

• URL - HTTP/HTTPS (transport http --resource http://10.0.0.1/my_feeds/stix_feed.xml)
  *Self-signed certificate HTTPS resource prompts for a user agreement to update the bundle. You can skip the certificate verification by running "export EXT_IOC_NO_SSL_VALIDATION=1" on the gateway.
• File on the gateway (--transport local_file --resource "/home/admin/my_feed.csv")
• Directory on the gateway, which contains the same feed_format - (--transport local_directory --resource "/home/admin/my_feed_folder")

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:

• Add a new remote feed:

  [Expert@HostName:0]# ioc_feeds add --feed_name remote_csv_feed --transport http --resource "http://10.10.1.100/ioc/ioc_csv_file.csv" --feed_action Prevent

• Add a new local feed:

  [Expert@HostName:0]# ioc_feeds add --feed_name ioc_stix_file --transport local_file --resource "/home/admin/ioc/ioc_stix_file.xml"

• Print existing feeds:

  [Expert@HostName:0]# ioc_feeds show

• Delete a feed:

  [Expert@HostName:0]# ioc_feeds delete --feed_name ioc_stix_file

• Test feed fetching and parsing:

  [Expert@HostName:0]# ioc_feeds add --feed_name remote_stix_file --transport http --resource "http://www.public_indicators.com/ioc_stix_file.xml" --test true

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:

• The supported observables are: Name, Value, Type, Confidence, Severity, Product, Comment.
• Define the file's format, delimiter and the comment lines to skip:

  Use --format and specify your observables inside square brackets.

  Use --comment for content to ignore in the original file.

  Note: comment specified within the square brackets of --format is fetched from the original file. content inside the square brackets of --comment is ignored.

• Value and Type observables are mandatory.
• The Value observable is specified according to its location in the original file: #<location_of_item>.

  For example:

  If the Value observable is in the 3rd place in your csv row, enter:

  --format [value:#3]

• For all other observables, you can enter their location in the original file, or specify their value.

  For example, if you want the value of the Type observable to be the domain specified in every csv row, enter:

  --format [type:domain]

• When the feed's resource is a remote source (transport equals HTTP or HTTPS), every time the feed is fetched, it parses according to the format that was specified for this feed.

Examples:

• Original CSV file is a list of domains:

  # This list consists of High Level Sensitivity website URLs # Columns (tab delimited): # (1) site # Site 4kqd3hniqgptupi3p.k7oudl.top stggsjv6mqiibmax.torshop.li grrgelpetkavanis4.pv 52ou5k3t73ypjije.ie7t8k.top ja:many.cu.ma

  If you enter this command, the gateway takes the domain specified in the first place of every row, and ignores anything that starts with # and the word Site.

  ioc_feeds add --feed_name domain_list --transport https --resource "https://isc.sans.edu/feeds/suspiciousdomains_High.txt" --format [type:domain,value:1] --comment "#, Site"

• This is the original CSV file:

  # category Descriptive tag name for this entry. For this report, # the text sshpwauth will appear. # # A commented footer section shows an aggregate account of ASNs and # addresses seen in the current report # 3 | organization A | 18.30.10.26 | 2018-12-15 08:16:39 | sshpwauth 3 | organization B | 18.30.21.197 | 2018-12-28 17:43:41 | sshpwauth 17 | organization C | 128.46.80.71 | 2019-01-04 17:56:00 | sshpwauth 111| organization D | 128.197.31.119 | 2019-01-10 03:12: 18| sshpwauth

  If you enter this command, the gateway takes the IP address from the 3rd place in the row, takes the comment from the second place in the row, and ignores all content preceded by #:

  ioc_feeds add --feed_name ip_list_with_spaces --transport local_file --resource "/home/admin/ioc/ip_list_with_spaces.txt" --format [value:#3,comment:#2,type:ip] --comment [#] --delimiter "|"

To learn more about Custom Intelligence Feeds, see sk132193.

Configuring Threat Prevention Settings on VSX Gateways

When you configure Virtual Systems to use a Threat Prevention Software Blade, make sure the Software Blade:

• Is enabled and configured on the relevant Virtual Systems. The VS0 handles contract validation for all Virtual Systems.
• Can connect to the internet. A Virtual System gets updates through the VSX Gateway (VS0). If the VSX Gateway fails, each Virtual System uses its proxy settings to get the update from the internet.

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

To enable Anti-Bot, Anti-Virus or IPS on Virtual Systems:

1. If applicable, configure proxy settings for the VSX Gateway (VS0) or the Virtual Systems or both:
   1. In SmartConsole > Gateways & Servers view > double-click the VSX Gateway (or VSX Cluster) object.
   2. From the navigation tree, select Network Management > Proxy.
   3. Configure the proxy settings.
   4. Click OK.
2. Enable Anti-Bot/Anti-Virus/IPS on the Virtual Systems that use Anti-Bot/Anti-Virus/IPS.
   1. In the Gateways & Servers view, expand the VSX Gateway or VSX Cluster object, and double-click the Virtual System object.
   2. In the Network Security tab, select any or all of these blades:
      • Anti-Bot
      • Anti-Virus
      • IPS
   3. Click OK.
3. When you enable the Anti-Bot/Anti-Virus/IPS blades, the First Time Activation window opens, and you must select:
   • According to the Threat Prevention policy
   • Detect only
4. Configure the Threat Prevention policy.
5. Install the Threat Prevention policy on the relevant <tp_vsx_vss).

To enable Threat Emulation on Virtual Systems:

1. If applicable, configure proxy settings for the VSX Gateway (VS0) or the Virtual Systems or both:
   1. In SmartConsole > Gateways & Servers view > double-click the VSX Gateway (or VSX Cluster) object.
   2. From the navigation tree, select Network Management > Proxy.
   3. Configure the proxy settings.
   4. Click OK.
2. Enable Threat Emulation on the Virtual Systems that use Threat Emulation:
   1. In the Gateways & Servers view, expand the VSX Gateway or VSX Cluster object, and double-click the Virtual System object.
   2. In the Network Security tab, select Threat Emulation
   3. Click OK.
3. In the Threat Emulation First Time Activation Wizard that opens, configure the emulation location.
4. Configure the Threat Prevention policy.
5. Install the Threat Prevention policy (and Access Control policy, if needed) on the relevant <tp_vsx_vss).

To enable Threat Extraction on Virtual Systems:

1. If applicable, configure proxy settings for the VSX Gateway (VS0) or the Virtual Systems or both:
   1. In SmartConsole > Gateways & Servers view > double-click the VSX Gateway (or VSX Cluster) object.
   2. From the navigation tree, select Network Management > Proxy.
   3. Configure the proxy settings.
   4. Click OK.
2. In the Gateways & Servers view, right-click the Virtual System object and select Edit.

   The Virtual System Properties window opens.

3. In the General Properties page, go to the Threat Prevention tab and select Threat Extraction.

   The Threat Extraction First Time Activation Wizard opens.

4. In the Next Hop Configuration window:

   If you want Threat Extraction to scan email attachments, you must enable the MTA and configure the Domain and Next Hop.

   If you do not want Threat Extraction to scan email attachments, select Skip this configuration now, and then click Next.

5. In the Summary window, click Finish.
6. Enable Threat Extraction web support:

   In the Security Policies view, go to Threat Prevention > Threat Tools > Profiles > double-click a profile > go to <to_tcb> > General > Protocol, and select Web (HTTP/HTTPS).

7. Install the default VSX policy on the VSX Gateway/VSX Cluster

   This policy is called:

   <Name of the VSX Gateway or VSX Cluster object_VSX

8. Install the ,Threat Preventionpolicy on the Virtual Systems (including (VS0).

For more information, see sk106496 and sk79700.

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:

• Control local cache
• Show information about the Threat Emulation system
• Run advanced options
• Show status of emulation downloads, statistics and processes
• Configure affinity for TED (Threat Emulation Daemon)

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:

• Prepare
• Processing
• Finalizing

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.