R80.20 – fw monitor

Introduction

This document describes the content inspection in a Check Point R80.10 and above gateways. Context Management Infrastructure (CMI) is the “brain” of the content inspection and use more different modules (CMI Loader, PSL vs. PXL, Protocol Parsers, Pattern Matcher, Protections and new in R80.10 NGTP Architecture) for content inspection.

Chapter

R80.x Security Gateway Architecture (Logical Packet Flow) 

R80.x Security Gateway Architecture (Content Inspection) 

R80.x Ports Used for Communication by Various Check Point Modules 

What’s new in R80.10 and above:
  • UP Manager
  • Unified policys
  • NGTP Architecture
  • Content Awareness (CTNT)
Context Management Infrastructure and and Basic Components
https://community.checkpoint.com/servlet/JiveServlet/downloadImage/102-3073-17-68916/pastedImage_1.png

                         This picture is from Check Point. I will update my original picture in the next days.

Context Management Infrastructure – The Context Management Infrastructure (CMI) is the “brain” of the content inspection. It coordinates different components, decides which protections should run on a certain packet, decides the final action to be performed on the packet and issues an event log.
CMI separates parsers and protections. Protection is a set of signatures or/and handlers, where

  • Signature – a malicious pattern that is searched for
  • Handler – INSPECT code that performs more complex inspection

CMI is a way to connect and manage parsers and protections. Since they are separated, protections can be added in updates, while performance does not depend on the number of active protections. Protections are usually written per protocol contexts – they get the data from the contexts and validate it against relevant signatures. Based on the policy, the CMI determines which protections should be activated on every context discovered by a protocol parser. If policy dictates that no protections should run, then the relevant parsers on this traffic are bypassed in order to improve performance and reduce potential false positives.

CMI Loader – collects signatures from multiple sources (e.g. IPS, Application Control,…) and compiles them together into unified Pattern Matchers (PM).

Stream Assembly In order to identify more sophisticated threats we need to do additional inspection of the initial and subsequent packets within a session. The Streaming Engine processes the individual packet chains, creates an ordered packet stream and directly performs a number of security functions on the stream. One is to validate the TCP stream, e.g. looking for retransmissions with modified data or TCP connection packets with no handshake. The streaming engine passes assembled stream to the protocol parsers.

The engine has two modes depending on the nature of the traffic. In the passive mode there is limited opportunity to modify the traffic stream itself. The active mode however, is able to modify the connection. This mode essentially proxies the TCP connection and is necessary when performing HTTPS man-in-the-middle inspection. Active streaming also facilitates timing and buffering when it’s necessary to inspect content such as large files.

Streaming serves – an important function in the NGTP software architecture. The streaming process creates an ordered packet stream and directly performs a number of security functions on the stream. NGTP can assemble packets into a stream in two ways, passive or active, depending on the nature of the traffic. Each has advantages and disadvantages. The passive mode gives little opportunity for modifying the traffic stream. In contrast, the active mode can modify the connection. Active mode essentially proxies the TCP connection and is necessary when performing HTTPS inspection. Active streaming also facilitates timing and buffering when inspecting content such as large files. Keeping the goals of integrated, high security effectiveness and performance in mind, Check Point chose to provide the option to do passive and active streaming, which provides the best balance of security and optimized performance based on actual usage conditions.

PSL – Packets may arrive out of order or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with Passive Streaming Library (PSL) technology.

  • PSL is an infrastructure layer, which provides stream reassembly for TCP connections.
  • The gateway makes sure that TCP data seen by the destination system is the same as seen by code above PSL.
    This layer handles packet reordering, congestion handling and is responsible for various security aspects of the TCP layer such as handling payload overlaps, some DoS attacks and others.
  • The PSL layer is capable of receiving packets from the firewall chain and from SecureXL module.
  • The PSL layer serves as a middleman between the various security applications and the network packets. It provides the applications with a coherent stream of data to work with, free of various network problems or attacks
  • The PSL infrastructure is wrapped with well defined APIs called the Unified Streaming APIs which are used by the applications to register and access streamed data.

