cancel
Showing results for 
Search instead for 
Did you mean: 
Start an article

Check Point for Beginners (CP4B)

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies

 Part 8 - Network Address Translation  

Part 9 - Application Control, URL Filtering and Content Awareness <--- You are here 

In this lecture, we add Application Control, URL Filtering and Content Awareness functionalities to our Access Control policy. We also touch on the HTTPS Inspection feature.

 

Application Control & URL Filtering

 

Application Control and URL Filtering Software Blades enable security policies to identify and control usage of URLs and applications, including Web and social networking. While URL Filtering blade is Web oriented, Application Control works regardless of port and protocols.

 

Let’s take a look at the categories and applications. Open Object Explorer and chose Application Categories there:

 

You can look up specific categories and applications by:

 

If you do not have SmartConsole installed, refer to Check Point AppWiki:

 

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 the Access Control policy allows the administrator to enforce additional control based on the content of the traffic by identifying files and its content.

 

CTNT restricts the Data Types that users can upload or download and inspects HTTP, HTTPS, FTP and SMTP protocols.

 

Content Awareness can be used together with Application Control to enforce more interesting scenarios, for example, identify which files are uploaded to Dropbox.

 

You can review the supported file types and contents in the Object Explorer:

 

A full list of supported files and contents can be found in sk114640.

 

CTNT enforces control over both inbound (Download) and outbound (Upload) traffic. In this lecture, we will be blocking download of executable files.

Building Multi-Layer Access Policy

 

Let’s start by enabling the required blades on the Security gateway. In SmartConsole, open the gateway object and mark Application Control, URL Filtering, and the Content Awareness Software Blades:

Press OK button to exit.

 

Now, add an additional Layer to the Access Control policy. Right-click on Access Control > Policy and click Edit:

 

Add a new Layer:

 

 

Name the Layer “Application” and enable Applications & URL Filtering and Content Awareness Blades in General:

 

Go to Advanced tab and chose Accept option for Implicit Cleanup Action:

 

Press OK button to finish:

 

 

You should now see the new Application Layer in the Access Control Policy, with the default Cleanup Rule – Accept:

 

This Layer will be now used to control access to Web resources and applications.

 

Our Access Policy is based on two layers: Network layer and Application Layer. Traffic is filtered through Network Layer first before being matched through Application Layer. This is how it looks:

 

Refer to this video for more details.

 

Note: with R80.x product family, Access policy can be layered, as we are doing now, or Unified, where Network filtering, Application Control, URL Filtering and Content Awareness can be used in a single rulebase as a unified layer. You can get more information about the logic and capabilities of Unified policy rulebase on CheckMates, or in the official R80.10 documentation.

 

HTTPS Inspection Settings

 

According to different sources, today between 50% and 75% of Internet traffic is HTTPS. That means HTTPS Inspection is essential for effective control over web traffic.

 

In essence, HTTPS inspection is a man-in-the-middle attack, where the Security Gateway is decrypting and re-encrypting TLS traffic in both client to server and server to client directions. This is how it looks:

 

Before setting up Security Policy, you need to activate HTTPS Inspection. Double-click the Security Gateway object and choose HTTPS Inspection tab. Here you can either import an existing certificate that is already trusted by your users or to create a new one. Choose the Create option, set up DN (testlab.local in our case) and the key password:

 

 

Once the certificate is created, you need to export it, to install onto your end users’ computers. Choose Export and save it:

 

Finish the changes by marking “Enable HTTPS Inspection” checkbox and press OK.

We have finished the initial configuration of HTTPS Inspection feature.

Inspection Policy

 

Now we need to create a new Inspection Policy. Go to Application Layer and add a new rule with the following parameters:

  • Put LanNetwork as a Source.
  • In the Services & Application column add Anonymizer & Social Networking categories, as shown below:

In the Action column, choose Drop > Blocked Message:

Add another rule below and put Executable File into Content:

 

 

Right-click on Any Direction and choose Down. Set Action to Drop > Blocked Message:

In the Cleanup rule in this section, set Action to Accept and enable Detailed Log:

 

 

 

Your policy should now look like this:

Choose Install Policy. Now we are ready to test our Inspection Policy.

 

Installing the Certificate and Tests

 

Before we can test how effective our Inspection Policy is, we need to install the self-signed Security Gateway certificate on the Lab User PC.

 

Copy the certificate to that machine and open. Choose Install Certificate:

 

During the Import Wizard process, choose Local Machine:

Press Yes:

 

Select Trusted Root Certificate Authorities store to install:

 

Press Next:

Complete the Installation Wizard:

 

 

We are all set to test HTTPS Inspection. Open your browser and go to google.com. Press on the lock icon to see the certificate details:

 

You can see that the original google.com certificate is changed to one issued by testlab.com. That means HTTPS inspection is working as expected, and our Security is playing the man-in the-middle role, decrypting and re-encrypting HTTPS traffic between the user and a web server.

 

Important note: If you are using Google Chrome, HTTPS Inspection may not be triggered with the browser default settings. Chrome uses QUIC protocol to access Google resources. QUIC is UDP based and will not be a subject of HTTPS inspection. To force HTTPS communication, you will have to block QUIC in your policy. Alternatively, use browsers other than Chrome.

 

Now, try accessing facebook.com through your browser. In this case you should see Certificate Error warning and redirection to an IP address of the Security Gateway (192.168.1.254).

 

That is because you have been redirected to the UserCheck Portal, where we should see the blocking message. Since we did not install UserCheck certificate on the User Lab PC, the browser is trying to warn us about potential security issue. To avoid this in the future tests, you can establish trust to this certificate as well.

 

Alternatively, you can import a third party trusted certificate as shown below:

 

If you did not import UserCheck certificate, press Continue to this website. In the browser. You will be shown a Block Message:

Review the certificate and install it:

 

 

Try accessing Twitter. You do not have the certificate warning anymore and get the Block Message directly:

Now, check functionality of Content Awareness Software Blade. Try downloading any .exe file, for example, Wireshark:

 

The download will be blocked:

 

Go back to Security Policy to review the corresponding access logs:

 

This is the end of this chapter. Next time we will discuss Identity Awareness.

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

 

 

 

 

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies

 Part 8 - Network Address Translation  

Part 9 - Application Control, URL Filtering and Content Awareness <--- You are here 

Read more
5 4 434
0 0 12
0 0 3

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies

  Part 8 - Network Address Translation   <--- You are here 

Part 9 - Application Control, URL Filtering and Content Awareness

In this part, we will discuss different types of Network Address Translation (NAT), set up Internet access for our lab, and review a common example of Port Forwarding.

 

Types of NAT

 

NAT settings are part of the Access Control policy, as we have mentioned in Part 7:

  

Check Point has two different ways of setting up Network Address Translation: Automatic NAT and Manual NAT. Each of them allows configuring two different types of NAT: Hide NAT and Static NAT:

 

Hide NAT translates multiple internal addresses into a single IP (many to one translation). That allows internal clients to open connections to external networks. Outside of your security gateway, these connections will look as originated from a single IP address. To perform such Address Translation, the Security Gateway will change both the IP address and source port on the outgoing packets. On the return traffic, the destination IP address and port will be translated back to their original values so the packets can reach the originating client machine.

 

This type of NAT does not allow access to internal resources from external networks.

 

Static NAT preforms one to one translation, changing only appropriate IP addresses of the packets: Source IP address on the Client to Server packets and Destination IP address on Server to Client ones.

 

Static NAT is commonly used to ensure reachability of DMZ resources from Internet.

 

Let’s review cases of Automatic and Manual NAT configurations on more details.

1. Automatic NAT

This way of setting NAT is quite simple. NAT parameters are configured on an object requiring Network Address Translation, with two clicks. You need to open that object and add appropriate settings in its NAT tab.

 

Let us configure Automatic NAT for our LanNetwork object. In SmartConsole, double-click on it and go to the NAT tab.

 

 

Mark “Add automatic address translation rules” checkbox.

 

The translation method menu has two options: Hide (which is the default one) or Static. Leave the default value and press OK.

This action will create Automatic NAT rules. Move to Security Policies > Access Control > NAT to see them:

 

 

In a similar manner, set up Automatic NAT for our DMZ-Srv object:

 

 

These settings will allow the server to reach the Internet but not allow hosts on the Internet to reach the server. If we want to make the DMZ server accessible from external network on all services, we create an automatic static NAT. An additional external IP address is needed for this.

 

If we only need to forward specific services, such as HTTP, we can configure Port Address Translation (port forwarding). We can only do that by adding manual NAT rules.

2. Manual NAT

Manual NAT rules need to be explicitly created in the NAT Policy rulebase.

 

In our case, we want to forward only HTTP traffic to our DMZ server when someone is trying to reach it from external networks.

 

Let’s take a look on our network diagram once more:

 

 

To allow access with HTTP to our DMZ server, we need to make some additional changes.

 

Create a new host object with the external IP address of our Security Gateway:

 

 

Now, let’s add our new manual static NAT rule.

 

Go to Security Policies > Access Control > NAT and add a new rule to the top of the rulebase:

 

 

Manual NAT allows creating more sophisticated rules for Network Address Translation. We can now work with all the available fields of the rule:

  • Original Source
  • Original Destination
  • Original Service
  • Translated Source
  • Translated Destination
  • Translated Services

 

Static or Hide NAT method can be used here. To choose a desired NAT method, right-click on the Translated Source / Translated Destination field, and choose either Static or Hide, as show below.

 

 

Create the manual NAT the rule in the following manner:

  • Original Source: Any
  • Original Destination: PublicIP (the object we have just created)
  • Original Services: http
  • Translated Source: Original (we are leaving Source IP address as is)
  • Translated Destination: DMZ-Srv (Translated Destination should be our Windows Sever)
    Important: Use Static Nat Method here
  • Translated Services: Original (Destination port stays unchanged)

 

 

 

