Check Point CCSA Notes

CheckPoint is the largest pure-play security vendor globally, and has a long history of being a respected security solutions provider and the company’s devices are one of the most deployed firewalls in use today.

Till now, for eighteen consecutive years Check Point has been positioned in the “Leaders” quadrant in the Magic Quadrant for Enterprise Network Firewalls. Check Point is also positioned in the “Leaders” for Unified Threat Management (UTM) for five years till now. Gartner evaluates each vendor’s Enterprise Network Firewall offerings on a scale of completeness of vision and ability to execute.

Traffic Control Methods:

  • Packet Filtering in OSI Layer 3 (Network) and Layer 4 (Transport)
  • Stateful control by Inspect Engine, again at L3 and L4 but with more focus on L4
  • Application Awareness

Check Point Operating system:

We talk here about both Management Server and the Gateways (firewalls) OS.

  • IPSO was the initial version, based on BSD (Nokia’s IPSO).
  • SecurePlatform (SPLAT), based on Redhat
  • GAiA is the latest version!

Deployment Notes

With small environments, it’s possible to have the Management Server and Gateway on the same hardware. This is called Standalone deployment.

In Distributed deployment, the communication between Gateway and Management servers happens via Secure Internal Communication or SIC.

When connecting to the Management Server via SmartConsole SmartDashboard, it is possible to validate the received Fingerprint by cpconfig utility on GAiA SuperShell (clish):

GAiA-Standalone> cpconfig
This program will let you re-configure
your Check Point products configuration.
 
Configuration Options:
----------------------
....
(8)  Certificate's Fingerprint
...
Enter your choice (1-11) :8
 
Configuring Certificate's Fingerprint...
========================================
The following text is the fingerprint of this Security Management Server:
PLY SKI WIRE GWYN HALL INCA LOP CUBA BIND OMIT COT FIT

Firewall Security Policy

In any Firewall implementation, I always consider adding the below categories of policies:

  • Management Traffic from trusted networks/hosts
  • Stealth rule to drop any other traffic to the Firewall
  • Rules for Internal traffic
  • As in all other vendors, there is a default implicit DROP rule in Check Point Policy implementation, but it doesn’t log the traffic. Therefore, a Cleanup rule has to be added with the Track set as Log.

There is a very large set of Implied Rules to be tweaked from Global Properties. Pay attention to the placing options! It’s possible to make these rules visible in the Policy section from Options > View > Implied Rules.

POlicy PACKAGES, Policy Targets & Installation
  1. After creating the policy, it should be Saved and then Installed. Nothing is in place until the policy is Saved!
  2. By default, SmartDashboard installs the policy to “All Internal Security Gateways” which can be changed in Options > Policy > Policy Package Installation Targets.
  3. Then, by default, a rule has Policy Targets as “Install On” option, which can be changed by specifying any required target Gateway from “Policy Package Installation Targets“.

To make life easier in an enterprise deployment with lots of firewalls, firewalls with similar rules are bundled to use a specific Policy Package and select the Policy Targets as mentioned above. This can be created from Options > File > New

In small businesses with small number of firewalls, there could be different Sections in the same Policy Package and separate rules of each Gateway. But, the option of “Install On” should be specifically set to the target Gateway.

Also, I should mention that it’s possible to copy/paste policy rules between Policy Packages!

Below are some related CLI commands:

  • fw stat indicates the current active policy
  • fw unloadlocal to unload the active policy, whether it’s Initial Policy, Default Policy or a regular one. By unloading the active Policy, then GAiA becomes an Operating System, which is Redhat without any Firewall policy.
  • fw fetch localhost loads the policy from the local machine
  • fw fetch 10.1.1.1 fetches policy from a remote host, usually Management Server, and activates it.

NAT

We all know what is Static NAT, but what we call PAT in Cisco world, is named Hide NAT in Check Point platform.

It’s good to remind that NAT happens after the packet is logically processed and routed to the outgoing interface, but at the Egress interface (Pre phase) before leaving the interface for Post phase.

NAT configuration is unbelievably easy, so I don’t go through it. Just keep in mind that beside the NAT rule, a matching policy rule is also required to allow the traffic.

While doing Static NAT to publish an internal server on DMZ zone, and the topology on the DMZ interface is set to Internal - Network defined by IP and Mask, it is recommended to check Translation destination on client side inside the Global Properties.

In case you are interested about session timeouts, they can be seen/modified from Options > Policy > Global Properties > Stateful Inspection.

There’s a Wrench shortcut icon for Global Properties at the top of SmarDashboard.

Application & URL Filtering

This feature helps in protecting the environment against Malware, Bandwidth abuse, Non-approved Sites, and also provides HTTPS Inspection.
To make use of Application & URL Filtering, below licensed software blades should be enabled:

  • Application Control
  • URL Filtering (mandatory for HTTPS Inspection)

The whole concept is pretty simple and the configuration happens via Application & URL Filtering. Simply by adding rules, specifying source, destination, Application/Sites, Actions, etc.

Regarding HTTPS Inspection:

  1. From the Gateway node options,  HTTPS Inspection tree, a certificate needs to imported/created. This will be used for secure connection between the Gateway and Client.
  2. The certificate should be installed on the clients,otherwise the client browser will throw a warning. Usually enterprises use deployment tools to import the certificates on clients.
  3. Checking Enable HTTPS Inspection

The Inspection engine inserts itself into the Kernel between Data Link and Network Layer (OSI)