For more details – how a connection comes into the PSL modul – see article:

R80.x Security Gateway Architecture (Logical Packet Flow)

PXL – Technology name for combination of SecureXL and PSL.

Protocol Parsers – Protocols include HTTP, SMTP, DNS, IMAP, Citrix, and many others. Protocol parser instances register with the streaming engine in order to receive ordered streams of data, both client-to-server (C2S) as well as server-to-client (S2C) streams. They test for conformance to RFCs and look for anomalies. An example of a protocol anomaly would be where, for example, there is a non-existing HTTP method instead of GET, POST etc. in the HTTP header.

Another job of the parsers is to normalize content. The parser will normalize this content before passing the URL to the protections for inspection. The parsers main purpose is to extract ‘contexts’ from the streams to prepare for the next level of inspection. The content is normalized before inspection to thwart attempts to evade detection. The protocol parser detects and prevents protocol anomalies. The parsers main purpose is to extract ‘contexts’ from the streams to prepare for the next level of inspection.

Pattern Matcher – Security modules each have a distinct function and they register with the CMI to receive particular context types. The CMI Loader maintains a register table of all security modules and the contexts they want to inspect. This registration process occurs at policy install time. During policy installation, the CMI collects signatures from multiple sources (e.g. IPS and Application Control) and compiles them together into Pattern Matchers (PM) (one for each context – such as URL, Host header etc.). The CMI Pattern Matcher quickly identifies harmless packets, common signatures in malicious packets, and does a second level analysis when needed to reduce false positives. The engine uses a two tiered inspection process. The first tier quickly filters out the vast majority of traffic which is clearly harmless by looking for signatures that are simple to find at a low CPU cost. If the first tier identifies a common attack signature a second level analysis is done, thus increasing the confidence that there is indeed an attack. The first tier will never decide on its own that a packet is malicious. It can only decide that a packet is clearly harmless. The second tier can also be instructed to activate further inspection using INSPECT technology when some patterns are matched.

The Pattern Matcher is a fundamental engine within the enforcement architecture.

  • Pattern Matcher quickly identifies harmless packets, common signatures inmalicious packets, and does a second level analysis to reduce false positives.
  • Pattern Matcher engine provides the ability to find regular expressions on a stream of data using a two tiered inspection process:
    • The first tier quickly filters out the vast majority of traffic which is clearly harmless by looking for signatures that are simple to find at a low CPU cost.

If the first tier identifies a common attack signature it passes the connection to the second tier to do a second level analysis, thus increasing the confidence that there is indeed an attack.

  • The first tier will never decide on it’s own that a packet is malicious. It can only decide that a packet is clearly harmless.
  • The second tier can also be instructed to activate further inspection using INSPECTv2 technology when some patterns are matched.

Protections  – are composed of signatures that identify malicious activity. There are three types of signatures;

  • Regular expression like patterns
  • INSPECT code
  • Compound Signature Identification (CSI)

Regex signatures are done first followed by INSPECT and CSI if needed. CSI can address signatures on multiple parts of a packet, multiple parts of the protocols such as URL and an HTTP header, multiple parts of a connection, such as CIFS request and response, or multiple connections, such as VoIP control and data connections. In its operation, CSI constructs complex signatures that are triggered only if a certain logical condition over multiple contexts is matched. The logical expression can use AND, OR, NOT or ORDERED-AND to construct the logical expression.

Content Security Policy and InspectionWhen enabling advanced security features like Application Control, URL Filtering, Content Awareness, IPS, Anti-Bot, Antivirus and SandBlast Threat Emulation (sandboxing); the security gateway inspects content using the contexts derived from the protocol parser. The gateway’s local cache is augmented with real-time cloud updates and zero-day threat protection.

During policy installation, signatures are compiled into Pattern Matchers (PM) with one PM for each context such as URL, Host header etc. The PM quickly identifies harmless packets, common signatures in malicious packets, and if needed, does a second-level analysis to reduce false positives. The engine uses a two-tiered inspection process. The first tier quickly filters out the vast majority of traffic, which is clearly harmless, by looking for signatures that are simple to find at a low CPU cost. If the first tier identifies a common attack signature, it passes the connection to the second tier to do a second level analysis. This increases confidence there is indeed an attack.

