OVERVIEW
1.Firewall Basic
2.Introduction to Check Point Technology
3.Checkpoint Deployment Methods
4.Checkpoint Architecture Overview
5.Installing New Security Gateway (R80)
6.Lab: - Working on few general commands
7.Checkpoint R80 Overview and Differences
8.Best practice for firewall rules
9.NAT, Backup
10.Logging
11.VPN and ClusterXL
12.Introduction to Check Point Management API
13.Troubleshooting
Firewall Basic: What is Firewall
A firewall is a system of hardware and/or software that controls access between two or more networks.
Firewall sits at the junction point or gateway between the two networks, usually a private network and a public network such as the Internet.
Security is an extensive and serious issue in today's environment.
With a firewall , you can ensure
– To safeguard corporate trusted network from internet
– To separate networks from one another and impose rules that regulate data traffic flows from one network to another
– To regulate authorized access to corporate resources
– To audit and analyze network traffic
– To prevent network threats spreading from one network to other
Firewall Basic: Types of firewall
Application Layer Firewalls
Introduction to Check Point Technology
• Founded in 1993
• Headquartered at Tel Aviv, Israel
• Worldwide leader in delivering security solutions for networks, data and endpoints under unified management framework
• Invented and patented Stateful inspection technology
• 100% of Fortune 100 companies use Check Point solutions
• 98% of Fortune 500 companies use Check Point solutions
Check Point technology addresses network deployments and security threats while providing administrative flexibility and accessibility. To accomplish this, Check Point uses a unified Security Management architecture and the Check Point Firewall. These Check Point features are further enhanced with the SmartConsole interface and the Gaia operating system. This chapter provides a basic understanding of these features and enhancements.
Deployment Platforms
Additional Check Point Appliance Solutions
Choosing the right security appliance for a specific deployment situation can be a challenging task. However, Check Point appliance solutions are prepared to meet the challenge. Additional appliances designed to meet even more specialized security functions are also available, such as DDoS Protector appliances, management appliances, and virtual systems. Leverage the Check Point Appliance Sizing Tool, to select the right appliance based on your specific environment and security needs. Check Point’s Security Power provides an effective metric for selecting the appliance that can best meet your network security needs for today and provide room for growth.
Open Servers
Check Point software technology can be also be deployed on open servers, or non-Check Point hardware. Open servers provide the benefit of bringing your own hardware, which provides the ability to increase RAM, CPU and disk space. With open servers, licensing is not hardware dependent and can be transferred between old and new hardware. Hardware compatibility, must be approved for the device to work and be supported by Check Point. In addition, there is no requirement to purchase all software solutions, only the necessary software blades.
Deployment Methods :-
Standalone Deployment
Distributed Deployment
Bridge Mode Deployment
Architecture overview
The
Three-tiered architecture
SmartConsole is the new unified application of Check
Point R80.10 Security Management. The new SmartConsole provides a consolidated solution to
manage the security of your organization:
Security Policy Management
Log Analysis
System Health Monitoring
Multi Domain Management
Notes: The communication with the
management server is based on web services on top of port 19009.Some blades use components of the former SmartDashboard views. Those components communicate with
the management server (FWM) using the CPMI
API on port 18190.
The Check Point Security Management Architecture is an object-oriented architecture that
uses graphical representations of real-world entities, such as users and gateways. These entities are configured, managed, and monitored through a single management console which provides the flexibility needed for organizations of all shapes and sizes to manage and secure their network. There are three essential components of the Check Point Security Management Architecture: SmartConsole, Security Management Server, and the Security Gateway.
SmartConsole
SmartConsole is a Graphical User Interface (GUI) used to manage the objects that represent network elements, servers, and gateways. These objects are used throughout SmartConsole for many tasks including creating Security Policies. SmartConsole is also used to monitor traffic through logs and manage Software Blades, licenses, and updates.
Security Management Server
When a Security Policy is created in SmartConsole, it is stored in the Security Management Server. The Security Management Server then distributes that Security Policy to the various Security Gateways. The Security Management Server is also used to maintain and store an organization’s databases, including object definitions and log files for all gateways.
Security Gateway
A security gateway is a gateway on which the Firewall Software Blade is enabled. It is also known as a Firewalled machine. Security gateways are deployed at network access points, or points where the organization’s network is exposed to external traffic. They protect the network using the Security Policy pushed to them by the Security Management Server.
CPM
The Main Management process
What does it do?
•Service
the (GUI) Clients (TCP/19009
via CPM web service)
•Database tasks (creating /deleting modifying
object)
•Policy compilation
•Empowers
the migration from our legacy Client-Side logic to Server-side logic
•Provides
the architecture for a consolidated management console
FWM
•Runs on
Security Management Server (SMS)
•Communication between SmartConsole applications and Security Management Server.
•Policy verification
& compilation.
•Management HA Sync.
•Command to check cpwd_admin list.
CPWD
•Runs on both SMS's and Security Gateways.
•WatchDog is a process that launches and monitors critical processes such as Check Point daemons on the local machine, and attempts to restart them if they fail.
•Among the processes monitored by Watchdog are cpd, fwd and fwm.
•Watchdog is controlled by the cpwd_admin utility.
•To learn how to start and stop various daemons, run cpwd_admin command.
•It is similar to the Unix process "init".
CPCA
•Check Point Internal Certificate Authority (ICA)
•SIC certificate pulling
•Certificate enrolment
•CRL fetch
•Admin WebUI
Note: By default, in MGMT HA, it runs only on "Active" Security Management Server. On the "Backup" Security Management Server, the "cpstat mg" command will show "SmartCenter CA is not running".
CPD
•Runs on both SMS's and Security Gateways.
•Handel licencing and checkpoint update.
•Handel SmartView Monitor
•pushing/fetching policy between the SMS and Security Gateway Port 18191
•Handles generic functions such as SIC/certificates. Port 18211
FWD
•Runs on both SMS's and Security Gateways
•Mainly handles passing of logs from the Security Gateways to the SMS.
•On the Security Gateway also acts as a parent process to many security server processes that do advanced inspection outside the kernel for example VPND.
VPND
•IKE (UDP/TCP)
•NAT-T
•Tunnel Test
•Reliable Datagram Protocol (RDP)
•Topology Update for SecureClient
•SSL Network Extender (SNX)
•SSL Network Extender (SNX) Portal
•Remote Access Client configuration
•Visitor Mode
•L2TP
Note:- This process is not monitored by Check Point WatchDog.
RTMD
-Responsible for Real Time traffic statistics
-The following command displays monitoring data in bytes-per-sec for the top 50 services passed on interface hme1.
-rtm monitor localhost hme1 -g topsvc -y b
Network Communication
Secure Internal Communication (SIC)
SIC is based on certificates. When your Security Management Server (SMS) is initially loaded, part of the post-installation is the initialization of the Internal Certificate Authority (ICA). The SMS is a full-featured certificate authority and the first thing the ICA does is create a certificate for itself (the "SMS-Cert"). The SMS-Cert is presented when you connect to the SMS with any of the SmartConsole GUI tools to validate the identity of the SMS. The SMS-Cert is also presented to Security Gateways when a policy is being pushed to validate the identity of the SMS. You can view the SMS-Cert from the SmartDashboard by going to Manage...Servers and OPSEC Applications...internal_ca...Local Security Management Server...View. The ICA setup can be viewed by running cpconfig on the SMS and can be reset using the fwm sic_reset command.
The goal of initializing SIC/trust between an SMS and Security Gateway is to have the ICA create a certificate for the Security Gateway (FW-Cert) and assign it to the Security Gateway. Once that is accomplished, all communication between the SMS and Security Gateway is authenticated and encrypted using a certificate exchange. Once a new Security Gateway has been loaded and placed on the network, it needs a SMS to assign it a certificate ("establish trust") so it can receive a security policy and start performing useful work. But there is a problem: How does the new Security Gateway know that the SMS offering it a certificate is really the authorized SMS and not an impostor trying to gain control of the Security Gateway?
This initial trust problem is solved by the use of a SIC activation key. During the Security Gateway post-installation the administrator is prompted for an activation key. This is essentially a pre-shared secret (very similar to IKE Phase 1 authentication) that will be used to establish a one-time trust between the SMS and Security Gateway so it can receive the FW-Cert. When an object representing the new firewall is created in the SmartDashboard, you'll be prompted for an activation key. When you hit the Initialize button the SMS and Security Gateway perform a two-way challenge and essentially convince each other that they both have the same value for the activation key. Once the Security Gateway receives its FW-Cert the activation key is thrown away and is no longer valid; even if an attacker learns the activation key after the fact it does them no good.
From that point on all communication between the SMS and Security Gateway is authenticated and encrypted using SMS-Cert & FW-Cert and trust has been established between the two entities.
Internal Certificate Authority
SIC is based on certificates. When your Security Management Server (SMS) is initially loaded, part of the post-installation is the initialization of the Internal Certificate Authority (ICA). The SMS is a full-featured certificate authority and the first thing the ICA does is create a certificate for itself (the "SMS-Cert"). The SMS-Cert is presented when you connect to the SMS with any of the SmartConsole GUI tools to validate the identity of the SMS. The SMS-Cert is also presented to Security Gateways when a policy is being pushed to validate the identity of the SMS. You can view the SMS-Cert from the SmartDashboard by going to Manage...Servers and OPSEC Applications...internal_ca...Local Security Management Server...View. The ICA setup can be viewed by running cpconfig on the SMS and can be reset using the fwm sic_reset command.
The goal of initializing SIC/trust between an SMS and Security Gateway is to have the ICA create a certificate for the Security Gateway (FW-Cert) and assign it to the Security Gateway. Once that is accomplished, all communication between the SMS and Security Gateway is authenticated and encrypted using a certificate exchange. Once a new Security Gateway has been loaded and placed on the network, it needs a SMS to assign it a certificate ("establish trust") so it can receive a security policy and start performing useful work. But there is a problem: How does the new Security Gateway know that the SMS offering it a certificate is really the authorized SMS and not an impostor trying to gain control of the Security Gateway?
This initial trust problem is solved by the use of a SIC activation key. During the Security Gateway post-installation the administrator is prompted for an activation key. This is essentially a pre-shared secret (very similar to IKE Phase 1 authentication) that will be used to establish a one-time trust between the SMS and Security Gateway so it can receive the FW-Cert. When an object representing the new firewall is created in the SmartDashboard, you'll be prompted for an activation key. When you hit the Initialize button the SMS and Security Gateway perform a two-way challenge and essentially convince each other that they both have the same value for the activation key. Once the Security Gateway receives its FW-Cert the activation key is thrown away and is no longer valid; even if an attacker learns the activation key after the fact it does them no good.
From that point on all communication between the SMS and Security Gateway is authenticated and encrypted using SMS-Cert & FW-Cert and trust has been established between the two entities.
R80.10-mgmt-architecture-overview
Basic Packet Flow
Many organizations may include remote
gateways as a part of their overall network topology. To manage a remote
gateway, administrators must explicitly define Control Connection rules on
their local gateways to ensure that the Security Management Server can
interface with the remote gateway. The Security Management Server must be able
to send information to the remote gateway, such as during policy installation,
and receive data, such as logs and alerts from the remote gateway.
Installing and Managing a Remote Security Gateway
•The FTW (First Time Wizard) can be ‘completed’ on the command line using the command:
̶ config_system
̶ config_system -f b-gw.config
install_security_gw="true“
install_security_managment="false“
gateway_daip="false“
install_ppak="true“
gateway_cluster_member="true“
download_info="true“
upload_info="false“
ftw_sic_key=sic123
hostname=B-GW
domainname=alpha.cp
timezone='Europe/London’
iface=eth1
ipstat_v4=manually
ipaddr_v4=192.168.21.1
masklen_v4=24
ntp_primary=ntp.checkpoint.com
ntp_primary_version=2
primary=192.168.11.101
secondary=8.8.8.8
tertiary=158.43.128.1
Working on few general commands
Use the clish command before show configuration.
cpstat
cpstat fw
cpstat os -f cpu
cpstat os -f memory
cp_conf
cp_conf admin get # Get the list of administrators
cp_conf finger get # Get Certificate's Fingerprint
cp_conf lic get * cplic print is a similar command
Other commands to try:
ip addr
route –n
arp –an
dmesg | grep eth2
cpstat fw
cphaprob stat
cpstat fw –f policy
Checkpoint R80 Overview and Differences
ClusterXL Modes
ClusterXL has four working modes. This section briefly describes each mode and its relative advantages and disadvantages.
• Load Sharing Multicast Mode
• Load Sharing Unicast Mode
• New High Availability Mode
• High Availability Legacy Mode
Load Sharing Multicast Mode
Load Sharing enables you to distribute network traffic between cluster members. In contrast to High Availability, where only a single member is active at any given time, all cluster members in a Load Sharing solution are active, and the cluster is responsible for assigning a portion of the traffic to each member. This assignment is the task of a decision function, which examines each packet going through the cluster, and determines which member should handle it. Thus, a Load Sharing cluster utilizes all cluster members, which usually leads to an increase in its total throughput.
ClusterXL uses the Multicast mechanism to associate the virtual cluster IP addresses with all cluster members. By binding these IP addresses to a Multicast MAC address, it ensures that all packets sent to the cluster, acting as a Security Gateway, will reach all members in the cluster. Each member then decides whether it should process the packets or not. This decision is the core of the Load Sharing mechanism: it has to assure that at least one member will process each packet (so that traffic is not blocked), and that no two members will handle the same packets (so that traffic is not duplicated).
Load Sharing Unicast Mode
Load Sharing Unicast mode provides a Load Sharing solution adapted to environments where Multicast Ethernet cannot operate. In this mode a single cluster member, referred to as Pivot, is associated with the cluster virtual IP addresses, and is thus the only member to receive packets sent to the cluster. The pivot is then responsible for propagating the packets to other cluster members, creating a Load Sharing mechanism. Distribution is performed by applying a decision function on each packet, the same way it is done in Load Sharing Multicast mode. The difference is that only one member performs this selection: any non-pivot member that receives a forwarded packet will handle it, without applying the decision function. Note that non-pivot members are still considered as "active", since they perform routing and firewall tasks on a share of the traffic (although they do not perform decisions.)
When a failover event occurs in a non-pivot member, its handled connections are redistributed between active cluster members, providing the same High Availability capabilities of New High Availability and Load Sharing Multicast. When the pivot member encounters a problem, a regular failover event occurs, and, in addition, another member assumes the role of the new pivot. The pivot member is always the active member with the highest priority. This means that when a former pivot recuperates, it will retain its previous role.
High Availability
In a High Availability cluster, only one member is active (Active/Standby operation). In the event that the active cluster member becomes unavailable, all connections are re-directed to a designated standby without interruption. In a synchronized cluster, the standby cluster members are updated with the state of the connections of the active cluster member.
In a High Availability cluster, each member is assigned a priority. The highest priority member serves as the Security Gateway in normal circumstances. If this member fails, control is passed to the next highest priority member. If that member fails, control is passed to the next member, and so on.
Upon Security Gateway recovery, you can maintain the current active Security Gateway (Active Up), or to change to the highest priority Security Gateway (Primary Up).
ClusterXL High Availability supports IPv4 and IPv6.
High Availability Legacy Mode
When configured to work in the High Availability Legacy Mode, all cluster members are assigned the same shared IP and MAC addresses. A shared interface is an interface whose MAC and IP addresses are identical to those of another interface.
The principal advantage of using this mode is that moving from one Security Gateway deployment to a High Availability cluster requires no changes to IP addresses or routing. Any switch or hub can connect to cluster interfaces. The disadvantage is that configuring this mode is complicated, and must be performed in a precise sequence. You must connect the Security Management Server either to the cluster synchronization network or to a dedicated management network.
Introduction to Check Point Management API
R80 adds a new way to read information and to send commands to the Check Point management server. Just like it is possible to create objects, work on the security policy using the SmartConsole GUI, it is now possible to do the same using command line tools and through web-services.
There are four ways to communicate use the management APIs:
1) Typing API commands from a dialog inside the SmartConsole GUI application.
2) Typing API commands using the "mgmt_cli" executable (available in both Windows, Linux/Gaia flavors).
3) Typing API commands using Gaia's secure shell (clish).
4) Sending API commands over an https connection using web-services.
Troubleshooting
Cluster Troubleshooting Commands
cphaprob stat -Tells you the state of the cluster
cphaprob –i list -Lists the critical devices that are considered for failure
cphaprob –a if -Shows the state of real and virtual cluster interfaces
fw ctl pstat -At the end of the output this tells you the status of state sync
tcpdump –i eth1 port 8116 –X -Captures sync and CCP communication packets
fw tab –t connections –s -Shows the number of connections in the state table in summary (-s)
watch –d “fw tab –t connections –s” -As above but updates every 2 seconds
cpstat ha -Cluster stats
cpstat fw -Firewall stats
cpstat –f all os -Lots of potentially useful information
cphaprob stat –i list -Shows the faildevice as having a problem
cphaprob –d faildevice –s ok report -Changes the status of the faildevice to ok
cphaprob -d faildevice unregister -Unregisters the device
cphaprob –d faildevice –s problem –t 0 register -Creates a device called faildevice and denotes that it has a problem
The CPView user interface has three sections: View,
Navigation and Header. The View section simply displays the retrieved
statistics. The Navigation section shows the navigation menus and their
sub-menus. The Header section displays the time at which the statistics shown
were gathered, which is updated every time the statistics are refreshed.
[Expert@A-GW-02:0]# cpview --help
Usage: cpview [ [-t [<timestamp>]] | [-c <conf_file>] | [-p] ] | [-b [-t <sec> [-i <count>] [-j] [-l <filesize>] ] | [-s]] | [history [on] | [off] | [stat]]
-t Show history content. Show oldest available content, or from a given <timestamp>
<timestamp> format: [Jan..Dec] [01..31] [4-digit Year] [hh:mm:ss]
-c Loads configuration from <conf_file>
-p Prints all cpview data
-b Print batch statistics data
-t Show history content. Show oldest available content, or from a given <timestamp>
-i Limit dump info to <count> times
-j Compresses the generated logs after you run cpview -b -s to stop the instance
-l Change log file size limit to <filesize>MB (default: 1024MB)
-s Stops "cpview -b" instance that runs in the background history,Controls the history daemon.
on Starts the history daemon
off Stops the history daemon
stat Check whether history daemon is activated
export Export the history database
THANK YOU