Note: Letter “S” next to Translated Destination field symbol specifies Static NAT Method we have set.

 

Finally, we need to add an access rule allowing external users to reach DMZ server via HTTP service. To do so, go to Security Policy Rulebase and add a new rule called DMZ-Srv Access at the very top of the rulebase, with the following parameters:

  • Name: DMZ-Srv Access
  • Source: Any
  • Destination: PublicIP
  • Services & Applications: http
  • Action: Accept
  • Track: Log
      

 

Install Policy:

 

 

As before, choose only the Access Control policy to be installed:

 

 

Once policy is installed successfully, we can start testing.

 

Testing access

 

With all the changes above maid properly, Internet should now be accessible from the lab Internal Network. In addition, Port Forwarding should allow HTTP access to DMZ-Srv machine from external networks.

 

Our Access and NAT policies allow Lab User PC to access Internet Web resources, but ping should not be working for the routable Internet IP addresses:

 

 

To check Port Forwarding functionality, we should access the external IP address of our Security Gateway with HTTP. In our case, with a VMware Workstation based lab environment, we can use VMware host PC, through VMnet8 adapter.

 

Let’s test it:

 

 

Thus, we have completed the basic NAT settings.

In the next parts of our course, we will work with Application Control and URL Filtering.

 

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies

  Part 8 - Network Address Translation   <--- You are here 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
11 8 972

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies     <--- You are here 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

 

In the previous part, we have started working with SmartConsole, which is the main administrative tool for creating and managing security policies.

 

In this session, we will be using SmartConsole to perform the following tasks:

 

  1. Set Anti-Spoofing and Security Zone parameters for Security Gateway network interfaces;
  2. Create various objects;
  3. Create and apply an Access Control policy on our Security Gateway.

Security Policies

There are four types of Security policies:

 

  1. Access Control: With the R80.x Unified Policy concept, such policy can use Firewall, Application Control & URL Filtering, Content Awareness, and Mobile Access Software Blades;
  2. Threat Prevention: This includes IPS, Anti-Virus, Threat Emulation, and Threat Extraction Software Blades
  3. Desktop Security: This is not enabled by default and only relevant for Remote Access VPN clients.
  4. QoS: Only relevant if the QoS blade is enabled.

 

In this lecture, we will cover Access Control only.

Access Control

 

The Access Control policy is the primary security policy you must install on your Security gateway. It must be installed before applying other Security Policy, such as Threat Prevention and/or Desktop Security. With R80.x, the Access Policy in Unified mode can include multiple Software Blades: Firewall, Application Control, Identity Awareness, and Content Awareness.

 

In this part, we will talk about the Firewall blade only.

 

Before installing Access Control security policy, we need to perform some actions:

 

  1. Set up Anti-Spoofing and Security Zones for Network Interfaces of the Security Gateway,
  2. Create network objects describing your IT infrastructure: Networks, Hosts, Servers, Groups, etc.,
  3. Create Access Control Security Policy rulebase.

 

Anti-Spoofing and Security Zone settings

 

Double-click on your Security Gateway object in SmartConsole and choose Network Management tab. There are three interfaces listed there: eth0, eth1, and eth2.

 

 

Double-click on eth0 and the following screen appears:

 

 

Three parameters needs to be adjusted:

 

  • Leads To
  • Security Zone
  • Anti-Spoofing

 

Click on Modify and set up those as shown below:

 

Click on OK twice and set up eth1 interface topology, as shown below:

 

 

Note that we have changed the default settings for this interface by choosing Override option. In addition, we have marked “Interface leads to DMZ” checkbox.

 

Click on OK twice and move to eth2 settings:

 

 

Click on OK three times to finish setting up the Security gateway.

 

Network objects

 

Before building Access Security policies, we need to create Network Objects we will be using there. A network object is not an IP (which can be IPv4, IPv6, or both), but it may also contain many other important details.

 

Objects are managed through Objects Panel on the upper right part of SmartConsole screen or with Object Explorer:

 

 

Let us start by creating a new network object called LanNetwork. To do so, in the Object Panel, press New > Network

 

 

In the new pop-up, set up the object name (LanNetwork), IP address and Mask:

 

Leave NAT (Network Address Translation) settings untouched. They are a subject of our next lecture. Press OK to finish.

 

Similarly, create a Host object DMZ-Srv (172.16.20.100). To start, choose New > Host. For better representation, change the color of the object (upper left corner):

 

 

Our objects are ready, now we can start building Access Control Policy rulebase.

Creating Access Control Policy

 

Go to Security Policies > Access Control > Policy. We have there a single pre-defined policy called Standard with just one rule of Any > Any > Drop:

 

 

This rule is called Cleanup rule. It is best practice to put this rule at the bottom of your policy package, to make sure all previously unmatched connections are dropped by your security policy. For better visibility on a Cleanup rule, change Track settings to Log. To do so, right-click on the Track field in the rule and chose Log:

 

 

Add a new access rule by clicking on Add Rule above icon:

 

The purpose of this rule is to allow HTTPS and SSH access from our LAN to Security Gateway and SMS.

Put “Mgmt” in the Name field. Chose LanNetwork object as Source, add SMS and SG to Destination, finally, HTTPS and SSH to Services & Applications:

 

 You can use text search when looking up any of the mentioned objects by name:

 

 Change Action to Accept and put Track to Log. Your new policy rules should look as below:

 

To protect our Security System elements from unauthorized access, we need to create so-called Stealth rule. Right-click on Mgmt Rule and choose New Rule > Below:

 

Put the following parameters:

  • Name: Stealth
  • Source: Any
  • Destination: SMS, GW
  • Services & Applications: Any
  • Action: Drop
  • Track: Log

 

Our new rules should look as below:

To avoid excessive logging of dropped “noisy” services, we need a Trash rule. Add a new rule below Stealth one, with Any for both Source and Destination. Add udp-high-ports, bootp, NBT, and rip services to Services & Application. To avoid logging, leave Track option default (None):

 

 Below Trash rule, add rule named Internet for Local Network. Put http, https, ftp, and dns to Services and Applications. The rule will look as below:

 

Finally, add another policy rule allowing access from LanNetwork to DMZ-Srv with Any service. Your rulebase should now be as shown:

 

Note: R80.x Security Management Server allows multiple administrators to make parallel changes. To make your changes available to other administrators, you need to publish them by pressing on Publish button at the top of SmartConsole screen.

In our case, all changes will be published during policy installation process.

 Installing Security Policy

 

We need to apply our Security Policy. Click on Install Policy button at the upper left corner of your SmartConsole screen:

 

 

The pop-up message reminds us we did not publish changes. Note that amount of changes and the admin account are mentioned in the Description field. Press Publish& Install:

 

When changes are published, we will see Install Policy window. De-select Threat Prevention checkbox and press Install:

 

Once done, you will see Policy installation progress notification at the left bottom corner of your SmartConsole screen.

 

When installation process is finished, you will see a notification about success:

 

If your policy is configured and applied properly, Lab User PC should be able to ping and access via http your DMZ-Srv lab machine.

 

Note that DMZ-Srv should have IIS enabled for HTTP to work.

 

 

Select DMZ Access rule in SmartConsole and then chose Logs tab. You should see access logs for this rule:

 

While DMZ access should work, do not try accessing Internet from your lab environment. To do so, we need to configure Network Address Translation (NAT), which is a subject of our next session.

 

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

 

 

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway     

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 - Working with SmartConsole   

Part 7 - Managing Security Policies     <--- You are here 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
9 1 1,172

Principles of Check Point Architecture

by Valeri Loukine

Stateful Inspection

In the History article, we mentioned that Stateful Inspection technology is much more efficient and secure than Static Packet Filtering.  Let’s try to prove this statement and understand its technological basis.

 

Static Packet Filtering (SPF) is a method to control network access by checking the IP header of a packet and comparing its data with an access list, which contains access restrictions and allowances.  Practically any UNIX, BSD or Linux machine is capable of performing this function natively.  With SPF, the security decision is made by the kernel’s IP stack in conjunction with an IP forwarding decision.  This function is always performed on a per packet basis.

 

Static Packet Filtering is incapable of enforcing anything more complex than just a simple verification of Layers 3 and 4 parameters, such as IP addresses and sometimes port numbers.  It also has performance drawbacks, as the security decision has to be made for each and every forwarded or discarded IP packet.  On the other hand, since this security function is quite simple, the OS kernel is capable of performing it without any extra help.

 

The Check Point Stateful Inspection engine provides enforcement using much more elaborate networking communication details.  It is capable of controlling traffic by reviewing and enforcing parameters of the OSI model’s multiple layers, from Layer 3 up to Layer 7[1].

 

It is important to point out here that Stateful Inspection itself does not have full control over Layer 7.  For example, it cannot control application data flow without additional technological help (for example, from a feature called Application Control and some others).

 

To make Stateful Inspection possible, Check Point inserts an additional enforcement layer – the INSPECT Engine – into the OS kernel between IP stack and network interface drivers.

 

Figure 1: Traffic crossing Check Point Firewall kernel

 

The INSPECT Engine deals with so-called “connections” and not with separate packets. It also deals effectively with complex protocols, such as FTP, VoIP and streaming.  From the INSPECT Engine’s perspective, a single rulebase match may include multiple communication flows in both directions.  For example, an FTP session includes an initial client to server TCP connection on port 21, and also multiple client-to-server or server-to-client connections for transferring files, using various ports, depending on whether FTP passive or active mode is used.

 

Representing network traffic as connections instead of as a collection of independent IP packets requires some additional technological means.  The INSPECT Engine uses Dynamic State Tables to keep records of all accepted connections and their protocols’ state.  For example, if a single TCP session is allowed by a security policy, the INSPECT Engine will make sure that TCP 3-way handshake is properly completed by allowing only a sequence of SYN, SYN-ACK and ACK packets (in that precise order) between a client and a server at the beginning of a communication session.  After the TCP handshake completes, the enforcement engine will correlate sequence numbers with a pre-set TCP window size to enforce the state of the connection.  The INSPECT Engine will also respect idle timeouts and other RFC-based parameters for each networking protocol.  Any change of the connection state will result in changes to the Dynamic State Tables’ records.

 