It is worth noting that in some cases, the determination is a simple comparison. For instance, minimal processing time is needed to check an IP, a URL, a domain, or a file checksum against a known list. These comparisons are done first. A Context Management Infrastructure (CMI) connects parsers with pattern matchers. CMI determines which protections should be activated on every context discovered by a protocol parser. If policy dictates that no protections should run, then the relevant parsers on this traffic are bypassed in order to improve performance and reduce potential false positives. For instance, if the IPS policy is activating server protections only, then the HTTP parser will not analyze the server to client (S2C) traffic. After the security module analysis is done, their verdict is passed to the CMI to perform the final action to be done on the various contexts.

Cache with Cloud BackupAfter a match by the Pattern Matcher, the CMI is notified by the relevant module like Application Control, URL Filtering, Antivirus, Anti-Bot and Threat Emulation that its signature was matched. Additional processing is done as needed by the security module. For instance Application Control retrieves all the data regarding the application (its categories, priority, etc.) from a cache based on the signature that was matched. If a match is not found or social network widget detection is needed, then the  cloud service is checked. URL Filtering is another example where if the context is not found in cache, then the  cloud service is checked. URL categorization occurs mostly in the kernel. When not found in the local cache, the  cloud service is checked and the result is then cached in the kernel.

 
For instance:

  • Application Control retrieves all the data regarding the application (its categories, priority, etc.) from a cache based on the signature that was matched. If a match is not found or social-network widget detection is needed, then the  cloud service is checked and the cache is updated with the result.
  • URL Filtering checks for the URL category in the local cache. If not found, then the  cloud service is checked. The cache is then updated with the result.
  • Threat Emulation is a special case where the Pattern Matcher can be bypassed. If the checksum of a file is not cached, then the sandbox needs to receive a complete file. The protocol parser extracts the file and sends the file to our cloud service for processing where compute, disk and memory are virtually unlimited. If the protocol requires immediate delivery as in the case of HTTP/S, we offer user agents to notify the user and deliver only safe content to the user while the emulation happens in the background. Newly discovered threats are added to the local cache and sent to the cloud database to protect other Check Point platforms.

File HandlingIn some situations we need to inspect an entire file for malicious behavior. In these cases the file is sent directly to Threat Emulation, Threat Extraction and Antivirus for processing. If the SHA1 of the file is not cached, then these modules may need to receive a complete file. Files can be extracted from streams and security gateways have the option to act as a mail relay (Mail Transfer Agent), which allows us to inspect encrypted SMTP traffic over TLS. With SMTP inspection users don’t notice delays whilst inspection like that required in Threat Emulation (sandboxing) of large or complex attachments is carried out.

When files are transferred over HTTP/HTTPS, then users may notice a delay while Threat Emulation occurs. SandBlast Threat Extraction technology eliminates threats by removing exploitable content and reconstructing documents using known safe elements. Safe content is delivered to the user. Users are allowed access to original files after Threat Emulation completes its analysis.

Final DecisionAfter the security module analysis is done, their verdict is passed to the CMI to perform the final action. The CMI is responsible for the final action to be performed on the packet, given several considerations. The considerations include:

  • Activation status of the protection. e.g. IPS prevent, detect or inactive
  • Exceptions either on traffic or on IPS protection
  • Bypass mode status (the software fail open capability)
  • Troubleshooting mode status
  • Are we protecting the internal network only or all traffic

UserCheckIn the Application Control, URL Filtering and DLP security policy, the action Ask User presents users with a UserCheck dialog window prompting them to confirm they wish to complete the connection and if needed provide a reason. For example they may be visiting a risky site or sending confidential content to an external recipient. Depending upon their response the connection will be allowed or denied.

Unified policies

Check Point R80.10, part of Check Point Infinity, takes security to new levels, merging security into a single system which enables administrators to easily identify security risks across the organization.