IPSec VPN (Site-to-Site)

  • 6 packets will be transferred in Main-mode negotiation, IKE Phase 1
  • 3 packets will be transferred in IKE Phase 2
  • In IKE Phase 1 Aggressive mode, 3 packets are transferred, is little bit faster but less secure.
  • In Checkpoint environment, IPSec VPN is based on a terminology called Community! Gateways (firewalls) are called Community Members. Last but not least, interesting traffic is categorized into Domains.
Steps:
  1. Enabling the IPSec software blade on the gateway
  2. Specifying the VPN Domain under Topology tab
  3. Creating a VPN Community in VPN tab
  4. Adding policy rules and assign them to the VPN tunnel

When IPSec Mesh connectivity is required between Center Gateways [in Core], “Mesh Center Gateways” should be selected inside IPSec Community “Center Gateways” setting.

If you too prefer CLI, vpn tu command is very handy and provides all required information about IKE and IPSec SAs.

  • When troubleshooting an IPSec VPN and checking logs in SmartView Tracker, “IKE: Phase 1 Received notification from Peer: payload malformed” could be a hint of mismatch in Preshared secrets.
  • Imagine using AES 128 for IKE Phase 1 and AES 256 for IKE Phase 2. This not only doesn’t add security (due to a shorter key in phase 1), but also costs performance!

You can read more here.

Identity Awareness

To authenticate/collect user information whose traffic is passing the Check Point Gateway, there are four options:

  1. Active Directory Query (Security Event Logs)
  2. Captive Portal (redirection on browser)
  3. Agents (Terminal Services or Endpoint)
  4. VPN

Three basic steps must be taken to achieve Identity Awareness:

  1. Enabling the software Blade on Check Point nodes
  2. Creating Access Roles specifying at least Network and Users [groups]
  3. Assigning the Access Roles to Policy Rules source or destination
  4. [Optional] For Captive Portal redirection, it is required to edit the Accept Action Properties and check the redirection option.
  • When using Captive Portal authentication, to redirect the traffic, Gateway DNATs destination’s IP to Captive Portal’s IP!
  • Keep in mind that allowing DNS requests might be necessary in a preceding rule
  • User Authentication rules are  not applied on a first match basis!

Logging

It’s clear that per-rule logging is configured via the Track option for each rule and the logs can be seen on SmartView Tracker. But the Logging blade can be granularly manipulated from  Global Properties > Log and Alert.

One interesting point here is the Time Settings > Excessive log grace period. The default value, 62 seconds, means that for a continuous stateless/connectionless traffic a log will be generated every 62 seconds. This makes logging impressively efficient when the gateway is under DDoS. The goal is not getting many messages for the same event!

SmartLog is another interesting tool which is really handy when working with different log files. Besides that, basic Logging setting including destination Log Server, Log storage, etc. can be modified inside Check Point Gateway node setting via Logs menu.

Monitoring

SmartView Monitor is the answer to “How is everything?”. It provide stats/status of Gateways, Traffic, Counters, Tunnels, Users and more!

While using the Active mode in SmartView Tracker could be very resource intensive, it is possible to create and view Suspicious Activity Rules in SmartView Monitor. These rules have their own space and won’t be applied to Policy Packages.

Monitoring blade should be checked on each Gateway which needs to be monitored, and on the Management Server, the Management Monitoring blade should be chosen.

It can happen that while trying to see the traffic with SmartView Monitor, you face an error similar to “Could not connect to SmartView Monitor. Make sure that the Monitoring blade is up and running”. A trick to this case could be re-installing the policy!

In case you have configured Alerts, do not forget to Start System Alert Monitor in SmartView Monitor via  Options > Tools.

Backup & Recovery

There are three Backup options:

Type Relative Size Includes GUI CLI web
DB Version ~50MB Policy & Objects Yes dbver No
Backup ~500MB GAiA Config and CP Dbase No show/add/set backup Yes
Image/Snapshot ~5000MB Full OS Partition No show/add/set snapshot Yes
  • GAiA config is referring to the underlying OS configuration.
  • CP Dbase means Policy & Objects

License Management & SmartUpdate

There are two License Management strategies in Check Point environments:

  • Central: The licenses are bound to Management Server’s IP Address
  • Local: The licenses are linked to Gateway’s IP Address

Here, changing the IP Address, will lead to losing the license!

SmartUpdate is the place to assign and attach the licenses, updating packages and hotfixes. An interesting feature to mention is Pre-Install Verifier, which basically verifies that

  1. The Package is appropriate for the Gateway and SIC is established
  2. Enough disk space is available
  3. The package has not been pushed to the Gateway

CLI

Not talking that much about CLI, doesn’t mean that it’s not important!

As mentioned earlier, GAiA is based on RedHat Linux. After accessing the Console, initially you are logged into GAiA SuperShell (clish). To access the linux shell, when means going into expert-mode, expert command has to be used. Here you can run tcpdump, ifconfig, netstat, etc.

Unlike Cisco IOS, here you have to use tab to see the available commands:

Just to mention some commands:

  • Before the first expert-mode login, a password should be set for “expert
  • Password reset of Security Administrator
  • Checking Captive Portal logged-in users
  • Removing the current association of a user:
  • To monitor the status of an IP
  • Creating a Database revision and verifying that on Management Server
  • Going back to clish
  • To check SIC state on a Gateway:
  • To check validity of a feature license:
  • Status of current running OS
  • Traffic Capture, 40 bytes of each packet, save as capture.pcap
Share this!

Author: Mo Moghaddas

Amateur​ photographer, IP geek, In love with Networks, Living in the Internet!

Leave a Reply

Your email address will not be published. Required fields are marked *