{"id":20,"date":"2019-02-01T15:32:36","date_gmt":"2019-02-01T15:32:36","guid":{"rendered":"http:\/\/www.ankenbrand24.de\/?page_id=20"},"modified":"2019-02-01T20:40:11","modified_gmt":"2019-02-01T20:40:11","slug":"fw-monitor","status":"publish","type":"page","link":"https:\/\/www.ankenbrand24.de\/index.php\/articles\/articles-check-point\/fw-monitor\/","title":{"rendered":"R80.20 &#8211; fw monitor"},"content":{"rendered":"\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Introduction<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p>This document describes the content inspection in a Check Point R80.10 and\nabove gateways. Context Management Infrastructure (CMI) is the\n&#8220;brain&#8221; of the content inspection and use more different modules (CMI\nLoader, PSL vs. PXL, Protocol Parsers, Pattern Matcher, Protections and new in\nR80.10 NGTP Architecture) for content inspection.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Chapter<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-3041-r80x-security-gateway-architecture-logical-packet-flow\">R80.x Security Gateway Architecture (Logical Packet\nFlow)<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-3073-r80x-security-gateway-architecture-content-inspection\">R80.x Security Gateway Architecture (Content\nInspection)<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-2740-basic-ports-and-modul-communication\">R80.x Ports Used for Communication by Various Check\nPoint Modules<\/a>&nbsp;<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>What\u2019s new in R80.10 and\n   above:<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<ul><li>UP Manager<\/li><li>Unified policys<\/li><li>NGTP Architecture<\/li><li>Content Awareness\n     (CTNT)<\/li><\/ul>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Context Management\n   Infrastructure and and Basic Components<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<figure class=\"wp-block-image\"><img src=\"\" alt=\"https:\/\/community.checkpoint.com\/servlet\/JiveServlet\/downloadImage\/102-3073-17-68916\/pastedImage_1.png\"\/><\/figure>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/servlet\/JiveServlet\/showImage\/102-3073-17-68916\/pastedImage_1.png\"><strong><em><\/em><\/strong><\/a><\/p>\n\n\n\n<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\nThis picture is from Check Point. I will update my original picture in the\nnext days.<\/p>\n\n\n\n<p><strong><em>Context Management Infrastructure<\/em><\/strong> &#8211; The Context Management Infrastructure (CMI) is the &#8220;<strong>brain<\/strong>&#8221;\nof the content inspection. It coordinates different components, decides which\nprotections should run on a certain packet, decides the final action to be\nperformed on the packet and issues an event log.<br>\nCMI separates parsers and protections. Protection is a set of signatures or\/and\nhandlers, where<\/p>\n\n\n\n<ul><li>Signature &#8211; a malicious pattern that is searched\n     for<\/li><li>Handler &#8211; INSPECT code that performs more complex\n     inspection<\/li><\/ul>\n\n\n\n<p>CMI is a way to connect and manage parsers and protections. Since they are\nseparated, protections can be added in updates, while performance does not\ndepend on the number of active protections. Protections are usually written per\nprotocol contexts &#8211; they get the data from the contexts and validate it against\nrelevant signatures. Based on the policy, the CMI\ndetermines which protections should be activated on every context discovered by\na protocol parser. If policy dictates that no protections should run, then the\nrelevant parsers on this traffic are bypassed in order to improve performance\nand reduce potential false positives. <\/p>\n\n\n\n<p><strong><em>CMI Loader<\/em><\/strong> &#8211; collects\nsignatures from multiple sources (e.g. IPS, Application Control,&#8230;) and\ncompiles them together into unified Pattern Matchers (PM).<\/p>\n\n\n\n<p><strong><em>Stream Assembly<\/em><\/strong><strong> &#8211;<\/strong> In order to identify more sophisticated threats we need to do additional\ninspection of the initial and subsequent packets within a session. The\nStreaming Engine processes the individual packet chains, creates an ordered\npacket stream and directly performs a number of security functions on the\nstream. One is to validate the TCP stream, e.g. looking for retransmissions\nwith modified data or TCP connection packets with no handshake. The streaming\nengine passes assembled stream to the protocol parsers. <\/p>\n\n\n\n<p>The engine has two modes depending on the nature of the traffic. In the\npassive mode there is limited opportunity to modify the traffic stream itself.\nThe active mode however, is able to modify the connection. This mode\nessentially proxies the TCP connection and is necessary when performing HTTPS\nman-in-the-middle inspection. Active streaming also facilitates timing and\nbuffering when it\u2019s necessary to inspect content such as large files.<\/p>\n\n\n\n<p><strong><em>Streaming serves<\/em><\/strong> &#8211; an\nimportant function in the NGTP software architecture. The streaming process\ncreates an ordered packet stream and directly performs a number of security\nfunctions on the stream. NGTP can assemble packets into a stream in two ways,\npassive or active, depending on the nature of the traffic. Each has advantages\nand disadvantages. The passive mode gives little opportunity for modifying the\ntraffic stream. In contrast, the active mode can modify the connection. Active\nmode essentially proxies the TCP connection and is necessary when performing\nHTTPS inspection. Active streaming also facilitates timing and buffering when\ninspecting content such as large files. Keeping the goals of integrated, high\nsecurity effectiveness and performance in mind, Check Point chose to provide\nthe option to do passive and active streaming, which provides the best balance\nof security and optimized performance based on actual usage conditions.<\/p>\n\n\n\n<p><strong><em>PSL &#8211;<\/em><\/strong> Packets may\narrive out of order or may be legitimate retransmissions of packets that have\nnot yet received an acknowledgment. In some cases a retransmission may also be\na deliberate attempt to evade IPS detection by sending the malicious payload in\nthe retransmission. Security Gateway ensures that only valid packets are\nallowed to proceed to destinations. It does this with Passive Streaming Library (PSL)\ntechnology.<\/p>\n\n\n\n<ul><li>PSL is an infrastructure layer, which provides\n     stream reassembly for TCP connections.<\/li><li>The gateway makes sure that TCP data seen by the\n     destination system is the same as seen by code above PSL.<br>\n     This layer handles packet reordering, congestion handling and is\n     responsible for various security aspects of the TCP layer such as handling\n     payload overlaps, some DoS attacks and others.<\/li><li>The PSL layer is capable of receiving packets\n     from the firewall chain and from SecureXL module.<\/li><li>The PSL layer serves as a middleman between the\n     various security applications and the network packets. It provides the\n     applications with a coherent stream of data to work with, free of various\n     network problems or attacks<\/li><li>The PSL infrastructure is wrapped with well\n     defined APIs called the Unified Streaming APIs which are used by the\n     applications to register and access streamed data.<\/li><\/ul>\n\n\n\n<p>For more details &#8211;&nbsp;how a connection comes into the PSL modul &#8211; see\narticle: <\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-3041-r80x-security-gateway-architecture-logical-packet-flow\">R80.x Security Gateway Architecture (Logical Packet\nFlow)<\/a><\/p>\n\n\n\n<p><strong><em>PXL<\/em><\/strong><strong> <\/strong>&#8211; Technology name for combination of SecureXL and PSL.<\/p>\n\n\n\n<p><strong><em>Protocol\nParsers<\/em><\/strong> &#8211; Protocols\ninclude HTTP, SMTP, DNS, IMAP, Citrix, and many others. Protocol parser\ninstances register with the streaming engine in order to receive ordered\nstreams of data, both client-to-server (C2S) as well as server-to-client (S2C)\nstreams. They test for conformance to RFCs and look for anomalies. An example\nof a protocol anomaly would be where, for example, there is a non-existing HTTP\nmethod instead of GET, POST etc. in the HTTP header. <\/p>\n\n\n\n<p>Another job\nof the parsers is to normalize content. The parser will normalize this content\nbefore passing the URL to the protections for inspection. The parsers main\npurpose is to extract \u2018contexts\u2019 from the streams to prepare for the next level\nof inspection. The content is normalized before inspection to thwart attempts\nto evade detection. The protocol parser detects and prevents protocol\nanomalies. The parsers main purpose is to extract \u2018contexts\u2019 from the streams\nto prepare for the next level of inspection. <\/p>\n\n\n\n<p><strong><em>Pattern\nMatcher<\/em><\/strong><strong> <\/strong>&#8211; Security modules each have a\ndistinct function and they register with the CMI to receive particular context\ntypes. The CMI Loader maintains a register table of all security modules and\nthe contexts they want to inspect. This registration process occurs at policy\ninstall time. During policy installation, the CMI collects signatures from\nmultiple sources (e.g. IPS and Application Control) and compiles them together\ninto Pattern Matchers (PM) (one for each context &#8211; such as URL, Host header\netc.). The CMI Pattern Matcher quickly identifies harmless packets, common\nsignatures in malicious packets, and does a second level analysis when needed\nto reduce false positives. The engine uses a two tiered inspection process. The\nfirst tier quickly filters out the vast majority of traffic which is clearly harmless\nby looking for signatures that are simple to find at a low CPU cost. If the\nfirst tier identifies a common attack signature a second level analysis is\ndone, thus increasing the confidence that there is indeed an attack. The first\ntier will never decide on its own that a packet is malicious. It can only\ndecide that a packet is clearly harmless. The second tier can also be\ninstructed to activate further inspection using INSPECT technology when some\npatterns are matched.<\/p>\n\n\n\n<p>The Pattern\nMatcher is a fundamental engine within the enforcement architecture.<\/p>\n\n\n\n<ul><li>Pattern Matcher quickly\n     identifies harmless packets, common signatures inmalicious packets, and\n     does a second level analysis to reduce false positives.<\/li><li>Pattern Matcher engine provides\n     the ability to find regular expressions on a stream of data using a two\n     tiered inspection process: <ul><li>The first tier quickly filters\n      out the vast majority of traffic which is clearly harmless by looking for\n      signatures that are simple to find at a low CPU cost.<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>If the first tier identifies a common attack signature\nit passes the connection to the second tier to do a second level analysis, thus\nincreasing the confidence that there is indeed an attack. <\/p>\n\n\n\n<ul><li>The first tier will never\n      decide on it\u2019s own that a packet is malicious. It can only decide that a\n      packet is clearly harmless.<\/li><li>The second tier can also be\n      instructed to activate further inspection using INSPECTv2 technology when\n      some patterns are matched.<\/li><\/ul>\n\n\n\n<p><strong><em>Protections<\/em><\/strong>&nbsp; &#8211; are composed of signatures\nthat identify malicious activity. There are three types of signatures; <\/p>\n\n\n\n<ul><li>Regular expression like\n     patterns <\/li><li>INSPECT code <\/li><li>Compound Signature\n     Identification (CSI) <\/li><\/ul>\n\n\n\n<p>Regex\nsignatures are done first followed by INSPECT and CSI if needed. CSI can\naddress signatures on multiple parts of a packet, multiple parts of the\nprotocols such as URL and an HTTP header, multiple parts of a connection, such\nas CIFS request and response, or multiple connections, such as VoIP control and\ndata connections. In its operation, CSI constructs complex signatures that are\ntriggered only if a certain logical condition over multiple contexts is\nmatched. The logical expression can use AND, OR, NOT or ORDERED-AND to\nconstruct the logical expression.<\/p>\n\n\n\n<p><strong><em>Content\nSecurity Policy and Inspection<\/em><\/strong><strong> &#8211; <\/strong>When enabling advanced security features like\nApplication Control, URL Filtering, Content Awareness, IPS, Anti-Bot, Antivirus\nand SandBlast Threat Emulation (sandboxing); the security gateway inspects\ncontent using the contexts derived from the protocol parser. The gateway\u2019s\nlocal cache is augmented with real-time cloud updates and zero-day threat\nprotection.<\/p>\n\n\n\n<p>During\npolicy installation, signatures are compiled into Pattern Matchers (PM) with\none PM for each context such as URL, Host header etc. The PM quickly identifies\nharmless packets, common signatures in malicious packets, and if needed, does a\nsecond-level analysis to reduce false positives. The engine uses a two-tiered\ninspection process. The first tier quickly filters out the vast majority of\ntraffic, which is clearly harmless, by looking for signatures that are simple\nto find at a low CPU cost. If the first tier identifies a common attack\nsignature, it passes the connection to the second tier to do a second level analysis.\nThis increases confidence there is indeed an attack. <\/p>\n\n\n\n<p>It is worth\nnoting that in some cases, the determination is a simple comparison. For\ninstance, minimal processing time is needed to check an IP, a URL, a domain, or\na file checksum against a known list. These comparisons are done first. A\nContext Management Infrastructure (CMI) connects parsers with pattern matchers.\nCMI determines which protections should be activated on every context\ndiscovered by a protocol parser. If policy dictates that no protections should\nrun, then the relevant parsers on this traffic are bypassed in order to improve\nperformance and reduce potential false positives. For instance, if the IPS\npolicy is activating server protections only, then the HTTP parser will not\nanalyze the server to client (S2C) traffic. After the security module analysis\nis done, their verdict is passed to the CMI to perform the final action to be\ndone on the various contexts.<\/p>\n\n\n\n<p><strong><em>Cache with\nCloud Backup<\/em><\/strong><strong> &#8211; <\/strong>After a match by the Pattern\nMatcher, the CMI is notified by the relevant module like Application Control,\nURL Filtering, Antivirus, Anti-Bot and Threat Emulation that its signature was\nmatched. Additional processing is done as needed by the security module. For\ninstance Application Control retrieves all the data regarding the application\n(its categories, priority, etc.) from a cache based on the signature that was\nmatched. If a match is not found or social network widget detection is needed,\nthen the&nbsp; cloud service is checked. URL Filtering is another example where\nif the context is not found in cache, then the&nbsp; cloud service is checked.\nURL categorization occurs mostly in the kernel. When not found in the local\ncache, the&nbsp; cloud service is checked and the result is then cached in the\nkernel. <\/p>\n\n\n\n<p>&nbsp;<br>\nFor instance: <\/p>\n\n\n\n<ul><li><strong>Application Control <\/strong>retrieves all the data\n     regarding the application (its categories, priority, etc.) from a cache\n     based on the signature that was matched. If a match is not found or\n     social-network widget detection is needed, then the&nbsp; cloud service is\n     checked and the cache is updated with the result. <\/li><li><strong>URL Filtering <\/strong>checks for the URL category in\n     the local cache. If not found, then the&nbsp; cloud service is checked.\n     The cache is then updated with the result. <\/li><li><strong>Threat Emulation <\/strong>is a special case where the Pattern\n     Matcher can be bypassed. If the checksum of a file is not cached, then the\n     sandbox needs to receive a complete file. The protocol parser extracts the\n     file and sends the file to our cloud service for processing where compute,\n     disk and memory are virtually unlimited. If the protocol requires\n     immediate delivery as in the case of HTTP\/S, we offer user agents to\n     notify the user and deliver only safe content to the user while the\n     emulation happens in the background. Newly discovered threats are added to\n     the local cache and sent to the cloud database to protect other Check\n     Point platforms.<\/li><\/ul>\n\n\n\n<p><strong><em>File\nHandling<\/em><\/strong><strong> &#8211; <\/strong>In some situations we need to\ninspect an entire file for malicious behavior. In these cases the file is sent\ndirectly to Threat Emulation, Threat Extraction and Antivirus for processing.\nIf the SHA1 of the file is not cached, then these modules may need to receive a\ncomplete file. Files can be extracted from streams and security gateways have\nthe option to act as a mail relay (Mail Transfer Agent), which allows us to\ninspect encrypted SMTP traffic over TLS. With SMTP inspection users don\u2019t\nnotice delays whilst inspection like that required in Threat Emulation\n(sandboxing) of large or complex attachments is carried out.<\/p>\n\n\n\n<p>When files\nare transferred over HTTP\/HTTPS, then users may notice a delay while Threat\nEmulation occurs. SandBlast Threat Extraction technology eliminates threats by\nremoving exploitable content and reconstructing documents using known safe\nelements. Safe content is delivered to the user. Users are allowed access to\noriginal files after Threat Emulation completes its analysis.<\/p>\n\n\n\n<p><strong><em>Final\nDecision<\/em><\/strong><em> &#8211; <\/em>After the security module analysis\nis done, their verdict is passed to the CMI to perform the final action. The\nCMI is responsible for the final action to be performed on the packet, given\nseveral considerations. The considerations include: <\/p>\n\n\n\n<ul><li>Activation status of the\n     protection. e.g. IPS prevent, detect or inactive <\/li><li>Exceptions either on traffic or\n     on IPS protection <\/li><li>Bypass mode status (the\n     software fail open capability) <\/li><li>Troubleshooting mode status <\/li><li>Are we protecting the internal\n     network only or all traffic <\/li><\/ul>\n\n\n\n<p><strong><em>UserCheck<\/em><\/strong><strong> &#8211; <\/strong>In the Application Control, URL\nFiltering and DLP security policy, the action Ask User presents users with a\nUserCheck dialog window prompting them to confirm they wish to complete the\nconnection and if needed provide a reason. For example they may be visiting a\nrisky site or sending confidential content to an external recipient. Depending\nupon their response the connection will be allowed or denied.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Unified policies<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p>Check Point R80.10, part of Check Point Infinity, takes security to new\nlevels, merging security into a single system which enables administrators to\neasily identify security risks across the organization. <\/p>\n\n\n\n<p>Unified policies in R80.10 gateways enables organizations to translate\ntheir security definitions into a simple set of rules, which then streamline\npolicy administration and enforcement throughout the organization. Policy\nlayers provide the ability to separate the policy into independent segments,\nwhich can be independently managed and automated. In the kernel the rule base\nis represented as a database table. This enables the gateway security policy to\nautomatically adapt as dynamic objects change, providing simple automated\nsecurity across physical, virtual and cloud environments.<\/p>\n\n\n\n<p><strong><em>NGTP Architecture &#8211;<\/em><\/strong> Session-based\nprocessing enforces advanced access control and threat detection and prevention\ncapabilities. To do this we assemble packets into a stream, parse the stream\nfor relevant contexts and then security modules inspect the content. When\npossible, a common pattern matcher does simultaneous inspection of the content\nfor multiple security modules. In multi-core systems this processing is\ndistributed amongst the cores to provide near linear scalability on each\nadditional core. <\/p>\n\n\n\n<p>Security modules use a local cache to detect known threats. This local\ncache is backed up with real-time lookups of an&nbsp; cloud service. The result\nof cloud lookups are then cached in the kernel for subsequent lookups. Cloud\nassist also enhances unknown threat detection and prevention. In particular a\nfile whose signature is not known in a local cache is sent to our cloud service\nfor processing where compute, disk and memory are virtually unlimited. Our\nsandboxing technology, SandBlast Threat Emulation, identifies threats in their\ninfancy before malware has an opportunity to deploy and evade detection. Newly\ndiscovered threats are sent to the cloud database to protect other Check Point\nconnected gateways and devices. When possible, active content is removed from\nfiles which are then sent on to the user while the emulation is done. <\/p>\n\n\n\n<p><strong><em>UP Manager<\/em><\/strong> &#8211; The UP Manager controls\nall interactions of the components and interfaces with the Context Management\nInfrastructure (CMI) Loader, the traffic director of the CMI. The UP Manager\nalso has a list of Classifiers that have registered for \u201cfirst packets\u201d and\nuses a bitmap to instruct the UP Classifier to execute these Classifier Apps to\nrun on the packet. The \u201cfirst packets\u201d arrive directly from the CMI. Parsing of\nthe protocol and streaming are not needed in this stage of the connection. For\n\u201cfirst packets\u201d the UP Manager executes the rule base. <\/p>\n\n\n\n<p><strong><em>Classifier<\/em><\/strong> &#8211; When the \u201cfirst packet\u201d rule base\ncheck is complete Classifiers initiate streaming for subsequent packets in the\nsession. The \u201cfirst packet\u201d rule base check identifies a list of rules that\npossibly may match and a list of <strong>classifier objects (CLOBs)<\/strong> that are\nrequired to complete the rule base matching process. The Classifier reads this\nlist and generates the required CLOBs to complete the rule base matching. Each\nClassifier App executes on the packet and tells the result of the CLOB to the\nUP Manager. The CMI then tells the Protocol Parser to enable streaming. <\/p>\n\n\n\n<p>In some cases Classifier Apps do not require streaming, e.g. the first\npacket information is sufficient. Then the rule base decision can be done on\nthe first packet. <\/p>\n\n\n\n<ul><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n     Dynamic Objects <\/li><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n     Domain Objects <\/li><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n     Only the firewall is enabled <\/li><\/ul>\n\n\n\n<p>On subsequent packets the Classifier can be contacted directly from the CMI\nusing the CMI Loader infrastructure, e.g. when the Pattern Matcher has found a\nmatch it informs the CMI it has found application xyz. The CMI Loader passes\nthis information to the Classifier. The Classifier runs the Classification Apps\nto generate CLOBs required for Application Control and sends the CLOBs to the\nObserver. <\/p>\n\n\n\n<p><strong><em>Observer <\/em><\/strong>&#8211; The Observer decides if enough\ninformation is known to publish a CLOB to the security policy. CLOBs are\nobserved in the context of their transaction and the connection that the\ntransaction belongs to. The Observer may request more CLOBs for a dedicated\npacket from the Classifier or decides that it has sufficient information about\nthe packet to execute the rule base on the CLOB, e.g. if a file type is needed\nfor Content Awareness and the gateway hasn\u2019t yet received the S2C response\ncontaining the file. Executing the rule base on a CLOB is called \u201cpublishing a\nCLOB\u201d. The Observer may wait to receive more CLOBs that belong to the same\ntransaction before publishing the CLOBs. <\/p>\n\n\n\n<p><strong><em>Security Policy<\/em><\/strong> &#8211; The Security Policy\nreceives the CLOB published by the Observer. The CLOB includes a description of\nthe Blade it belongs to so that matching can be performed on a column basis.\nThe security policy saves the current state on the transaction Handle; either\nto continue the inspection or final match. <\/p>\n\n\n\n<p>The first packets are received directly from the UP Manager. Subsequent\npackets are received by the rule base from the Observer.<\/p>\n\n\n\n<p><strong><em>Handle<\/em><\/strong> &#8211; Each connection may\nconsist of several transactions. Each transaction has a Handle. Each Handle\ncontains a list of published CLOBs. The Handle holds the state of the security\npolicy matching process. The Handle infrastructure component stores the rule\nbase matching state related information. <\/p>\n\n\n\n<p><strong><em>Subsequent Packets<\/em><\/strong> &#8211; Subsequent packets are handled by the\nstreaming engine. The streaming engine notifies the Classifier to perform the\nclassification. The Classifier will notify the UP Manager about the performed\nclassification and pass the CLOBs to the Observer. The CLOBs will then be\nreceived by the Observer that will need to wait for information from the CMI.\nThe CMI sends the information describing the result of the Protocol Parser and\nthe Pattern Matcher to the Classifier. The Classifier informs the UP Manager\nand sends the CLOB to the Observer. The UP Manager then instructs the Observer\nto publish the CLOBs to the Rule Base. <br>\nThe Rule Base is executed on the CLOBs and the result\nis communicated to the UP Manager. The CLOBs and related Rule Base state are\nstored in the Handle. The UP Manager provides the result of the rule base check\nto the CMI that then decides to allow or to drop the connection. The CMI\ngenerates a log message and instructs the streaming engine to forward the\npackets to the outbound interface.<br>\n<br>\n<strong><em>R80.10 unified access control policy<\/em><\/strong> &#8211; defines firewall,\napplication control, URL filtering, mobile access and now content awareness in\none policy rule. Content awareness adds visibility and control over data using\ndata types based on content, file types and direction as the content\ntransverses the network. In R80.10 you can also group interfaces of gateways\ninto security zones in source and destination definitions. Core IPS protections\nare included in the access control policy while other IPS protections are now\nincluded in the Threat Prevention policy unifying IPS, Antivirus, Anti-Bot,\nThreat Extraction, and Threat Emulation into one threat prevention profile.\nLikewise the threat prevention policy can include multiple profiles for each\nsecurity gateway to apply more granular Threat Prevention policies. Layers in\nthe R80.10 policy are a new way to organize security. A policy can have one or\nmore layers as its building blocks. You can use combinations of Ordered Layers,\nInline Layers, and Domain Layers (in Multi-Domain environments). Build a rule\nbase with layers, each with a set of the security rules. Layers are inspected\nin the order in which they are defined, giving control over the rule base flow\nand precedence of security functionality. If an &#8220;Accept&#8221; action is\ndone in a layer, inspection continues in the next layer. Sub-Policies are sets\nof rules that you attach to specific rules. If the rule is matched, inspection\ncontinues in the sub-policy attached to the rule. If the rule is not matched,\nthe sub-policy is skipped. For example, a sub-policy can manage a network\nsegment or branch office.<\/p>\n\n\n\n<p><strong><em>Unified policy<\/em><\/strong> &#8211; In R80.10 the unified policy classifies\nsubsequent packets against the column definitions until enough information is\nknown to identify the traffic. Like column-based rule matching as more is known\nabout the connection, then rules are eliminated from the matched rules array. <\/p>\n\n\n\n<p>Example classification objects are application, access role source, access\nrole destination, content and file. <\/p>\n\n\n\n<p><strong><em>Applications and Recommended Services<\/em><\/strong><strong> &#8211; <\/strong>We have seen how R80.10\nService objects and application signatures are combined. Likewise, R80.10\napplications now include recommended services such as HTTP and HTTPS in the\napplication definition simplifying the unified policy configuration. For\ninstance the R80.10 Facebook application definition includes the Web services where\nit is common to see Facebook traffic; HTTP\/S over port 80\/443 and HTTP\/S proxy\nconnections over port 8080. In the UI you can see the services included in the\napplication definition.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Content Awareness<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p><strong><em>Content\nAwareness<\/em><\/strong><strong> &#8211; (CTNT)<\/strong> is a <strong>new<\/strong> blade introduced <strong>in<\/strong>\n<strong>R80.10<\/strong> as part of the new Unified Access Control Policy. Using Content\nAwareness blade as part of Firewall policy allows the administrator to enforce\nthe Security Policy based on the content of the traffic by identifying files\nand its content. Content Awareness restricts the Data Types that users can\nupload or download. Content Awareness can be used together with Application\nControl to enforce more interesting scenarios (e.g. identify which files are\nuploaded to DropBox). During policy installation, the CMI Loader collects\nsignatures from multiple sources (e.g. IPS, CTNT, APPI, &#8230;) and compiles them\ntogether into unified Pattern Matchers (PM) (one for each context &#8211; such as\nURL, Host header, etc.).<\/p>\n\n\n\n<p>The CMI\nprocess calls for Content Awareness blade for install policy process:<\/p>\n\n\n\n<ul><li>Read data types and other\n     settings information retrieved from the Security Management server.<\/li><li>Registered to FileApp contexts.<\/li><li>Load all Data Types signatures\n     and CPcodes into CMI.<\/li><li>Get the latest list of\n     supported file types.<\/li><li>Download all policy information\n     to the kernel.<\/li><\/ul>\n\n\n\n<p>Afterwards,\nFileApp parser updates the File Signatures (file type identification method) to\nits latest version to support new file types.<\/p>\n\n\n\n<p><strong><em>FileApp<\/em><\/strong> &nbsp;&#8211; is able to extract text\nfrom Microsoft Office 2007 and above files (<em>.docx, .pptx, .xlsx<\/em>, &#8230;), <em>.zip\/.gzip<\/em>\nand text files. &nbsp;For other file types (such as <em>.pdf<\/em>), FileApp sends\nthe file to User Mode for extraction.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>HTTPS &#8211; Inspection<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p>Check\nPoint&#8217;s Active Streaming infrastructure (CPAS) supplies applications above it\nthe means of handling the TCP data stream, without having to care about the\nimplementation below (e.g. 3 way handshake enforcement, retransmissions,\nchecksums, etc.). CPAS, as opposed to PSL, supplies means of modifying the data\npassed, such as enabling the changing of data, removing parts of it, and even\ninjecting completely new data. These capabilities where once achieved through\nthe Security Servers. This included folding the connection to the firewall and\nhaving context switches to and from user-space. Since CPAS is implemented\ncompletely in the kernel, there is no more need for context switches, hence a\nperformance increase. In order to inspect HTTPS encrypted traffic, we implement\nman-in-the-middle on the SSL protocol. The Security Gateway poses as a client\nwith the server, and as a server with the client (for this purpose the Security\nGateway creates a fake server certificate with all fields equals to the origin\nexcept the public key, issuer, issuer signature and CRL DP). Thus the Security\nGateway creates two different sets of keys: one (CF key) to encrypt\/decrypt\nclient side traffic, another (SF key) to encrypt\/decrypt server side traffic.<br>\n<br>\nThe HTTPS Inspection RuleBase runs mostly in the kernel. The enforcement is\ndone completely in the kernel, while policy installation is done partially in\nthe kernel and partially in user space. There is no dedicated process. <\/p>\n\n\n\n<p>SSL\nInspection requires CPAS streaming to be initialized. CPAS (active) streaming\nis a much more resource-consuming infrastructure than PSL (passive) streaming,\ntherefore we try to avoid CPAS streaming initialization, as soon as possible.\nIn order to avoid CPAS streaming initialization, when we do not really need it,\nwe run HTTPS Inspection rulebase twice on the same connection.<\/p>\n\n\n\n<p>The <strong>first\ntime<\/strong> it is run on the SYN packet, as part of the Security Rulebase\nexecution. Thus, if HTTPS Inspection Rulebase returns NO MATCH, then SSL\nInspection will not influence the steaming type decision (PSL will be used in\nmost cases), but if HTTPS Inspection Rulebase returns MATCH\/POSSIBLE MATCH (we\ncannot make final decision), then active (CPAS) streaming will be initialized.<\/p>\n\n\n\n<p>The <strong>second\ntime<\/strong> it is run on the Client Hello packet (https_inspection_exe_rulebase\nfunction). This time, we make the final match (URL is taken from DN cache or\nfrom previous CONNECT request), calculate the action that should be performed\n(according to action from the matched rule, blades defined on the matched rule\nand exceptions) and perform the action (INSPECT\/BYPASS) on the connection.<br>\n<br>\nConnection could be held during HTTPS Inspection rulebase execution due to\nIdentity Awareness (IDA) or RAD\/URL Filtering request for a sync execution.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Anti-Bot and Anti-Virus<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p><strong><em>Malware\ndetection (AntiBot and&nbsp;AntiVirus)<\/em><\/strong> &#8211;&nbsp; Check Point&#8217;s comprehensive Threat Prevention\nsolution offers a multi-layered, pre- and post-infection defence approach and a\nconsolidated platform that enables enterprise security to deal with modern\nmalware:<\/p>\n\n\n\n<ul><li><strong>Anti-Virus<\/strong> &#8211; Pre-infection detection and\n     blocking of malware at the gateway. The Anti-Virus Software Blade is\n     continuously updated from ThreatCloud. It detects and blocks malware by\n     correlating multiple detection engines before users are affected.<\/li><li><strong>Anti-Bot<\/strong> &#8211; Post-infection detection of\n     bots on hosts. Prevents bot damages by blocking bot C&amp;C (Command and\n     Control) communications. The Anti-Bot Software Blade is continuously\n     updated from ThreatCloud, a collaborative network to fight cybercrime.\n     Anti-Bot discovers infections by correlating multiple detection methods.<\/li><\/ul>\n\n\n\n<p><strong><em>AntiBot<\/em><\/strong> &#8211; A <em>bot<\/em> is malicious\nsoftware that can invade your computer. There are many infection methods. These\ninclude opening attachments that exploit a vulnerability and accessing a web\nsite that results in a malicious download.<\/p>\n\n\n\n<p>One bot can\noften create multiple threats. Bots are frequently used as part of Advanced\nPersistent Threats (APTs) where cyber criminals try to damage individuals or\norganizations. The Anti-Bot Software Blade detects and prevents these bot and\nbotnet threats. A botnet is a collection of compromised and infected computers.<\/p>\n\n\n\n<p>The Anti-Bot\nSoftware Blade uses these procedures to identify bot infected computers:<\/p>\n\n\n\n<ul><li><strong>Identify the C&amp;C addresses\n     used by criminals to control bots &#8211;&nbsp;<\/strong>These web sites are constantly\n     changing and new sites are added on an hourly basis. Bots can attempt to\n     connect to thousands of potentially dangerous sites. It is a challenge to\n     know which sites are legitimate and which are not.<\/li><li><strong>Identify the communication\n     patterns used by each botnet family &#8211;&nbsp;<\/strong>These communication\n     fingerprints are different for each family and can be used to identify a\n     botnet family. Research is done for each botnet family to identify the\n     unique language that it uses. There are thousands of existing different\n     botnet families and new ones are constantly emerging.<\/li><li><strong>Identify bot behavior &#8211;&nbsp;<\/strong>Identify specified actions for\n     a bot such as, when the computer sends spam or participates in DoS\n     attacks.<\/li><\/ul>\n\n\n\n<p><strong><em>AntiVirus<\/em><\/strong><em> &#8211; Malware<\/em> is a major threat to network\noperations that has become increasingly dangerous and sophisticated. Examples\ninclude worms, blended threats (combinations of malicious code and\nvulnerabilities for infection and dissemination) and Trojans.<\/p>\n\n\n\n<p>The\nAnti-Virus Software Blade scans incoming and outgoing files to detect and\nprevent these threats. It also gives pre-infection protection from malware\ncontained in these files.<\/p>\n\n\n\n<p>The\nAnti-Virus Software Blade:<\/p>\n\n\n\n<ul><li>Identifies malware in the\n     organization using the ThreatSpect engine and ThreatCloud repository: <ul><li>Prevents malware infections\n      from incoming malicious files types (Word, Excel, PowerPoint, PDF, etc.)\n      in real-time. Incoming files are classified on the gateway and the result\n      is then sent to the ThreatCloud repository for comparison against known\n      malicious files, with almost no impact on performance.<\/li><li>Prevents malware download from\n      the internet by preventing access to sites that are known to be connected\n      to malware. Accessed URLs are checked by the gateway&#8217;s caching mechanisms\n      or sent to the ThreatCloud repository to determine if they are\n      permissible or not. If not, the attempt is stopped before any damage can\n      take place.<\/li><\/ul><\/li><li>Uses the ThreatCloud repository\n     to receive binary signature updates and query the repository for URL\n     reputation and Anti-Virus classification.<\/li><\/ul>\n\n\n\n<p><strong><em>ThreadSpect\nEngine and ThreadCloud<\/em><\/strong> &#8211; The ThreatSpect engine is a unique multi-tiered engine that analyzes\nnetwork traffic and correlates information across multiple layers to find bots\nand other malware. It combines information on remote operator hideouts, unique\nbotnet (a collection of compromised computers) traffic patterns and behavior to\nidentify thousands of different botnet families and outbreak types.<\/p>\n\n\n\n<p><strong><em>Reputtion\nLayer<\/em><\/strong> &#8211; Analyzes\nthe reputation of URLs, IP addresses and external domains that computers in the\norganization access. The engine searches for the known or suspicious activity,\nsuch as Command and Control (C&amp;C).<br>\n<br>\nThe Reputation layer classifies per connection:<\/p>\n\n\n\n<ul><li>IP address &#8211; from handle first\n     packet before security rule base. Only in kernel, not in the cloud.<\/li><li>DNS &#8211; host from DNS request\n     (for both TCP and UDP)<\/li><li>URL &#8211; complete URL from the\n     HTTP request<\/li><\/ul>\n\n\n\n<p>After the\ndiscovery of bot infected machines, the Anti-Bot Software Blade blocks outbound\ncommunication to C&amp;C sites based on the Rule Base.<\/p>\n\n\n\n<p>This\nclassification has 3 stages:<\/p>\n\n\n\n<ol><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First,\nevery URL is searched in the local database, located in <em>$FWDIR\/conf\/urlrep.eng<\/em>\nfile that contains some malware data &#8211; commonly used signatures, URLs, and\ntheir related reputations.<br>\nLocal database is loaded to the kernel, and compiled to one Pattern Matcher\n(PM) that is executed on the incoming URLs to find a match.<br>\nIf the URL is found there, a response to the client is returned.<br>\nIf there is no match against local database, continue to next Step.<\/li><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RAD\n(Resource ADvisor) cache (for DNS and URL only), that gives answers to 99% of\nURL reputation requests.<\/li><li>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RAD\n(Resource ADvisor) service in the cloud (for DNS and URL only)<\/li><\/ol>\n\n\n\n<p>If the URL\nwas not found in the cache, a request is sent out to RAD and a response is\nreturned (asynchrony) back to the client, and the relevant data is kept in the\ncache.<\/p>\n\n\n\n<p>Anti-Bot\nResource Classification mode for DNS is overridden to &#8220;background&#8221; on\nthe Security Gateway. These settings override the existing default settings in\nthe SmartDashboard.<\/p>\n\n\n\n<p>The Resource\nClassification settings for Anti-Bot are now configurable from the Security\nGateway using the <em>malware_config<\/em> file.<\/p>\n\n\n\n<p>Using the\nSecurity Gateway configuration file provides more granularity and divide\nclassification to DNS, HTTP and SMTP.<\/p>\n\n\n\n<p>There are\nthree values for each option:<\/p>\n\n\n\n<ul><li><strong>hold<\/strong> &#8211; for hold classification<\/li><li><strong>bg<\/strong> &#8211; for background\n     classification<\/li><li><strong>policy<\/strong> &#8211; for classification according\n     to Security policy<\/li><\/ul>\n\n\n\n<p>The default\nvalues for HTTP and SMTP is policy, but for DNS the default is now <em>background<\/em>.<\/p>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>Other Security Modules<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p>Coming soon:<\/p>\n\n\n\n<ul><li><em>Application Control<\/em><\/li><li>URL Filtering<\/li><li>IPS<\/li><li>Threat Emulation and Protection<\/li><\/ul>\n\n\n\n<table class=\"wp-block-table\"><thead><tr><td>\n   <strong>References<\/strong><strong><\/strong>\n   <\/td><\/tr><\/thead><\/table>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk73220\">SecureKnowledge:\nApplication Control<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk92743\">SecureKnowledge: URL\nFiltering<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk119715\">SecureKnowledge: Content\nAwareness (CTNT)<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk95193\">SecureKnowledge: IPS<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk92264\">SecureKnowledge: Anti-Bot\nand Anti-Virus<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk114806\">SecureKnowledge: Threat\nEmulation<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk98348\">SecureKnowledge: Best\nPractices &#8211; Security Gateway Performance<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"http:\/\/dl3.checkpoint.com\/paid\/c1\/c1918858f31222841a08b76bbdca62b0\/wp-checkpoint-R80-security-gateway-architecture.pdf?HashKey=1532719982_4926d9c9b61f8d28973e2215e1e4e5ba&amp;xtn=.pdf\">Download Center: R80.10\nNext Generation Threat Prevention Platforms<\/a><\/p>\n\n\n\n<p><a href=\"http:\/\/downloads.checkpoint.com\/dc\/download.htm?ID=54724\">Download Center: R77\nSecurity Gateway Packet Flow<\/a> <\/p>\n\n\n\n<p><a href=\"http:\/\/downloads.checkpoint.com\/dc\/download.htm?ID=54704\">Download Center: R77\nSecurity Gateway Architecture<\/a> <\/p>\n\n\n\n<p><a href=\"https:\/\/supportcenter.checkpoint.com\/supportcenter\/portal?eventSubmit_doGoviewsolutiondetails=&amp;solutionid=sk116255\">Support Center: Check Point\nSecurity Gateway Architecture and Packet Flow<\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/thread\/5083-check-point-threat-prevention-packet-flow-and-architecture\">Checkmates: Check Point\nThreat Prevention Packet Flow and Architecture<\/a> <\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-2241-infinity-ngtp-architecture\">Checkmates: Infinity NGTP\narchitecture <\/a>&nbsp;<\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-3041-r80x-security-gateway-architecture-logical-packet-flow\">Checkmates R80.x Security\nGateway Architecture (Logical Packet Flow)<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/community.checkpoint.com\/docs\/DOC-3061-security-gateway-packet-flow-and-acceleration-with-diagrams\">Security Gateway Packet\nFlow and Acceleration &#8211; with Diagrams<\/a>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction This document describes the content inspection in a Check Point R80.10 and above gateways. Context Management Infrastructure (CMI) is the &#8220;brain&#8221; 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<\/p>\n<p><a class=\"button\" href=\"https:\/\/www.ankenbrand24.de\/index.php\/articles\/articles-check-point\/fw-monitor\/\" title=\"More\">  Read More \u2192<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":12,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/pages\/20"}],"collection":[{"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":10,"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/pages\/20\/revisions"}],"predecessor-version":[{"id":88,"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/pages\/20\/revisions\/88"}],"up":[{"embeddable":true,"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/pages\/12"}],"wp:attachment":[{"href":"https:\/\/www.ankenbrand24.de\/index.php\/wp-json\/wp\/v2\/media?parent=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}