Unified policies in R80.10 gateways enables organizations to translate their security definitions into a simple set of rules, which then streamline policy administration and enforcement throughout the organization. Policy layers provide the ability to separate the policy into independent segments, which can be independently managed and automated. In the kernel the rule base is represented as a database table. This enables the gateway security policy to automatically adapt as dynamic objects change, providing simple automated security across physical, virtual and cloud environments.

NGTP Architecture – Session-based processing enforces advanced access control and threat detection and prevention capabilities. To do this we assemble packets into a stream, parse the stream for relevant contexts and then security modules inspect the content. When possible, a common pattern matcher does simultaneous inspection of the content for multiple security modules. In multi-core systems this processing is distributed amongst the cores to provide near linear scalability on each additional core.

Security modules use a local cache to detect known threats. This local cache is backed up with real-time lookups of an  cloud service. The result of cloud lookups are then cached in the kernel for subsequent lookups. Cloud assist also enhances unknown threat detection and prevention. In particular a file whose signature is not known in a local cache is sent to our cloud service for processing where compute, disk and memory are virtually unlimited. Our sandboxing technology, SandBlast Threat Emulation, identifies threats in their infancy before malware has an opportunity to deploy and evade detection. Newly discovered threats are sent to the cloud database to protect other Check Point connected gateways and devices. When possible, active content is removed from files which are then sent on to the user while the emulation is done.

UP Manager – The UP Manager controls all interactions of the components and interfaces with the Context Management Infrastructure (CMI) Loader, the traffic director of the CMI. The UP Manager also has a list of Classifiers that have registered for “first packets” and uses a bitmap to instruct the UP Classifier to execute these Classifier Apps to run on the packet. The “first packets” arrive directly from the CMI. Parsing of the protocol and streaming are not needed in this stage of the connection. For “first packets” the UP Manager executes the rule base.

Classifier – When the “first packet” rule base check is complete Classifiers initiate streaming for subsequent packets in the session. The “first packet” rule base check identifies a list of rules that possibly may match and a list of classifier objects (CLOBs) that are required to complete the rule base matching process. The Classifier reads this list and generates the required CLOBs to complete the rule base matching. Each Classifier App executes on the packet and tells the result of the CLOB to the UP Manager. The CMI then tells the Protocol Parser to enable streaming.

In some cases Classifier Apps do not require streaming, e.g. the first packet information is sufficient. Then the rule base decision can be done on the first packet.

  •       Dynamic Objects
  •       Domain Objects
  •       Only the firewall is enabled

On subsequent packets the Classifier can be contacted directly from the CMI using the CMI Loader infrastructure, e.g. when the Pattern Matcher has found a match it informs the CMI it has found application xyz. The CMI Loader passes this information to the Classifier. The Classifier runs the Classification Apps to generate CLOBs required for Application Control and sends the CLOBs to the Observer.

Observer – The Observer decides if enough information is known to publish a CLOB to the security policy. CLOBs are observed in the context of their transaction and the connection that the transaction belongs to. The Observer may request more CLOBs for a dedicated packet from the Classifier or decides that it has sufficient information about the packet to execute the rule base on the CLOB, e.g. if a file type is needed for Content Awareness and the gateway hasn’t yet received the S2C response containing the file. Executing the rule base on a CLOB is called “publishing a CLOB”. The Observer may wait to receive more CLOBs that belong to the same transaction before publishing the CLOBs.

Security Policy – The Security Policy receives the CLOB published by the Observer. The CLOB includes a description of the Blade it belongs to so that matching can be performed on a column basis. The security policy saves the current state on the transaction Handle; either to continue the inspection or final match.

The first packets are received directly from the UP Manager. Subsequent packets are received by the rule base from the Observer.

Handle – Each connection may consist of several transactions. Each transaction has a Handle. Each Handle contains a list of published CLOBs. The Handle holds the state of the security policy matching process. The Handle infrastructure component stores the rule base matching state related information.