The representation of connections in a state table allows simplification of the security policy rules, among other things, as compared to SPF.  With Static Packet Filtering an administrator has to describe both client to server and server to client allowances in an access list to permit simple FTP connectivity.  In Check Point, a single rule allowing FTP to be initiated from a client to a server will suffice. 

 

Let’s see how Check Point policy enforcement actually works.  To do so, we need to recall how a security policy rule looks in the Check Point rulebase.

Figure 2: Sample rulebase

 

All policy rules have Source, Destination and Network Services columns.  These three columns describe allowed or restricted traffic.  The Action column defines a security decision for the matched traffic.  It can be Accept, Drop or Reject.  We assume the readers of this paper already have some basic understanding of security policies.  If you are new to Check Point environment, we advise you to refer to Check Point Security Administration course offered by a Check Point Authorized Training Center (ATC) for more details.

 

Let’s see how INSPECT Engine traffic enforcement works:

 

Figure 3: Simplified INSPECT Engine logics

 

When a new packet arrives at the FW kernel, the INSPECT Engine checks if there is already a connection in the Dynamic State Tables that this packet matches.  If yes, that means that a positive security decision (Accept) has already been made.  If the packet state is otherwise not considered a threat, it will be forwarded, and state records in the Dynamic State Tables are updated.  If there is no record of a known connection associated with this packet, the INSPECT Engine tries to find a matching rule, going through the rulebase from top to bottom.  To find the match, all three rule parameters: Source, Destination, and Service[2] are compared with the details of IP packet headers.  If a matching rule is found the appropriate action: Accept, Drop, or Reject is performed.  If the matched action is Accept, the INSPECT Engine adds a new set of records into the Dynamic State Tables.

Stateful Inspection advantages and limitations

Stateful Inspection improves the performance outcome for a security decision.  In case of an accepted connection, only the first packet requires a rulebase lookup.  The rest of the packet flow within an accepted connection only needs state table verification.  This approach is much more effective than SPF which requires making a security decision separately for each IP packet of the traffic.

 

Nevertheless, if connection is not accepted, every subsequent packet associated with the connection attempt (including retransmissions) must be matched to a Drop rule in the rulebase, even in case of Check Point Stateful Inspection is in use.

 

One more drawback of Stateful Inspection is about maintaining the stability of the OS kernel.  The INSPECT Engine is part of the system kernel; hence Dynamic State Tables reside in Kernel Memory space.  To prevent corruption of these tables, each set of Kernel Tables can only be accessed and updated by a single CPU core[3].

 

All these potential limitations are addressed with the SecureXL and CoreXL features in modern Check Point firewall systems[4].

Three Tier Architecture