Subsequent Packets – Subsequent packets are handled by the streaming engine. The streaming engine notifies the Classifier to perform the classification. The Classifier will notify the UP Manager about the performed classification and pass the CLOBs to the Observer. The CLOBs will then be received by the Observer that will need to wait for information from the CMI. The CMI sends the information describing the result of the Protocol Parser and the Pattern Matcher to the Classifier. The Classifier informs the UP Manager and sends the CLOB to the Observer. The UP Manager then instructs the Observer to publish the CLOBs to the Rule Base.
The Rule Base is executed on the CLOBs and the result is communicated to the UP Manager. The CLOBs and related Rule Base state are stored in the Handle. The UP Manager provides the result of the rule base check to the CMI that then decides to allow or to drop the connection. The CMI generates a log message and instructs the streaming engine to forward the packets to the outbound interface.

R80.10 unified access control policy – defines firewall, application control, URL filtering, mobile access and now content awareness in one policy rule. Content awareness adds visibility and control over data using data types based on content, file types and direction as the content transverses the network. In R80.10 you can also group interfaces of gateways into security zones in source and destination definitions. Core IPS protections are included in the access control policy while other IPS protections are now included in the Threat Prevention policy unifying IPS, Antivirus, Anti-Bot, Threat Extraction, and Threat Emulation into one threat prevention profile. Likewise the threat prevention policy can include multiple profiles for each security gateway to apply more granular Threat Prevention policies. Layers in the R80.10 policy are a new way to organize security. A policy can have one or more layers as its building blocks. You can use combinations of Ordered Layers, Inline Layers, and Domain Layers (in Multi-Domain environments). Build a rule base with layers, each with a set of the security rules. Layers are inspected in the order in which they are defined, giving control over the rule base flow and precedence of security functionality. If an “Accept” action is done in a layer, inspection continues in the next layer. Sub-Policies are sets of rules that you attach to specific rules. If the rule is matched, inspection continues in the sub-policy attached to the rule. If the rule is not matched, the sub-policy is skipped. For example, a sub-policy can manage a network segment or branch office.

Unified policy – In R80.10 the unified policy classifies subsequent packets against the column definitions until enough information is known to identify the traffic. Like column-based rule matching as more is known about the connection, then rules are eliminated from the matched rules array.

Example classification objects are application, access role source, access role destination, content and file.

Applications and Recommended ServicesWe have seen how R80.10 Service objects and application signatures are combined. Likewise, R80.10 applications now include recommended services such as HTTP and HTTPS in the application definition simplifying the unified policy configuration. For instance the R80.10 Facebook application definition includes the Web services where it is common to see Facebook traffic; HTTP/S over port 80/443 and HTTP/S proxy connections over port 8080. In the UI you can see the services included in the application definition.

Content Awareness

Content Awareness – (CTNT) is a new blade introduced in R80.10 as part of the new Unified Access Control Policy. Using Content Awareness blade as part of Firewall policy allows the administrator to enforce the Security Policy based on the content of the traffic by identifying files and its content. Content Awareness restricts the Data Types that users can upload or download. Content Awareness can be used together with Application Control to enforce more interesting scenarios (e.g. identify which files are uploaded to DropBox). During policy installation, the CMI Loader collects signatures from multiple sources (e.g. IPS, CTNT, APPI, …) and compiles them together into unified Pattern Matchers (PM) (one for each context – such as URL, Host header, etc.).

The CMI process calls for Content Awareness blade for install policy process:

  • Read data types and other settings information retrieved from the Security Management server.
  • Registered to FileApp contexts.
  • Load all Data Types signatures and CPcodes into CMI.
  • Get the latest list of supported file types.
  • Download all policy information to the kernel.

Afterwards, FileApp parser updates the File Signatures (file type identification method) to its latest version to support new file types.

FileApp  – is able to extract text from Microsoft Office 2007 and above files (.docx, .pptx, .xlsx, …), .zip/.gzip and text files.  For other file types (such as .pdf), FileApp sends the file to User Mode for extraction.

HTTPS – Inspection

Check Point’s Active Streaming infrastructure (CPAS) supplies applications above it the means of handling the TCP data stream, without having to care about the implementation below (e.g. 3 way handshake enforcement, retransmissions, checksums, etc.). CPAS, as opposed to PSL, supplies means of modifying the data passed, such as enabling the changing of data, removing parts of it, and even injecting completely new data. These capabilities where once achieved through the Security Servers. This included folding the connection to the firewall and having context switches to and from user-space. Since CPAS is implemented completely in the kernel, there is no more need for context switches, hence a performance increase. In order to inspect HTTPS encrypted traffic, we implement man-in-the-middle on the SSL protocol. The Security Gateway poses as a client with the server, and as a server with the client (for this purpose the Security Gateway creates a fake server certificate with all fields equals to the origin except the public key, issuer, issuer signature and CRL DP). Thus the Security Gateway creates two different sets of keys: one (CF key) to encrypt/decrypt client side traffic, another (SF key) to encrypt/decrypt server side traffic.

The HTTPS Inspection RuleBase runs mostly in the kernel. The enforcement is done completely in the kernel, while policy installation is done partially in the kernel and partially in user space. There is no dedicated process.

SSL Inspection requires CPAS streaming to be initialized. CPAS (active) streaming is a much more resource-consuming infrastructure than PSL (passive) streaming, therefore we try to avoid CPAS streaming initialization, as soon as possible. In order to avoid CPAS streaming initialization, when we do not really need it, we run HTTPS Inspection rulebase twice on the same connection.

The first time it is run on the SYN packet, as part of the Security Rulebase execution. Thus, if HTTPS Inspection Rulebase returns NO MATCH, then SSL Inspection will not influence the steaming type decision (PSL will be used in most cases), but if HTTPS Inspection Rulebase returns MATCH/POSSIBLE MATCH (we cannot make final decision), then active (CPAS) streaming will be initialized.

The second time it is run on the Client Hello packet (https_inspection_exe_rulebase function). This time, we make the final match (URL is taken from DN cache or from previous CONNECT request), calculate the action that should be performed (according to action from the matched rule, blades defined on the matched rule and exceptions) and perform the action (INSPECT/BYPASS) on the connection.

Connection could be held during HTTPS Inspection rulebase execution due to Identity Awareness (IDA) or RAD/URL Filtering request for a sync execution.

Anti-Bot and Anti-Virus

Malware detection (AntiBot and AntiVirus) –  Check Point’s comprehensive Threat Prevention solution offers a multi-layered, pre- and post-infection defence approach and a consolidated platform that enables enterprise security to deal with modern malware:

  • Anti-Virus – Pre-infection detection and blocking of malware at the gateway. The Anti-Virus Software Blade is continuously updated from ThreatCloud. It detects and blocks malware by correlating multiple detection engines before users are affected.
  • Anti-Bot – Post-infection detection of bots on hosts. Prevents bot damages by blocking bot C&C (Command and Control) communications. The Anti-Bot Software Blade is continuously updated from ThreatCloud, a collaborative network to fight cybercrime. Anti-Bot discovers infections by correlating multiple detection methods.

AntiBot – A bot is malicious software that can invade your computer. There are many infection methods. These include opening attachments that exploit a vulnerability and accessing a web site that results in a malicious download.

One bot can often create multiple threats. Bots are frequently used as part of Advanced Persistent Threats (APTs) where cyber criminals try to damage individuals or organizations. The Anti-Bot Software Blade detects and prevents these bot and botnet threats. A botnet is a collection of compromised and infected computers.

The Anti-Bot Software Blade uses these procedures to identify bot infected computers:

  • Identify the C&C addresses used by criminals to control bots – These web sites are constantly changing and new sites are added on an hourly basis. Bots can attempt to connect to thousands of potentially dangerous sites. It is a challenge to know which sites are legitimate and which are not.
  • Identify the communication patterns used by each botnet family – These communication fingerprints are different for each family and can be used to identify a botnet family. Research is done for each botnet family to identify the unique language that it uses. There are thousands of existing different botnet families and new ones are constantly emerging.
  • Identify bot behavior – Identify specified actions for a bot such as, when the computer sends spam or participates in DoS attacks.

AntiVirus – Malware is a major threat to network operations that has become increasingly dangerous and sophisticated. Examples include worms, blended threats (combinations of malicious code and vulnerabilities for infection and dissemination) and Trojans.