To manage the policy rulebase installed on a Security Gateway and to control Check Point security systems as a whole, one needs a Security Management Server.  As already mentioned in the History paper (found at http://papers.cpug.org), having a Management Server as a separate component of the security system is a defining and integral characteristic of Check Point security products.  Interacting with a Management Server requires a third component: a Windows-based SmartConsole application.  These three components: the SmartConsole GUI client, Security Management Server and Security Gateway are part of the Check Point Three Tier Architecture.  Any Check Point-based security system has all three components. 

Distributed and Standalone Security Systems

In a typical Check Point Security system implementation, the Security Management Server and Security Gateway(s) are deployed on separate machines.  This type of deployment is known as Distributed.

However, in a very limited number of scenarios both the Management and Gateway components of the Three Tier Architecture can be installed on the same machine.  This alternative type of deployment is called a Standalone.  Even in this case the Management and Gateway functionality are acting separately and using the same communication principles that are in use in case of a Distributed deployment.

Secure Internal Communication

The Three Tier Architecture requires a communication mechanism allowing the Security Management Server to exchange information such as policy configurations and logs with Gateways.  This communication platform is called Secure Internal Communication (SIC).  SIC is based on TLS (Transport Layer Security) technology[5].  It provides an encrypted and secured channel for policy installation and status information delivery within a managed Security System.   TLS authentication is based on internally signed certificates.  The primary Management Server acts as an Internal Certificate Authority (ICA).  It issues certificates for managed Gateways and other components of Check Point Security deployments.  To initiate SIC with a new Gateway, one-time password is required to be defined both on the Gateway and on the Management Server sides.

Software Blade Architecture

Check Point’s Software Blade Architecture term needs to be explained from two different points of view: technology and licensing.  From a technology standpoint, the term “Software Blade” is interchangeable with a more common term: “a feature”.  Arguably, there is no technological or even architectural change in the Check Point products that would justify use of the term “blade” from a functionality perspective.  We will be using Software Blade terminology in the CPUG Papers in regards to security features, only because Check Point is using it in the product documentation, online help and marketing papers.

 

However, the licensing model for Software Blades is quite different from any other previous Check Point licensing models, and in that discourse the “Blade” term actually does demonstrate a particular value.  

 

Credits and thanks

The author thanks Dameon Welch-Abernathy, Timothy Hall, Eric Anderson and Kishin Fatnani for their comments, ideas, support and assistance in writing this article.

Footnotes

[1]  More details about stateful Inspection functionalities in regards to OSI model can be found in Check Point’s technical documentation.  Some external sources consider Stateful Inspection’s capabilities to be limited up to Layer 6, not 7.  The confusion is probably caused by different interpretations of the OSI model itself and not by misrepresentation of Stateful Inspection technology.  For example, HTTP and FTP are considered to be part of Layer 6 or Layer 7 of OSI, according to different authors and schools of thought.  In this paper, we are sticking to the Check Point view on the matter.  However, it is important to point out that some other authors and security vendors may use different methods of OSI networking model representation.

[2] VPN column appearing in a Simplified VPN rulebase may also be part of matching conditions, when applicable.

[3] This is true even to the case of CoreXL, where each CPU core has its own set of connections to handle.

[4]  To get more information about SecureXL and CoreXL we recommend the “Max Power: Check Point Firewall Performance Optimization” book by Timothy Hall, who is co-author of the papers you are reading now.

[5] TLS's predecessor SSL has been deprecated due to security concerns.

Read more
8 0 620

Check Point Customer Support Reference

Search the SecureKnowledge™ site in UserCenter in the Support/Services section for any additional technical assistance you may need including SK articles, related Downloads, Documents or Forums.

  • For Advanced Troubleshooting Resource Guides search for the term "ATRG" along with the feature you are looking for

 

CheckPoint Community - Check Mates

Check Point Software Technologies, Ltd. Main YouTube Channel

"Best Practices" Solutions and Documents by product sk111303

 

Introduction to Check Point - Videos

  • Introduction Video
    (view in My Videos)
  • Abbreviated Intro Video
    (view in My Videos)
  • Licensing Video
    (view in My Videos)

  • Best Practices Video
    (view in My Videos)

  •  R77 Technical Demo Video
    (view in My Videos)
  •  R80.10 SmartConsole and SmartUpdate Video
    (view in My Videos)
  •  R80.10 Gaia Install on a Management Server with the First Time Wizard
  •  R80.10 Gaia Install and Gateway Web UI Configuration Wizard
    (view in My Videos)
  •  R80.10 Best Practices - Migrating from R77.30
  • R80 Full (Includes First Time Install, SmartConsole, Gateway, and Best Practices) Technical Demo Video
    (view in My Videos)
  • Endpoint Review Video
    (view in My Videos)
  •  vSEC (CloudGuard IaaS) Discussion Video
    (view in My Videos)

  • Threat Prevention (SandBlast™) Video
    (view in My Videos)
  • Troubleshooting Basics Videos
    (view in My Videos)



  • CLI Troubleshooting Cheat Sheet - attached to the post
  •  

 

Training

 

SecureKnowledge Articles (SKs)

Support Articles

  • The Check Point Uploader - File Uploader to Check Point User Center - sk108152
    • Check Point utility to upload files to Check Point UserCenter that were requested by Check Point
      Support.
  • How to verify that Security Gateway and/or Security Management Server can access Check Point servers? - sk83520
    • Security Gateways and Security Management Server require access to the Internet (either directly, or via configured proxy) for various Software Blades. The sk lists relevant connectivity tests.
  • Practical troubleshooting steps for logging issues - sk38848
    • Practical troubleshooting steps that have proven effective in resolving a wide variety of logging issues.
  • Check Point Processes and Daemons - sk97638
    • It is useful to understand the potential impact of an unhealthy daemon (e.g. if you see high CPU for the cpd daemon in top, what might that affect?).
  • Performance analysis for Security Gateway NGX R65 / R7x - Sk33781
    • A list of commands that can be run and files that can be used to monitor and troubleshoot the  performance of the Security Gateway.
  • Ports used by Check Point software - sk52421

 

SK Tools References

  • How to run the First Time Configuration Wizard through CLI in Gaia ('config_system ...') - sk69701
    • Check Point Security Gateway and Check Point Security Management require running the First Time Configuration Wizard in order to be configured correctly. The First Time Configuration Wizard is available in Gaia Portal and also through CLI.
  • CPUSE - Gaia Software Updates (including Gaia Software Updates Agent) - sk92449
    • Next-gen software upgrade and hotfix infrastructure
  • CPView Utility - sk101878
    • CPView Utility is a text based built-in utility that can be run ('cpview' command) on Security Gateway / Security Management Server / Multi-Domain Security Management Server. CPView Utility shows statistical data that contain both general system information (CPU, Memory, Disk space) and information for different Software Blades (only on Security Gateway). The data is continuously updated in easy to access views.

 

 

Advanced Technical Reference Guides

 

Technical Reference Guides - in-depth troubleshooting guides for a specific functional areas:

  • Multi-Domain Management - sk95329

 

R80 -

  • R80.10 for management and GW - sk111841
  • R77.30 Upgrade to R80 Best Practice - Video

 

SandBlast - Threat Emulation Technical References:

  • SandBlast™ Threat Protection - PDF
  • Threat Emulation Engine Update - Sk92509
  • Threat Emulation supported file types - Sk106123
  • R77 Threat Prevention Guide page 107 - Indicators Configuration

 

vSec Best Practices:

  • vSEC Gateway for NSX - Best Practices - sk111575
  • ATRG: vSEC for VMware NSX - Best Practices - sk111060

 

SSL Inspection -

  • Best Practices - HTTPS Inspection - sk108202
  • Best Practices - Security Gateway Performance - sk98348

 

EndPoint and Remote Access

  • EndPoint Best Practices - Series of videos - sk103395
  • Check Point License Guide - sk11054
  • Check Point Remote Access Solutions - sk67820
  • Endpoint Security Server versions and supported Endpoint Security Client versions - Sk107255
  • Deploying a Check Point Endpoint Security Management Server in AWS - sk119393
  • Endpoint Security Home Page - sk117536

 

VPN -

  • ATRG:VPN Core - sk104760
  • VPN-related performance tips  - sk105119: Best Practices - VPN Performance
  • How VPNs are processed differently between base R77.30 and earlier and R77.30 JHF and R80.10 - sk118097: MultiCore Support for IPsec VPN in R80.10 and above
  • Performance of different encryption and hashing algorithms - sk73980: Relative speeds of algorithms for IPsec and SSL
  • Virtues of using AES over 3DES for improved performance - sk98950: Slow traffic speed (high latency) when transferring files over VPN tunnel with 3DES encryption
  • Email or SNMP trap automatically sent upon tunnel failure - sk25941: Configuring 'Mail Alerts' using 'internal_sendmail' command

 

Check Point Customer Support Reference

Search the SecureKnowledge™ site in UserCenter in the Support/Services section for any additional technical assistance you may need including SK articles, related Downloads, Documents or Forums.

 

Check Point Software Technologies, Ltd. - Main YouTube Channel

 

"Best Practices" Solutions and Documents by product - sk111303 

 

Contacting Account Services for Licensing Questions

  1. Phone: (US) +1 972-444-6600, option 5
  1. Email: AccountServices@CheckPoint.com
  1. Live Chat
    • Click the “Support/Services” tab
    • Click “Support Center”
    • Select “Live Chat” under the “Get Help” section
  1. Web Tickets
    • Click the “Support/Services” tab
    • Click “Create Service Request”
  1. Escalating an open Service Request
    • An escalation request can be submitted via the User Center
    • Escalation requests are sent to Account Services Managers and/or Team Leaders

 

References for Licensing

  • Check Point License Guide - sk11054
  • How to install a license - sk81200
  • How to Generate an Evaluation License - sk102029
  • Check Point VPN License Guide – sk84560
  • Service Contract File – sk33089

 

User Center

FAQ page - https://usercenter.checkpoint.com/usercenter/portal/media-type/html/role/usercenterUser/page/default...

 

 

Sync with User Center  - sk94064

User Center Mobile Application  - sk91860

Adding new users to Check Point User Center - sk22447

Read more
32 2 2,770

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 Working with SmartConsole    <--- You are here 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

In this part, we are starting to work with the main Check Point security administration tool: SmartConsole. We will install it, review its new look and feel, and interconnect Security Management Server (SMS) and Security Gateway (SG).

 

Installation

 

SmartConsole is a Windows based GUI Client. To install it, we need to get an installation package. The easiest way to obtain it is to download it from our SMS. Open WebUI to your lab SMS (https://192.168.1.100) and log in.

On Overview screen, press “Download Now!” green button at the top of the page.

 

 

Download the installation package and start installation:

 

 In the welcome pop-up window accept Check Point EULA and press Install:

 

 The installation process will take some time:

 

 

Press Finish at the end:

Connecting to SMS

 

Launch SmartConsole application. You will see administrator login screen. If you remember, during SMS installation we have chosen to use OS credentials to login with SmartConsole. Type in Gaia admin username and password, and IP address of your Security Management Server.

 

 Confirm SMS Fingerprints and press PROCEED:

 

The main SmartConsole window opens. At the center, there is What’s New tutorial describing the basic functionality of SmartConsole application.

 

 Go through the Tutorials screens, especially if you are already familiar with R77.30 SmartDashboard. The R80.x SmartConsole has quite a different look and feel.

 

Close the What’s New tutorial. You can always go through it again by pressing What’s New icon at the left bottom corner of SmartConsole screen.

The default view is Gateways and Servers, where you only have a single object at this point: the SMS. In the bottom part of the screen, you see the summary information about it: License Status, active Software Blades, CPU and RAM utilization. To get further info, click the Device & License Information link:

 

 

In the pop-up, choose Device Status > System Information:

 

 You can see more details about resources utilization:

 

 Browse System Counters > System to review graphic representation of utilized resources.

 

Connecting to Security Gateway

 

Close the pop-up window. It is time to connect our SG with SMS. At the top of SmartConsole choose New > Gateway:

 

 Choose Wizard Mode and continue:

 

 In the Wizard pop-up window, choose Open Server for Gateway Platform, type in IP address 192.168.1.254 and then press Next:

 

 

 Type in SIC - One Time Password we have defined during SG installation REFERENCE and press Next:

 

 

Under normal circumstance, (SG is up, and SIC password is correctly typed), you should see Get Topology Results pop-up screen:

 

 Check IP addresses and networks; then press Close and Next. Press Finish to end the Wizard.

 

You can now see Check Point Security Gateway pop-up for the newly defined SG. Choose General Properties and review Gateway Software Blade available. As you can see, Firewall Software Blade is marked by default. Do not change any settings and this point and press OK:

 

Press Publish button at the top of the screen to make all changes you performed available to other administrators.

 

Confirm by pressing Publish button in the pop-up window:

 

When the Publish operation is finished, you should see a green Status indicator for SG:

 

 

This is the end of this part. Next time, we will configure interface anti-spoofing, set up a new Access Control policy rulebase, and install it on the Security Gateway.

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

 

 

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway     

Part 5 - Gaia WebUI and CLI I and CLI

Part 6 Working with SmartConsole    <--- You are here 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
8 0 1,115

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway    

Part 5 - Gaia WebUI and CLI    <--- You are here 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

In this lecture, we will talk about managing the Operating System of Gaia based Check Point devices, finalize configuration of our Security Gateway, and introduce the Command Line Interface (CLI).

Gaia Management Tools

 To function properly, Check Point devices need some OS level settings: IP addresses, routing parameters, DNS, DHCP, SNMP, system updates, and backup settings. OS parameters can be managed either through WebUI or CLI.

WebUI

We have already touched the Gaia WebUI during initialization of our lab machines. To access WebUI, open your web browser to https://<device IP address>.

The Gaia WebUI supports the following browsers:

  • Internet Explorer 8 or higher (including IE11).
  • Microsoft Edge
  • Chrome 14 or higher
  • Firefox 6 or higher
  • Safari 5 or higher

You can always check if you browser is supported in SK92668

Let’s connect to our Security Gateway. To do so, open https://192.168.1.254 from your LAB PC or SmartConsole PC. After logging as admin you get to the Overview page.

 

 

The settings are broken down to the following categories:

  • Network Management
  • System management
  • Advanced Routing
  • User Management
  • High Availability
  • Maintenance
  • Upgrades (CPUSE)

For more details, refer to the Gaia Administration Guide.

Network Interface Setup

 

In the previous lecture we have set up just one network interface of our Security Gateway, eth2. We need to set up two other interfaces, as shown in the lab setup (Refer to part 2 of our lectures).

To do so, go to Network Management > Network Interfaces. All physical interfaces detected by the systems are listed there:

 

Double-click on eth0. In the popup window, mark enable checkbox to activate it. Write “Outside” in the comment field and finally, set up the IP address. Press OK to finish.

 

 Set up eth1 in the same manner:

 You can also add “Inside” to the Comment field of eth2. All interfaces should be shown Up at this point.

 

 

Setting Default Gateway

 Now, let’s set up default gateway. Go to Network Management > IPv4 Static Routes. The only entry there is Default.

 

Double-click on it and chose Add Gateway > IP Address:

 

Type in the IP address of the default gateway. In our case it is 192.168.206.2 (Vmware Workstation has .2 for NAT Adapter gateway).

Note: Gaia OS allows only a single admin session in write mode. If you close your browser window without logging off first, or the session times out due to inactivity, you will see the system configuration locked on the next entry to WebUI.

 

To unlock the settings, just click on the lock icon.

Gaia command line interface (CLI)

Gaia OS settings and also some parameters of installed Check Point products can be managed through CLI.

There are several different way to invoke Command Line Interface:

  1. From WebUI, click on “Open Terminal” icon at the top of the screen:

 

          Terminal Window with a login prompt pops up:

 

  1. Console port terminal connection
  2. SSH connection
  3. CLI option in SmartConsole

 

Let’s try SSH option. We are using Putty SSH client. Connect to the SG IP address (192.168.1.254). Log in as admin. You will see the following:

 

 

Command line ending with > symbol means you are in Clish – Command Line Shell. This is the default shell on Gaia OS, which has commands for managing OS parameters: IP addresses, interfaces, routing, DNS settings, etc. Although Gaia OS based on RedHat Linux, the syntax for commands in clish is different from bash.

 

If you want to access Linux bash, you need to enter Expert mode. Entering Expert mode require “expert” password which is different from the user password.

Clish CLI syntax is simple and can be vewed as Operation > Feature > Parameter.

 

Let’s take a look at some examples:

  • show commands - To view all commands that the user has permissions to run;
  • show commands feature <TAB> - To view a list of all features;
  • show commands feature VALUE - To show all commands for a specific feature;
  • show commands op <SPACE> <TAB> - To show all possible operations;
  • show commands [op VALUE] [feature VALUE] - To show all commands per operation, per feature.

Here are the four operation commands that are most frequently used: show, set, add, delete. You can get more details about Clish in R80.10 Gaia Administration Guide.

Practicing CLISH

Open an SSH session to the Security Gateway and login as admin. Type show command and then press Tab twice. You will see all available features:

 

There are a number of options here, but we will start with reviewing the configuration, which can be done by typing the command show configuration. You will see all Gaia configuration settings in the output, including the ones related to the network interfaces:

 

Never try setting any Gaia OS parameter with standard Linux tools. These settings will not survive reboot and will be get overridden by clish or WebUI configuration changes.

 

To access bash, you need to enter expert mode, which you do by typing the command expert. You will be asked to set the expert password with set expert-password command:

 

 

 

Set the expert password and type in expert again, than enter the configured password.

CLI prompt sign will change from > to #:

 

 Standard Linux tools and commands are now fully available.

This is the end of this Part 5. In the next session, we will install SmartConsole and start configuring our security system that will include Security Management Server and Security Gateway.

 

 

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway     

Part 5 - Part 5 - Gaia WebUI and CLI    <--- You are here 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
12 0 1,349

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway      <--- You are here 

 Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

In this lecture, we will cover deployment and initial configuration of a Security Gateway.

 

Deployment

As mentioned in our first lecture, Security Gateway can be deployed in three different options:

  1. Check Point Security Appliance;
  2. Open Server;
  3. A Virtual Machine.

 Note: in the practical part of this lecture, we will be installing our lab Security Gateway as a virtual machine.

  

Check Point Security Appliance

 With Check Point, there are four categories of Security Gateway Appliances:

  • Small and Medium Business,
  • Enterprise,
  • High End Enterprise and Data Center,
  • Large Data Centers and Telcos, also known as Scalable Platforms (SP).

 Note: SMB and SP appliances use different OS and software and are not part of our discussion.

 

Similar to what we have noted previously for the case of Smart-1 deployment, Check Point Security Gateway comes preinstalled with at least one version of Check Point Gaia software. If you want to re-image the appliance or install a software version different from the available factory defaults, look into sk65205.

 

Open Server / virtual machine

If you are deploying your Security Gateway on an Open Server or as a virtual machine, consult with the Hardware Compatibility List to make sure your deployment option is supported by Check Point. Installation flow for open server and a virtual machine is practically identical.

Installing a Software Gateway

In our lab, we will be installing a Security Gateway as a virtual machine. Let us review the lab configuration:

Create a new virtual machine with the following parameters:

 

Note there are three different NICs defined. The initial installation flow is very similar to the Management Server installation covered in the previous lecture. The only difference is about configuring interfaces.

 

At this step, choose NIC that shares a network with Lab User PC (VMnet2). In our case, it is eth2. Set up IP as 192.168.1.254/24 and leave Default gateway settings empty.

Continue the installation and reboot.

Initializing Security Gateway

 Initialization process is very similar for any Gaia based deployment: an appliance or open server, management or gateway. You are already familiar with the process from the last lecture.

In your browser, connect to https://192.168.1.254 and login with admin user and the password you have defined during installation process (vpn123 in our case). Start the First Time Configuration Wizard and choose “Continue with R80.10 configuration”.

Leave interface eth2 settings as is.

Wizard will advise you to set up other interfaces. Skip them at this point by pressing Next. We will set up other networks later on.

In Device Information menu, set up the machine hostname (SG), domain name (testlab.local) and the Primary DNS Server (8.8.8.8):

Leave Date and Time as default and press Next.

Choose “Security Gateways and/or Security Management” for Installation Type and press и Next:

 

For Products, chose only Security Gateway. Press Next to continue.

Choose No for Dynamically Assigned IP (DIAP) and press Next:

 

The last part of the Wizard is about SIC – Secure Internal Communication. In a few words, all parts of Check Point based Security System are using TLS encrypted channel to interconnect. This tunnel is known as SIC. It uses certificate based encryption. Certificates are issued by the Management Server and are initialized with an activation key we are defining at this step.

For further information about SIC, feel free to click on “learn more about SIC” link in the menu.

Press Finish to conclude the initialization process. The machine will reboot.

 

After reboot, you will be able to login into Gaia WebUI, same as in the case of SMS in the previous lecture.

 

Congratulations, you have successfully finished installation and initial configuration of two major elements of Check Point security system: Security Management and Security Gateway.

Next time we will continue configuring our system and will work with Gaia WebUI and CLI.

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway      <--- You are here 

 Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
11 3 1,460

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server      <--- You are here 

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Introduction

In this lecture, we will cover installation and initial configuration of a new Security Management Server. The labs settings from the previous lecture.

Deployment Options

Security Management Server (SMS) can be deployed in two different options: Smart-1 Appliance or Open Server.

Let talk about both options in more detail.

1. Smart-1 Appliance

Check Point provides a wide range of Smart-1 appliances that are divided into two groups:

  • Enterprise (Smart-1 405, 410, 225, 525)
  • High End Enterprise (Smart-1 3050, 5050, 3150, 5150)

 

 

The main difference between two categories is about amount of Security Gateways such appliance can manage. The more firewalls to manage, the bigger the performance requirements for the management server appliance in CPU, RAM, and hard disk size.

 

2. Open Server

In case of the Open Server deployment, you install SMS on a dedicated physical server or as a virtual machine, with Gaia OS. If the physical server is your choice, check the Hardware Compatibility List

Deploying SMS as a virtual machine is also a popular option. SMS VM production deployment is supported on several ESX versions, Hyper-V and KVM. See Hardware Compatibility List, tab "Virtual Machines" for more details.

We are deploying SMS as a VM in our lab.

Installation Procedure

 

Smart-1 and Open Servers installation procedures lightly differ in details. Let’s talk about appliance deployment in brief before covering the Open Server option.

Smart-1 Deployment

By default, Smart-1 appliance comes preinstalled with at least one version of Check Point Gaia software. In most cases, all you need is to initialize it. However, if you want to re-image the appliance or install a software version different from the available factory defaults, look into sk65205 for tools and details.

Deployng SMS as a VM

Our first lab starts here. To install a Security Management Server, we will be using a Windows based WMware Workstation.

By default, with Vmware Workstation installed on your PC, you have two additional network adapters related to VMware Workstation networks: VMnet1 (Host-only) и VMnet8 (NAT).

 

We need one more virtual network adapter: - VMnet2.To create in, in the VMware Workstation menu choose Edit -> Virtual Network Editor -> Add Network

After creating a new network, uncheck – “Use local DHCP service…” setting to disable DHCP on it.

Now we can create a new Virtual Machine with the following parameters:

  • Virtual Machine Name - SMS
  • Guest operating system - Other 64-bit
  • RAM - 8GB[i]
  • Processors - 2
  • HDD - 50
  • CD/DVD - Check_Point_R80.10_T462_Gaia.iso
  • Network Adapter - VMnet2

 

 

Once you start the machine, it boots from the DVD ISO image file, and the following screen appears:

 

 

Choose “Install Gaia on this system” to start the installation process. It includes six steps:

Proceed with the installation by pressing OK

 

Choose the keyboard locale from the menu (we are using US) and press OK again

 

 

Partition the hard drive. In the real world when deploying an Open Server, it is usually safe to rely default Gaia partitioning. Yet, if require, you can change sizes for System-root and Logs partitions.

 

In production SMS deployment, always set up Logs as the biggest partition. For lab purposes only, we will set up System-root for 17GB, leaving only 10GB for the Logs.

 

Set up the initial admin password. You can chose your own, but we are setting “vpn123” password at this step.

 

 

Set up IP address, network mask, and the default gateway.

 

Confirm the setup parameters and start installation by pressing OK.

 

 

At the end of installation procedure, you will see the note about first time configuration accessible via https://192.168.1.100. Press reboot and wait until the VM is fully up.

 

At this point, we have finished the installation. Let’s run a First Time Wizard to complete configuration of our SMS.

Initializing

 

Although, as mentioned above, installation / re-imaging of Smart-1 appliance and Open Server differ, First Time Wizard flow is identical in both cases.

To continue, we need to set up an IP address on virtualization host (your PC) VMnet2 adapter as 192.168.20 and network mask for class C (255.255.255.0).

Once the IP address is set, you can connect with a browser to https://192.168.1.100. Most probably, you will see “Invalid Certificate” security warning. Default Gaia installation uses self-signed certificates, so you can ignore the message and connect. You will see an authentication prompt.

 

 

Type in username admin and the password you chose previously (vpn123). You will see the First Time Wizard Welcome screen. Press Next button:

 

 

Choose “Continue with R80.10 configuration” and press Next:

 

Do not change Management Connection settings and continue by pressing Next:

 

Set up a Host Name - SMS, Domain Name - testlab.local, and DNS server – 8.8.8.8, then press Next:

 

 

You can leave default time and date settings:

 

On Installation Type screen chose the first option – Security Gateways and/or Security Management, then press Next:

On the Products screen chose only Security Management option and press Next:

We will be using Gaia administrator settings for Security Management default Administrator account:

We will also leave the default “Any IP Address” settings for GUI clients list:

Finally, confirm all the settings and press Finish to start configuration process.

The process takes 10 to 15 minutes:

 

Once it is finished, we get access to Gaia OS WebUI:

 

 

In the next lecture, we will describe installation and initial configuration of a new Security Gateway. Stay tuned!

[i] In case of very limited resources, you can use 5GB, but remember, the minimal requirements for SMS RAM are 8GB.

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server      <--- You are here 

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
16 4 2,509

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab          <--- You are here 

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Introduction

Our lectures are designed for mastering both theoretical and practical aspects of Check Point products. Before moving forward, we need to build a lab environment. All further discussions have in mind the virtualization lab setup described below.

Virtual Lab

The virtual lab layout is presented on the diagram below.

 

It consists of five virtual machines

  • Security Management Server (SMS)
  • Security Gateway (SG)
  • Lab User PC
  • PC with SmartConsole[1]
  • Windows Server (Active Directory and IIS are enabled)

 

Virtualization platform

While we are using VMware Workstation 14 in our lab, you can also use ESXI or Virtual box as a virtualization platform.

 

Installation Software Images

To install and setup all Check Point machines you need R80.10 Check Point ISO file. It is available here.

You will also need to install Windows Client (Windows 7 or higher) and Windows Server (2012 or higher) machines.

Note: Installation and setup of Windows machines are out of scope.

 

Hardware Requirements

Minimal Hardware requirements for Gaia R80.10 Open Server installation are listed in Check Point R80.10 Release Notes:

Although going below these requirements is definitely not recommended in the production, we can have some allowances in the lab.

These are recommended virtual machine parameters for our lab:

  • SMS:   6GB RAM, 4 CPU Cores, 80GB HDD
  • SG:     4GB RAM, 2 CPU Cores, 50GB HDD

 

You can chose your own RAM, CPU and HDD settings for Windows lab machines.

 

We believe the lab can be performed on a virtualization host with the following parameters:

  • 4 cores CPU,
  • 16BG RAM,
  • 500GB HDD/SSD.

 

Network Layout

 

We recommend using the same IP addresses as shown on the lab diagram above. Make sure you use different VMnet segments for each of the lab networks.

 

All three Security Gateway network interfaces should be defined in the different network segments.

 

In case of VirtualBox based lab, chose Host-Only Ethernet Adapter.

 

 

To be continued

In the next parts, we will deploy Security Management Server and Security Gateway.

[1] In case you are building this lab on your Windows PC, your virtualization host can take the role of SmartConsole Client.

 

----------------------------

Authors and contributors

Author Evgeniy OlkovCTO at TS Solution. 

Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture

Part 2 - Preparing the Lab          <--- You are here 

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
16 2 3,633

Navigation

Part 1 - Architecture                <--- You are here

Part 2 - Preparing the Lab 

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Disclamer

This article is a part of Check Point for Beginners materials. It is for CheckMates members exclusively. Check Point for Beginners does not replace official training and product documentation. 

Introduction

Check Point Software Technologies (Check Point for short) is a company operating exclusively on the field of Information Security and covering four main areas:

  1. Network Security on the perimeter and inside Data Centers,

  2. Cloud Security: Public, Private and Hybrid,
  3. Endpoint Security for both Windows and Macs, and
  4. Mobile Security for Android and iOS devices

 

 

 

In this article, we are discussing the Point 1 – Network Security solutions with Check Point.

 

 

Network Defense. Three Tier Architecture components

 

The main product of Check Point is the network security solution – Next Generation Firewall (NGFW). When working with it, you will encounter three main components: Security Gateway, Security Management Server and SmartConsole.

  1. Security Gateway (SG) is usually deployed on the perimeter to control and secure traffic with Firewall and Threat Prevention capabilities.
  2. Security Management Server (SMS) defines and controls security policies on the Gateways. It can also be used to as a log server with built-in system of log indexing (SmartLog) and event correlation (SmartEvent – a SIEM-like solution for Check Point products). Usually, SMS is the main element of central management with multiple Security Gateways in operation. Nevertheless, you need an SMS even if your security system has a single gateway only.
  3. SmartConsole is a GUI administration tool to connect to SMS. Through this tool, a security administrator is able to prepare and apply security policies to the Security Gateways.

Administration process includes the following steps:

  1. Security Administrator opens SmartConsole and connects to the Security Management Server.
  2. Security Administrator changes the existing (or defines a new) security policy and applies the changing by pressing Install Policy button.
  3. Security Management Server verifies policy for consistency to avoid logical errors, compiles it and send the result policy package to a Security Gateway.
  4. Security Gateway receives the compiled policy and applies it to the network traffic crossing the gateway.

Operating Systems

 

Historically, Check Point Software Technologies was oriented to different OSs: SUN, AIX, HP-OS, various flavors of Linux and Windows, IPSO, Secure Platform (SPLAT) and others. Today three component of Check Point are using the following Operating Systems:

  1. Windows – for SmartConsole only. SG and SMS cannot be deployed on Windows.
  2. Gaia – Check Point own OS based on hardened RH Enterprise Linux. Gaia will be the focus of some further materials, as it is the main option when deploying both SMS and SG on open server platform and Check Point appliances.

Note: Check Point SMB appliances based on ARM processors are using Gaia Embedded OS, which is a stripped and optimized version of Gaia.

Software Versions

At this moment Check Point supports three main software versions of its products:

  • R77.30
  • R80.10
  • R80.20

R77.30 is planned to go out of support in May 2019. R80.20 was released at the end of September 2018.

Deployment option

There are different deployment options for a Network Security System based on Check Point products:

  1. Check Point Security Appliance. This option includes both hardware and software required to run Check Point Network Security System.
  2. Open Server. Gaia OS can be deployed on specific certified servers from a Hardware Compatibility List available on Check Point web site.
  3. A Virtual Machine. Gaia supports VMware ESX and the most popular public cloud platforms: AWS, Azure, Google Cloud, Alibaba, and Oracle.

 

Standalone and Distributed Deployment

 

Security Gateway and Security Management Server components can be deployed on the same hardware of VM (Standalone):

  

or as different entities (Distributed Deployment).

 

Standalone option is economical but also limited, especially when talking about performance.

Distributed is the most popular and deployment option for Check Point customers. For some specific functions, such as SmartEvent, distributed deployment is a requirement.

 

Gateway Deployment

 

Security Gateway is deployed in a Routed Mode or a Bridge Mode.

Routed Mode is the most common. In this case, Security Gateway performs L3 routing when forwarding traffic allowed by Security Policy.

Bridge Mode can be deployed without changing network topology, to control traffic on Layer 2. Some functionality is limited in this mode.

Check Point Software Blades

One of the most frequent questions beginners have is about the term “Software Blades”. In plain words, Check Point is using this term for specific features of its products.

Security Gateways and Management Servers have collections of related Software Blades that one can enable or disable when required, depending on licensing. Combination of those defines specific flavor of Check Point products.

We will be addressing most of the Software Blades and their functions in the further CP4B materials. However, it worth listing all Software Blades available for Management and Gateways here.

 

 

Security Gateway Software Blades

 

  • Firewall – Basic security filtering functionality
  • IPSec VPN – functionality for creating IPSec-based Site to Site Virtual Private Networks
  • Mobile Access – SSL and IPSec Endpoint VPN solution
  • Application Control & URL Filtering – Advanced Security solution to control Web URL and Application traffic through the gateway
  • Data Loss Prevention – Pre-emptively prevent sensitive information from leaving the organization, educate users on proper data handling procedures, and allow remediation in real-time
  • IPS – Intrusion Prevention System
  • Anti-Bot – blade to detect and prevent Advanced Persistent Threats (APT) activity within the protected network
  • Anti-Virus – AVI scanning on the fly for downloads and uploads crossing Security Gateways
  • Threat Emulation – Sandboxing solution for downloads and email attachments
  • Threat Extraction – Unique technique to remove active content from downloads and attachments to prevent incidental malware infections and APT
  • AntiSpam & Email Security – email protection blade
  • Identity Awareness – Provides visibility to the identities of end users and the specific Active Directory host they are connecting from. This allows security policies to be enforced based on any combination of user, specific machine, or network.
  • Content Awareness – Control over specific types of content data files crossing Security Gateways
  • QoS – Quality of Service, traffic shaping and prioritization functionality
  • Monitoring – Real Time Monitoring of performance and traffic indicators for Security Gateways

 

 

Security Management Server Software Blades

  • Network Policy Management — to create and manage SG security policies
  • Endpoint Policy Management — to create and manage Endpoint Security Policies
  • Logging & Status – central logging and log consolidation functionality
  • Workflow — Change Management Cycle functionality with ability to audit and approve certain policy management operations
  • User Directory — User management and integration with external authentication solutions
  • Provisioning — Centralized maintenance tool
  • Compliance — Automated compliance tool for security and best practices audits
  • SmartEvent — Log correlation and Security Events management tool

 

 

Conclusion

In this article we have introduce you to the main terms and concepts of Check Point Network Security product family. In the next articles, we will address installation and initial configuration flow for both Security Gateway and Security Management Server.

 

----------------------------

Authors and Contributors

AuthorEvgeniy Olkov‌, CTO at TS Solution. 
Founded in 2010, the TS Solution is a fast growing Russian company, focused on integrating high-tech networking, security and server virtualization systems and technologies, along with maintenance and professional services.

Translation and editing - Valeri Loukine

Review and editing - Dameon Welch-Abernathy

Navigation

Part 1 - Architecture                <--- You are here

Part 2 - Preparing the Lab 

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI 

Part 6 - Working with SmartConsole 

Part 7 - Managing Security Policies 

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness

Read more
53 9 6,694

Brief History of Check Point Firewalls

by Valeri Loukine


 

At the beginning of things

The idea of filtering traffic between different networks is as old as routing itself.  Most routers are capable of enforcing so-called “access lists” to define basic inter-network communication restrictions.

The first paper describing network packet filtering was published by Digital Equipment Corporation (DEC) in 1988.  In 1992 DEC presented the very first commercial firewall: DEC SEAL.  Early firewalls such as SEAL checked network addresses and sometimes the port numbers of a packet to determine whether that packet could be forwarded or should be discarded.  This type of inspection is called Static Packet Filtering (SPF).

 

Figure 1: Static Filtering Enforcement - OSI Model

As shown on the diagram above, SPF acts on Layers 3 and 4 of OSI Networking Model.  Its security decision is based on IP addresses and in some cases ports of IP packets.

 

Although packet filtering’s logic is very simple, is has a fundamental flaw.  The firewall has to check each and every packet individually, disregarding state of a connection.  Most problematically, the same security decision is made over and over again to forward new packets within the same connection.

 

Everything changed in December 1993, when an Israeli startup called Check Point filed US patent application 5,606,668 describing a new principle of network security: Stateful Inspection.

 

Generally speaking, stateful firewalls deal not with single packets, but with connections and sessions.  This representation allows making a concise security filtering decision when inspecting the very first packet in the connection, and applying this action to any further packets of connections allowed by the security policy.  On top of that, a stateful firewall enforces RFC-defined network protocol behavior through the allowed sessions and blocks any attempt of improper use of network resources.  A stateful firewall is not only inspecting headers of IP and TCP packets, but also allowing enforcement of many other parameters in the data payload of the packets, securing communications on higher layers of the OSI model up through Layer 7.

 

Figure 2: Stateful Inspection - OSI model

 

Check Point presented Firewall-1 version 1.0, the very first commercial stateful firewall, in 1994.  Version 2.0 followed in 1995.

 

Firewall-1 1.0 was supported with SunOS and Solaris.  Version 2.0 added HP-UX support.  Version 3.0 added support for Windows NT and IBM AIX, and was also rebranded and sold by Sun Microsystems under the name “Solstice Firewall-1”.

 

The market success of Check Point and its firewall product was tremendous, and not only because of revolutionary Stateful Inspection principles.  It also had to do with the product itself.  Check Point introduced the “Three Tier Architecture” principle, distinguishing the three parts of its security system: SmartConsole GUI, Security Management Server, and Security Gateways (firewalls).  While the Three Tier Architecture often seemed cumbersome (especially to those with only a single gateway), it soon proved to be a game-changer for those who needed to manage multiple gateways.  The Graphical User Interface provided a simple and very intuitive way of managing policies and security rules.  It wins the hearts and minds of many a network security professional even now.

 

This is how the main administrative (fwui) tool looked on the Sun Motif windowing system:

Figure 3: fwui on Solaris

 

On Windows the color scheme was different, but the main look of the rulebase was still recognizable.  It is actually quite similar to the latest Check Point products:

 

Figure 4: Rulebase view - FW 2.0 on Windows

 

Evolution of Check Point firewall products proceeded smoothly for several more years.  In 2000, version 4.1 was introduced, supporting Windows NT, Solaris, Red Hat Linux, IBM AUX, HP-UX, and IPSO.

 

Changing product architecture

With a growing number of supported platforms and increasing complexity of the product, Check Point faced some development challenges.  The firewall software was originally maintained as a single piece of code.  It had to be re-compiled for every bug fix and every new feature added, and for each specific flavor of the supported platforms.  The software for version 4.1 had more than 1.5 million lines of code.  Product development and improvement started to become somewhat cumbersome.  The situation had to change.

 

In 2001 Check Point released a completely redeveloped product called NG[1], the fifth generation of its firewall software.  It had a modular structure, with various features and functionalities organized as separate pieces of software, and with a common infrastructure called Secure Virtual Network (SVN) Foundation.  The modular structure allowed Check Point to accelerate implementation of new features.

 

One of the most interesting improvements added to the NG version was related to performance. At the beginning of the century Check Point started working on developing acceleration solutions that would allow offloading some of the security processing to a separate CPU.  Although the initial development was oriented towards an external CPU on a card, such as VPNx cards to offload VPN encryption and decryption calculations, Check Point developers added acceleration APIs to the software that would allow using an external acceleration solution such as ADP card, or just an additional CPU available on a multi-core system.  This solution is known as SecureXL.  This technology is still among core architectural principles of Check Point security system.

Intrusion Prevention

While firewalls were becoming more and more effective, the security landscape was also changing rapidly.  At the beginning of 21st century, IDS/IPS systems became a real necessity. Check Point first introduced SmartDefense in NG Service Pack 3 (R53).  While really just a compilation of pre-existing advanced defense features (like SynDefender, CPMAD, and anti-spoofing), it laid the foundation for what was to come.  In year 2003 Check Point released version NG AI R54.  The “AI” in the product name stood for Application Intelligence, which was the name Check Point used for IPS-like functionality.  Later on, with the NG AI R55 version of the firewalls, Check Point started grouping the AI function into SmartDefense and Web Intelligence categories, to distinguish general protocol related protections and security features protecting Web communications.

 

Unfortunately, Application Intelligence was not competitive enough given the new IPS vendors that were defining the market such as ISS and Tipping Point.  NG AI was difficult to configure and was missing some security features.  At this time, Check Point started looking to acquire a true IPS solution.

 

In 2005 Check Point attempted to acquire Sourcefire, a security company developing Snort-based IDS products.  In early 2006, the deal was ultimately scuttled after it became clear that USA authorities would not approve it.  In December 2006 Check Point acquired NFR Security, another American company with its own IPS solution.  Immediately after this acquisition Check Point started working on integrating NFR Sentivist IPS technology into its security products.  The Sentivist IPS was renamed to Check Point IPS-1. 

 

In 2009 Check Point released new IPS blade as part of the R70 firewall version.  It was based on deep packet inspection technology that is now shared with other advanced security features of Check Point firewalls.

 

Multi-core firewalls

As network technology and overall speeds were progressing, the performance requirements for firewalls were also growing.  Although Stateful Inspection principles were much more efficient than static filtering, they presented a completely different challenge.  Enabling IPS and other more advanced security features on a firewall required much more firepower than Check Point Stateful Inspection was originally designed for.  Why is that, you may ask?

 

Classic Stateful Inspection is based in the operating system kernel of the firewall system.  Multiple additional modules (called kernel chains) are inserted into OS kernel prior to the IP stack for inspection purposes.  In the classic firewall architecture, just a single CPU core was used by the FW kernel to perform traffic inspection and to maintain a state table containing all accepted connections and their allowed parameters.

 

In a dual CPU system, it made sense to let one of the CPUs make FW security decisions and use the second CPU for acceleration via SecureXL.  This was the case for all Check Point firewall versions up to NGX R65.  With firewall performance requirements growing drastically, Check Point needed to make a major change to the firewall’s architecture.  In 2009, the company released version R70 with CoreXL – new technology allowing simultaneous use of multiple CPU cores for Stateful Inspection filtering.

 

Check Point also significantly changed the licensing model for R70 and above, protecting their value by controlling performance and sizing with a licensing model based on the number of CPU cores used by the firewall system.

 

Next Generation Firewalls

Throughout the first 15 years of its history, Check Point firewalls evolved smoothly.  New features were added in response to market demands.  The architecture of the product evolved, and so did the licensing.  Competitors were fighting Check Point for market share here and there, yet all firewall products in the market were still using the same principles (Stateful Inspection & Three Tier Architecture) as in the early 90s, with some minor technological improvements.

 

It was too quiet and predictable.  It was bound to be disrupted.

 

In July 2007 Palo Alto Networks (PAN) came to market with its concept of Next Generation Firewalls or NGFW.  According to PAN, stateful inspection firewalls were obsolete.  Evolving security requirements demanded that new principles be applied to network-based security enforcement.  These new principles would filter traffic based on applications and user information, not just based on network and protocol parameters.

 

NGFW became a buzzword, and the market began expecting similar features from all established firewall vendors.  In 2009, Check Point acquired the application classification and signature database of FaceTime Communications, Inc. (who soon after sold the naming rights and trademark to Apple).  FaceTime had been selling solutions (initially focused on IM and compliance) since 2001.  The Facetime engine and App Wiki (which was more mature than PAN’s App Id) became the foundation of Check Point’s Application Control blade.  At the same time, Check Point introduced Identity Awareness, enabling Access Role object, rounding out Check Point’s ability to surpass, or at least compete with other content filtering solutions.  Unlike PAN, the company did not completely dismiss Stateful Inspection principles but complemented them with NGFW features.

 

Advanced security features

In the 20 years since the very first commercial Stateful Inspection product was introduced, Check Point offerings had evolved enormously.  Modern firewalls now include lots of sophisticated security features on top of the classic rulebase filtering: IPS, Data Loss Prevention, Threat Prevention and the already mentioned NGFW protections.

 

Managing such a complex security solution is no longer nearly as simple today as it was in 1994.  Most of the newer advanced NGFW features have their own security policies independent of the regular FW rulebase, at least as of version R80.  Each aspect of the firewall’s security enforcement functionality dictates its own security principles and has to be managed separately.

 

For example, in the R77 release, Application Control & URL Filtering has its own rulebase.  If a connection is allowed by the classic Stateful Inspection FW rulebase, it also has to be further inspected and secured through the Application Control rulebase.  This is known as layered security, where each feature provides an independent security enforcement layer while enforcing traffic flow through a firewall.

 

The following diagram presents a simplified view of multi-layered security enforcement, where traffic is being inspected and secured by different security software blade policies, bottom to the top.

Figure 5: Simplified representation of Multi-Layered Security

 

There are multiple arguments and competing reasons for using a layered security policies approach.  It may be useful when different administrators and teams are responsible for different portions of security enforcement functionalities.  For example, if Alice is managing the access policy rulebase, Bob is in charge of IPS policies, and Application Control policies are defined by Charles, the layered security policies & procedures of the organization fit into this situation very well.

 

However, if one person or a single team is in charge of the whole security system and its policies, using multiple rulebases and different tools to set up layered security policies may not be advantageous.

 

Another argument against layered policies concerns performance.  Any connection accepted through the access security rulebase must then be matched through potentially many other enabled security layer policies: Threat Prevention, IPS, Application Control, DLP/Content Awareness, etc.  Each independent layer’s inspection is independent and unavoidable, which adds some burden to security system resources.

 

An alternative is to implement a single unified policy where particular advanced features would be part of the security rules or even applied as sub-rules under selected access rules, as will be described later on in these papers. Such security policy requires new architecture of both Security Gateway and Security Management Server.  Hence Unified Policy is fully available starting from the R80.10 version.

 

Appliances and platforms

The full company name of Check Point is Check Point Software Technologies Limited.  The key word here is “Software”.  For many years, Check Point concentrated its efforts to build software products, allowing customers to bring/build their own servers, while leveraging multiple hardware partners and vendors to produce purpose-built security appliances.

 

During 20 years of company history there were quite a few partnerships of this nature with such participants as HP, Dell, Siemens, Nortel, IBM, Nokia, SofaWare, Crossbeam, and many others.

 

Newcomers to Check Point may find this surprising, as Check Point now offers many different appliance models in its portfolio, covering all varieties from SOHO to High End Security Gateway lines.

 

Yet, even as late as 2005, Check Point did not have a single enterprise appliance in its own price list.  All available offerings were from HW partners such as Nokia; HP and IBM.  The Company executive team explained its reluctance to enter the hardware business with the following statement: “We know how to make very good software. We engage other companies as partners because they know how to make a very good hardware.  Let our customers decide which hardware they want to use by themselves”.

 

Although this argument makes a lot of sense, other competitors did not hesitate to offer off-the-shelf security appliances to compete with Check Point.  The “Software only” policy also had some disadvantages that were not solely competitive: it was actually causing development, maintenance, and support issues along the way.

 

We mentioned some of the early supported Check Point platforms at the beginning of this chapter.  Some of those platforms and OSs, such as HP AIX and Nokia IPSO, were owned directly by the HW partners themselves.

 

Multi-platform development does have its challenges.  The company has to port and compile the same source code for different Operating Systems and different software libraries.  These products then have to be debugged and tested to assure their quality and stability.  Each new supported platform adds its own required development and test cycle along with continuous training of support engineers, increasing both support and development costs.

 

Dealing with multi-platform security systems out in the field is also cumbersome.  Some of the supported platforms also had additional licensing costs included on top of Check Point’s pricing.  One also must contend with OS support, which was provided by the OS vendors themselves.  This could sometimes result in “finger-pointing” in a troubleshooting scenario, where the OS support engineers blamed the firewall software for a problem, and the firewall support engineers blamed the OS.

 

Through a great deal of effort, Check Point managed to eliminate the firewall OS acquisition and support costs by producing its own Linux-based hardened OS known as SecurePlatform or SPLAT.  SPLAT was originally based on the 2.4 variant of Red Hat Enterprise kernels, and later on kernel version 2.6.18.  The price for SPLAT was included in the FW licenses[2], and the maintenance for both security products and the OS itself was all performed by Check Point itself, thus greatly reducing the possibility of a “finger-pointing” scenario.

 

Having its own OS for security products was a good compromise, but it also required platform certification.  With Windows NT, Check Point was supported on any Windows-enabled box.  However, with SPLAT, the hardware vendor had to make sure the required storage and network drivers were available, and could actually run on a particular configuration of hardware.

 

The Nokia Security Appliances resulted from what was by far the most successful partnership that Check Point ever had with its HW counterparties.  Nokia was using its own OS called IPSO, which was based on FreeBSD.  The popularity of Nokia Security Appliances varied by region.  In many European countries, IPSO appliances were enjoying up to 90% penetration of the Check Point installed base.  IPSO boxes were loved for their flexibility, improved clustering features (especially native VRRP), solid dynamic routing capabilities and native support of multicast routing.  Effective maintenance and support plans directly provided by Nokia distributors and partners also contributed to the amazing success.

 

Nevertheless, the development challenges remained even for IPSO.  Nokia was also partially responsible for software porting and testing.  In many cases Nokia was late to release new versions of Check Point security products.  In some isolated cases, such as with the VSX product, the IPSO release could be delayed for up to six months after general availability of that particular version had been announced by Check Point.

 

Pressured by competitive and internal development needs, Check Point finally introduced its own security appliance hardware in 2007.  Strangely enough, SPLAT-based Check Point UTM-1 and Power-1 security appliances were competing directly with IPSO based Nokia Security Appliances for a period of time.  Both had their own advantages.  Check Point’s UTM-1/Power-1 appliances had more up-to-date hardware specifications, but lacked stable dynamic routing and multicast features.  IPSO-based boxes, while exceling against Check Point appliance offerings in logistics and maintenance, were more expensive.  The challenge of dual platform development for Check Point’s software also remained.

 

In 2009 Check Point acquired the Nokia Security Appliance business, and started working on merging the best of SPLAT and IPSO into a new OS platform called Gaia.  Gaia is designed to work on all variations of Check Point security appliances, including the Nokia hardware.  Although based on the RH Linux kernel (IPSO used the FreeBSD kernel), Gaia had the IPSO variant of dynamic routing and multicast features integrated into it.

 

Today Check Point has a wide spectrum of appliance offerings for all market segments: small and medium offices, enterprise, and high end.  All Check Point appliances utilize Gaia as their OS platform, even in VMWare.

 

SmartConsole and Management APIs

R80 brings major innovations for security management.  For many years, the Check Point SmartConsole set of applications could only run on Windows machines.  Nowadays more and more security administrators use something other than Microsoft operating systems, and would welcome a platform-independent security management interface.

 

Many Check Point competitors are already using a Web-based management UI with their own security solutions.  Such browser-based interfaces do not depend on a particular OS platform.  Unfortunately, these WebUI interfaces are usually Java or AJAX based.  Most of them are dependent on a particular Java flavor and also have various limitations related to particular Web browsers.

 

With R80, Check Point developers presented a new architecture for the Security Management Server.  It now uses web infrastructure libraries such as Java.  Although the SmartConsole GUI tool is still Windows based, Check Point is making significant progress towards multi-platform management interfaces.

 

With the new SMS architecture, Check Point also removes the longstanding limitation of only a single user having write access to the management database.  With R80 management, multiple administrative accounts can perform object and policy configuration changes at the same time.

 

Another area addressed by the R80 SMS solution is software-defined network security.  Virtualization and automatic orchestration are essential requirements for modern security solutions.  R80 provides effective management APIs that are replacing the “old school” OPSEC interfaces.  With R80 management, API customers can engineer their own integration with Check Point security systems to leverage automated changes within their SDNs and cloud-based security solutions.

 

New Security Gateway Architecture

R80.X gateways bring vast changes in the enforcement capabilities. New Unified Policy with sub-layers, Content Awareness feature, redesigned SecureXL, and multi-core IPSec VPN functionality – these are just some of the new features and improvements.

 

Revolution is now

One does not have to be a futurologist to make some predictions.  It is clear that network and information security is now part of everyday reality.  In our interconnected world, we care about privacy, intellectual property, accessibility, and continuity of access.  We are bound to see more sophisticated attacks, new hacking tricks, new threats and also new technological solutions to prevent any of those and to protect our lives and businesses.  While technology is changing our daily lives, Check Point helps making that change safe and continuous.

 

The author hopes this article may help you in understanding and appreciation of tremendous efforts and achievements Check Point made through the years.  But the journey does not end here.  Digital revolution is happening every day, and Check Point security solutions are part of it.  They will continue to fascinate and amaze us. 

 

Stay tuned, stay sharp, and prepare to be surprised.

Credits and thanks

The author thanks Dameon Welch Abernathy, Timothy Hall, Eric Anderson and Kishin Fatnani for their comments, ideas, support and assistance in writing this article.

 

Footnotes

[1] NG stands for Next Generation.  The term Firewall-1 Next Generation should not be confused with NGFW (Next Generation Firewalls), the concept originally introduced by Palo Alto Networks in 2007.  To avoid any potential ambiguity, we will be using the NG abbreviation only when referring to particular versions of Check Point software products.

[2] Originally, there was also an additional license for SecurePlatform Pro feature, discontinued later on.

Read more
15 6 545

In a set of videos our renown trainer Manuel Joaquim explains the basic ideas behind network security, packet filtering, Stateful Inspection and firewalling.

 

Stay tuned for more.

Read more
5 0 154

In a set of videos our renown trainer Manuel Joaquim explains the basic ideas behind network security, packet filtering, Stateful Inspection and firewalling.

 

Stay tuned for more.

Read more
6 0 150

In a set of videos our renown trainer Manuel Joaquim explains the basic ideas behind network security, packet filtering, Stateful Inspection and firewalling.

 

Stay tuned for more.

Read more
5 0 169

In a set of videos our renown trainer Manuel Joaquim‌ explains the basic ideas behind network security, packet filtering, Stateful Inspection and firewalling.

Stay tuned for more.

Read more
8 0 474

Understanding technology is a challenge. 

Complex concepts, rapid changes, new paradigms, overwhelming details, tools to master, time pressure - all those things might be tough to cope with.

As a member of CheckMates, you deserve the best. That's why we have created a new Space on CheckMates - Check Point for Beginners. It is members' exclusive space where we will be posting learning materials: videos, articles, lab manuals,  even history overviews - to help you out and to make understanding and mastering Check Point easier, less stressful and more productive. 

 Subscribe and learn at your pace. 

Our Publications

Check Point for Beginners (CP4B) Lecture Series

Part 1 - Architecture

Part 2 - Preparing the Lab         

Part 3 - Installing Security Management Server

Part 4 - Installing Security Gateway

Part 5 - Gaia WebUI and CLI

Part 6 - Working with SmartConsole  

Part 7 - Managing Security Policies

Part 8 - Network Address Translation 

Part 9 - Application Control, URL Filtering and Content Awareness      <--- NEW LECTURE!!! 

Videos

Understanding Check Point FireWall - Part 1 

Understanding Check Point FireWall - Part 2 

Understanding Check Point FireWall - Part 3 

Understanding Check Point FireWall - Part 4 

Other Materials

Brief History of Check Point Firewalls 

Principles of Check Point Architecture <--- NEW ARTICLE!!! 

Note: You have to be a member of CheckMates to access the materials. Please register with your UserCenter account. Create one, if you do not have it yet.

Read more
21 3 7,646