The Anti-Virus Software Blade scans incoming and outgoing files to detect and prevent these threats. It also gives pre-infection protection from malware contained in these files.

The Anti-Virus Software Blade:

  • Identifies malware in the organization using the ThreatSpect engine and ThreatCloud repository:
    • Prevents malware infections from incoming malicious files types (Word, Excel, PowerPoint, PDF, etc.) in real-time. Incoming files are classified on the gateway and the result is then sent to the ThreatCloud repository for comparison against known malicious files, with almost no impact on performance.
    • Prevents malware download from the internet by preventing access to sites that are known to be connected to malware. Accessed URLs are checked by the gateway’s caching mechanisms or sent to the ThreatCloud repository to determine if they are permissible or not. If not, the attempt is stopped before any damage can take place.
  • Uses the ThreatCloud repository to receive binary signature updates and query the repository for URL reputation and Anti-Virus classification.

ThreadSpect Engine and ThreadCloud – The ThreatSpect engine is a unique multi-tiered engine that analyzes network traffic and correlates information across multiple layers to find bots and other malware. It combines information on remote operator hideouts, unique botnet (a collection of compromised computers) traffic patterns and behavior to identify thousands of different botnet families and outbreak types.

Reputtion Layer – Analyzes the reputation of URLs, IP addresses and external domains that computers in the organization access. The engine searches for the known or suspicious activity, such as Command and Control (C&C).

The Reputation layer classifies per connection:

  • IP address – from handle first packet before security rule base. Only in kernel, not in the cloud.
  • DNS – host from DNS request (for both TCP and UDP)
  • URL – complete URL from the HTTP request

After the discovery of bot infected machines, the Anti-Bot Software Blade blocks outbound communication to C&C sites based on the Rule Base.

This classification has 3 stages:

  1.       First, every URL is searched in the local database, located in $FWDIR/conf/urlrep.eng file that contains some malware data – commonly used signatures, URLs, and their related reputations.
    Local database is loaded to the kernel, and compiled to one Pattern Matcher (PM) that is executed on the incoming URLs to find a match.
    If the URL is found there, a response to the client is returned.
    If there is no match against local database, continue to next Step.
  2.       RAD (Resource ADvisor) cache (for DNS and URL only), that gives answers to 99% of URL reputation requests.
  3.       RAD (Resource ADvisor) service in the cloud (for DNS and URL only)

If the URL was not found in the cache, a request is sent out to RAD and a response is returned (asynchrony) back to the client, and the relevant data is kept in the cache.

Anti-Bot Resource Classification mode for DNS is overridden to “background” on the Security Gateway. These settings override the existing default settings in the SmartDashboard.

The Resource Classification settings for Anti-Bot are now configurable from the Security Gateway using the malware_config file.

Using the Security Gateway configuration file provides more granularity and divide classification to DNS, HTTP and SMTP.

There are three values for each option:

  • hold – for hold classification
  • bg – for background classification
  • policy – for classification according to Security policy

The default values for HTTP and SMTP is policy, but for DNS the default is now background.

Other Security Modules

Coming soon:

  • Application Control
  • URL Filtering
  • IPS
  • Threat Emulation and Protection
References

SecureKnowledge: Application Control 

SecureKnowledge: URL Filtering 

SecureKnowledge: Content Awareness (CTNT) 

SecureKnowledge: IPS 

SecureKnowledge: Anti-Bot and Anti-Virus 

SecureKnowledge: Threat Emulation 

SecureKnowledge: Best Practices – Security Gateway Performance 

Download Center: R80.10 Next Generation Threat Prevention Platforms

Download Center: R77 Security Gateway Packet Flow

Download Center: R77 Security Gateway Architecture

Support Center: Check Point Security Gateway Architecture and Packet Flow 

Checkmates: Check Point Threat Prevention Packet Flow and Architecture

Checkmates: Infinity NGTP architecture  

Checkmates R80.x Security Gateway Architecture (Logical Packet Flow)

Security Gateway Packet Flow and Acceleration – with Diagrams