Manual CCSE R80.10 PDF

SECURITY ENGINEERING
S t u d e n t & L a b M a n u a l
R 8 0 . 1 0
© 2017 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed under
licensing restricting their use, copying, distribution, and de-compilation. No part of this product or related
documentation may be reproduced in any form or by any means without prior written authorization of Check
Point. While every precaution has been taken in the preparation of this book, Check Point assumes no
responsibility for errors or omissions. This publication and features described herein are subject to change
without notice.
RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
52.227-19.
TRADEMARKS:
Refer to the Copyright page (http://www.checkpoint.com/copyright.html) for a list of our trademarks.
Refer to the Third Party copyright notices (http:// www.checkpoint.com/
3rd_party_copyright.html) for a list of relevant copyrights and third-party licenses.
International  5 Ha’Solelim Street

Headquarters Tel Aviv 67897, Israel
Tel: +972-3-753 4555
U.S. Headquarters 959 Skyway Road, Suite 300

San Carlos, CA 94070
Tel: 650-628-2000
Technical Support,  6330 Commerce Drive, Suite 120

Education & Professional Irving, TX 75063
Services Tel: 972-444-6612
E-mail comments or questions about our courseware to: courseware@us.checkpoint.com
For questions or comments about other Check Point documentation, e-mail:
CP_TechPub_Feedback@checkpoint.com
Document # DOC-Manual-CCSE-R80.10
Revision R80.10 v4
Content Joey Witt, Vanessa Johnson
Graphics Chunming Jia, Vanessa Johnson
Contributors Beta Testing, Content Contribution, or Technical Review
Michael Adjei - Wick Hill - United Kingdom
Chris Alblas - QA - England
Eric Anderson - Netanium - USA
Michael Curtin - ContentWise - Australia
Piotr Czopik - CLICO - Poland
Brent Denny - Dimension Data Learning Solutions - Australia
Valery Fraerman - Diona Master Lab - Russia
Alfred Goh - M.Tech Products - Singapore
Desmond Gooh - M.Tech Products - Singapore
Tim Hall - Shadow Peak - USA
Oliver Jantz - Arrow ECS - Germany
Mario Jehmlich - Arrow ECS - Germany
Anthony Joubaire - Arrow ECS - France
Sanjay Kanesamoorthy - Red Education - Australia
Arno Kobarg - Red Education - Australia
Alfred Koebler - Westcon - Germany
Yasushi Kono - Arrow ECS - Germany
Fabrizio Lamanna - Check Point Software Technologies - USA
Jani Lindner - S&T - Slovenia
Dries Mertens - Westcon - Belgium
Carlos Moncayo - Rese - Colombia
Thomas Norbeck - Glasspaper - Norway
Richard Parkin - Arrow ECS - England
Jigarkumar Patel - Check Point Software Technologies - USA
Mika Rantanen - Hawkware Training - Finland
Jason Ross - Red Education - Australia
Niklas Savstrom - Infinigate - Sweden
Fedor Tsyganov - Softline Group - Russia
Madhava V - ITecSys Technologies - India
Sandra Van Loon - Avent - The Netherlands
Erik Wagemans - Proximus ICT Academy - Belgium
Special Thanks:
Glen Bayless - Check Point Software Technologies - USA
Fabrizio Lamanna - Check Point Software Technologies - USA
Kim Winfield - Check Point Software Technologies - USA
Daniel Storey - Red Education - Australia (Sydney Beta Host)
Kia Wentzel - Arrow ECS - Finland (Helsinki Beta Host)
Certification Exam Development:
Jason Tugwell
Check Point Technical Publications Team:
Uri Lewitus, Daly Yam, Eli Har-Even, Paul Grigg, Rachel Teitz, Ronit Segal, Shira Rosenfeld, Yaakov Simon,
Devora Hosseinof
Table of Contents
Preface: Security Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Check Point Security Engineering Course ................................................................................................... 13
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Course Chapters and Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Lab Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Related Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 1: System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Advanced Gaia ............................................................................................................................................. 17
Gaia Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Upgrades ....................................................................................................................................................... 21
Upgrade Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Advanced Upgrade with Database Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Lab 1.1: Upgrading to R80.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Migrating Management Server Data ............................................................................................................ 25
Installing the Security Management Server .................................................................................................. 38
Configuring Security Management Server Using the Gaia Portal ............................................................... 43
Installing SmartConsole ............................................................................................................................... 59
Importing the Check Point Database ............................................................................................................ 66
Launching SmartConsole and Reconfiguring Existing Security Policies .................................................... 73
END OF LAB 1.1 88
Hotfixes ........................................................................................................................................................ 89
The CPUSE Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
The Central Deployment Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Lab 1.2: Applying Check Point Hotfixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Installing the Hotfix on the Security Gateways ............................................................................................ 95
END OF LAB 1.2 102
4
Check Point Security Engineering
Lab 1.3: Configuring a New Security Gateway Cluster . . . . . . . . . . . . . . . . . . . . . . . 103

Installing a Second Security Gateway ........................................................................................................ 104
Configuring the Bravo Security Gateway with the First Time Configuration Wizard .............................. 113
Using the Gaia Portal to Configure the Security Gateway ......................................................................... 124
Re-configuring the Primary Gateway ......................................................................................................... 135
Configuring the Alpha Security Policy to Manage the Remote Security Gateway Cluster ....................... 146
END OF LAB 1.3 182
CLI Commands .......................................................................................................................................... 183

CPInfo ........................................................................................................................................................ 191
Lab 1.4: Core CLI Elements of Firewall Administration . . . . . . . . . . . . . . . . . . . . . 193

Managing Policy and Verifying Status from the CLI ................................................................................ 194
Using cpinfo ............................................................................................................................................... 196
Reconfiguring the Security Policies ........................................................................................................... 207
Using fw monitor ........................................................................................................................................ 211
Using tcpdump ........................................................................................................................................... 218
END OF LAB 1.4 219
Advanced Firewall ..................................................................................................................................... 220

Check Point Firewall Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
The Firewall Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Chain Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Lab 1.5: Viewing the Chain Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Evaluating the Chain Modules ................................................................................................................... 231
Modifying the Security Policy ................................................................................................................... 233
Reviewing Changes to the Chain Modules ................................................................................................ 237
END OF LAB 1.5 246
Stateful Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Security Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Kernel Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Policy Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Rule Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Firewall Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
5
Lab 1.6: Configuring Manual Network Address Translation . . . . . . . . . . . . . . . . . . 271

Configuring the Security Policy ................................................................................................................. 272
Configuring the ARP Table ........................................................................................................................ 283
Reconfigure the Alpha Rule Base .............................................................................................................. 291
END OF LAB 1.6 293
Review Questions ....................................................................................................................................... 294
Chapter 2: Automation & Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Automation & Orchestration ...................................................................................................................... 296
Check Point APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Check Point API Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Management API Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Management API Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Lab 2.1: Managing Objects Using the Check Point API . . . . . . . . . . . . . . . . . . . . . . 308
Configuring the Check Point API .............................................................................................................. 309
Defining and Editing Objects in the API .................................................................................................... 312
END OF LAB 2.1 321
Chapter 3: Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Advanced ClusterXL .................................................................................................................................. 324
Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
VMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Cluster Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Cluster Connectivity Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Add a Member to an Existing Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Sticky Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Management High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
OPSEC Certified Clustering Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Lab 3.1: Deploying a Secondary Security Management Server . . . . . . . . . . . . . . . . 339

Installing the Secondary Management Server ............................................................................................ 340
Configuring Management High Availability ............................................................................................. 344
Testing Management High Availability ..................................................................................................... 350
END OF LAB 3.1 364
VRRP Clusters ........................................................................................................................................... 365

VRRP Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
6
Lab 3.2: Enabling Check Point VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Viewing ClusterXL Failover ...................................................................................................................... 371
Defining a Virtual Router for VRRP .......................................................................................................... 375
Configuring the Security Policy for VRRP ................................................................................................ 387
END OF LAB 3.2 395
Chapter 4: Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

SecureXL: Security Acceleration ............................................................................................................... 398
Using SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Packet Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Session Rate Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
SecureXL Connection Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
VPN Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Lab 4.1: Working with SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Identifying Status of Current Connections ................................................................................................. 407
END OF LAB 4.1 412
CoreXL: Multicore Acceleration ................................................................................................................ 413

Using CoreXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Processing Core Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Dynamic Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Packet Flow with CoreXL and SecureXL Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Multiple Traffic Queues ............................................................................................................................. 421
Using Multi-Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Lab 4.2: Working with CoreXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Enabling CoreXL ....................................................................................................................................... 425
Reviewing CoreXL Settings ....................................................................................................................... 433
END OF LAB 4.2 434
Chapter 5: SmartEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

The SmartEvent Solution ........................................................................................................................... 437
SmartEvent Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
SmartEvent Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
SmartEvent Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
SmartEvent Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Defining the Internal Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
7
Identifying an Event ................................................................................................................................... 443

Monitoring the Network ............................................................................................................................. 449
Event Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Investigating Security Events ..................................................................................................................... 452
Importing Offline Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Remediating Security Events ..................................................................................................................... 454
Configuring Event Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Configuring IPS Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Reporting Security Events .......................................................................................................................... 458
Using Predefined Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Defining Custom Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Preventative Measures ................................................................................................................................ 461
Creating a New Event Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Reporting an Event to Check Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Eliminating False Positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
SmartEvent Example .................................................................................................................................. 463
High Availability Environment .................................................................................................................. 464
Security CheckUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Lab 5.1: Evaluating Threats with SmartEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Configure the Network Object in SmartConsole ....................................................................................... 467
Monitoring Events with SmartEvent .......................................................................................................... 476
END OF LAB 5.1 484
Chapter 6: Remote and Mobile Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Choosing Remote Access Solutions ........................................................................................................... 487
Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Secure Connectivity and Endpoint Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
SSL VPN versus IPSec (Layer 3) VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Clients ......................................................................................................................................................... 490
Mobile Access Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
SSL Network Extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Check Point Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Check Point Capsule Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
SecuRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Additional Remote Access Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
8
Check Point Capsule .................................................................................................................................. 492

Capsule Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Capsule Docs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Capsule Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Mobile Access Software Blade .................................................................................................................. 500
Mobile Access Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Mobile Access Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Gateway Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Mobile Access Deployment ....................................................................................................................... 507
Mobile Access Policy ................................................................................................................................. 508
Mobile Access Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Lab 6.1: Managing Mobile Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

Enable Mobile Access Blade ...................................................................................................................... 513
Configure the Check Point Capsule Policy ................................................................................................ 522
Testing Check Point Mobile Access .......................................................................................................... 538
END OF LAB 6.1 542
Chapter 7: Threat Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

The Threat Landscape ................................................................................................................................ 545
Zero-Day Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Advanced Persistent Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Intrusion Prevention System ...................................................................................................................... 546
IPS Profile Settings and Protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
IPS Tuning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Lab 7.1: Understanding IPS Protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Configuring the Protection Profile ............................................................................................................. 550
Configuring the IPS Demonstration Tool .................................................................................................. 563
Testing the Default Protections .................................................................................................................. 569
Modifying the Protection Profile Settings .................................................................................................. 571
Working with Logs & Monitor to Investigate Threats ............................................................................... 580
Modifying an Existing Protection Profile .................................................................................................. 581
END OF LAB 7.1 592
Geo-Protection ............................................................................................................................................ 593
9
Lab 7.2: Deploying IPS Geo Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Modifying Anti-Spoofing Settings ............................................................................................................. 596
Configuring IPS Geo Protection ................................................................................................................. 600
END OF LAB 7.2 606
Antivirus ..................................................................................................................................................... 607

Anti-Bot ...................................................................................................................................................... 608
Lab 7.3: Reviewing Threat Prevention Settings and Protections . . . . . . . . . . . . . . . 609

Review Threat Prevention Settings and Protections .................................................................................. 610
Testing EICAR Access ............................................................................................................................... 620
END OF LAB 7.3 622
Sandboxing ................................................................................................................................................. 623

OS-Level Sandboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
CPU-Level Sandboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Check Point SandBlast Zero-Day Protection ............................................................................................. 625
SandBlast Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
SandBlast Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
SandBlast Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
SandBlast Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
SandBlast Deployment ............................................................................................................................... 637
Public Cloud Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Hybrid Solution (SandBlast Appliance and Cloud) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
SandBlast Mobile ....................................................................................................................................... 639
SandBlast Mobile Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
SandBlast Mobile Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Lab 7.4: Deploying Threat Emulation and Threat Extraction . . . . . . . . . . . . . . . . . 645

Use ThreatCloud to Verify File Safety ....................................................................................................... 646
Configure Threat Emulation to Inspect Incoming Traffic .......................................................................... 648
END OF LAB 7.4 658
Review Questions ...................................................................................................................................... 659
10
Chapter 8: Questions and Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Chapter 1: System Management ................................................................................................................. 661
Chapter 2: Automation and Orchestration .................................................................................................. 662
Chapter 3: Redundancy .............................................................................................................................. 663
Chapter 4: Acceleration .............................................................................................................................. 664
Chapter 5: SmartEvent ............................................................................................................................... 665
Chapter 6: Remote and Mobile Access ...................................................................................................... 666
Chapter 7: Threat Prevention ..................................................................................................................... 667
11
P
P
R
Check Point Security Engineering E
F
Security Engineering A
C
E
Welcome to the Check Point Cyber Security Engineering course. This course provides an
advanced and in-depth explanation of Check Point technology. It includes advanced
upgrading, key techniques for building, deploying and enhancing network performance,
and management and troubleshooting features to mitigate security risks. The course is
intended to provide you with an understanding of the skills necessary to effectively design,
maintain and protect your enterprise network.
Preface Outline
• Prerequisites
• Course Chapters and Learning Objectives
• Lab Topology
• Related Certification
_____________________
_____________________ 12
Check Point Security Engineering Course

This course is designed for security experts and Check Point resellers who need to perform
advanced deployment configurations of a Security Gateway and are working towards their
Check Point Certified Security Engineering (CCSE) certification. The following professionals
benefit best from this course:
• System Administrators
• Support Analysts
• Network Engineers
P r e r e q u i s i te s
Successful completion of this course depends on knowledge of multiple disciplines related to
network-security activities including:
• UNIX and Windows operating systems

• Certificate management
• System administration
• CCSA training/certification
• Networking (TCP/IP)
C o u r s e C ha p te r s a nd L ea r ni ng O b j e c t i ve s
Chapter 1: System Management

• Understand system management procedures, including how to perform system
upgrades and apply hotfixes.
• Identify advanced CLI commands.
• Understand the Check Point Firewall infrastructure and other advanced Firewall
processes and procedures.
Chapter 2: Automation and Orchestration

• Recognize how Check Point’s flexible API architecture supports automation and
orchestration of daily operations.
• Understand how to use the management API command line tools and web services to
read information, create objects, work on Security Policies, and send commands to the
Check Point Security Management Server.
_____________________
_____________________ 13
Chapter 3: Redundancy
• Discuss advanced ClusterXL functions and redundancy.
• Describe VRRP network redundancy and its advantages.
Chapter 4: Acceleration
• Understand how SecureXL acceleration technology enhances and optimizes Security
Gateway performance.
• Understand how CoreXL acceleration technology enhances and improves Security
Gateway performance.
Chapter 5: SmartEvent
• Identify SmartEvent components used to store network activity logs and identify
events.
• Discuss the SmartEvent process that determines which network activities may lead to
critical security issues.
• Understand how SmartEvent can assist in detecting, remediating, and preventing
security threats targeting organizations.
Chapter 6: Remote and Mobile Access

• Recognize Check Point Remote Access solutions and how they differ.
• Discuss Check Point Capsule components and how they work to protect mobile devices
and business documents.
• Discuss the Mobile Access Software Blade and how it secures communication and data
exchange during remote connections.
• Understand Mobile Access deployment options.
Chapter 7: Threat Prevention

• Discuss different Check Point Threat Prevention solutions for dangerous attacks such
as zero-day and Advanced Persistent Threats.
• Understand how SandBlast, Threat Emulation, and Threat Extraction helps to prevent
security incidents.
• Identify how Check Point SandBlast Mobile helps protect an organization from threats
targeting company-issued smartphones and tablets.
_____________________
_____________________ 14
L a b To p o l o g y
Labs for this course were developed using VMware Workstation. Your instructor will have
information for the specific settings and configuration requirements of each virtual machine.
Most lab exercises will require you to manipulate machines in the virtual network. Review the
starting lab topology pictured below. Note the location of each server in relation to the Security
Gateways and how they are routed. Make sure you understand the purpose of each machine,
and the credentials and applications used throughout the course. As the course progresses, you
will add Virtual Machines to this topology during the lab exercises.
Figure 1 — Starting CCSE Lab Topology
Rel a te d C er ti fi c a t i o n
The Check Point Certified Cyber Security Engineer (CCSE) certification is designed for
partners and customers seeking to validate their expert level knowledge of Check Point’s
software products and security solutions. Students must have a valid CCSA certification before
challenging the CCSE exam.
_____________________
_____________________ 15
C
1
H
Check Point Security Engineering A
P
System Management T
E
R
Cyber Security experts are expected to acquire and apply in-depth knowledge of systems
used to securely manage the organization’s network infrastructure. This course begins
with a deep dive into the Check Point Gaia operating system, with how to use essential
CLI commands, perform upgrades, and apply hotfixes. We will also take a closer look at
the Check Point Firewall infrastructure, chain modules, kernel tables, packet flow, and
many more advanced Firewall processes and procedures.
Learning Objectives
• Understand system management procedures, including how to perform system upgrades and apply
hotfixes.
• Identify advanced CLI commands.
• Understand the Check Point Firewall infrastructure and other advanced Firewall processes and
procedures.
_____________________
_____________________ 16
Advanced Gaia
Check Point Gaia is the unified, revolutionary, secure operating system for all Check Point
appliances, open servers, and virtualized gateways. The cutting-edge technology combines the
best features of IPSO and Check Point’s original secure operating system, SecurePlatform, into
a single, harmonious operating system to provide greater operational efficiency and robust
performance.
The Makings of Gaia

Gaia was derived from IPSO and SecurePlatform. The IPSO operating system was developed
by Ipsilon Networks, a computer networking company specializing in IP switching during the
1990s. Nokia purchased Ipsilon Networks in 1997 and incorporated IPSO into their secure
network appliances. Check Point acquired Nokia’s Security business unit in April 2009.
As a stripped down operating system, IPSO provided enough functionality to run Check Point
Firewalls, along with the incorporation of some standard Unix commands, such as top, ps,
and df. It also provided great visibility into kernel statistics, such as network counters,
interrupts, and more.
Check Point’s SecurePlatform operating system is based on a kernel from Red Hat Software.
SecurePlatform’s hardened and optimized operating system eliminated software package
components that were unnecessary for a network security device and modified or removed
components that could present security risks. Its easy-to-use command shell provided a set of
commands required for configuration, administration, and system diagnostics, including
network settings, back up and restore utilities, upgrading, and system log viewing. Routine
management and maintenance of SecurePlatform was performed through a restricted shell
called Standard mode. Standard mode enhanced the security of SecurePlatform by restricting
access to utilities that, if used improperly, would damage system stability. SecurePlatform also
consisted of a Web Graphical User Interface (WebUI), which enabled users to easily configure
settings and perform first time installations.
SecurePlatform allowed all system resources to be dedicated to the operating system and the
installed Check Point products. With SecurePlatform, resources were no longer consumed by
software such as GUIs, office applications, and network file systems.
G a i a Fe a t u r e s a n d B e n e f i t s
Gaia supports the full suite of Check Point technologies, giving you improved connection
capacity and the full power of Check Point security.
_____________________
_____________________ 17
Check Point Gaia offers these key values:
• Combine the best features of IPSO and SecurePlatform.

• Increase operational efficiency with a wide range of features.
• Provide a secure platform for the most demanding environments.
Gaia simplifies and strengthens management with the segregation of duties by enabling role-
based administrative access. Additionally, Gaia greatly increases operational efficiency with
an advanced and intuitive software update agent, commonly referred to as the Check Point
Update Service Engine (CPUSE). Gaia management is made simple with the intuitive and
feature-rich WebUI, and instant search options for all commands and properties. The same
powerful CLI commands from IPSO and SecurePlatform have been seamlessly integrated into
Gaia, along with new commands and capabilities.
Figure 2 — Gaia Portal
_____________________
_____________________ 18
Key Features
Key features of Gaia include:
• Web-based User Interface with search navigation — This interface integrates all
Gaia operating system management functions into a dashboard that is accessible via the
most popular Web browsers, such as Internet Explorer, Chrome, Firefox, Opera, and
Safari. The built-in search navigation tool delivers instant results, and for the CLI-
inclined users, a Shell Emulator pop-up window is only a single click away.
• Full Software Blade support — Gaia provides support for comprehensive Security
Gateway and Security Management Software Blade solutions deployed on Check Point
appliances and open servers.
• High connection capacity — Utilizing the efficiency of a 64-bit operating system,
Gaia is capable of boosting the connection capacity of existing Check Point appliances.
• Role-based administrative access — Segregation of duties is part of a good Security
Policy because it improves operational efficiency and auditing of administrative events.
Role-based administrative access gives Gaia customers the ability and granularity to
customize their security management policies to meet their business needs. User
authentication and authorization is based on industry standard RADIUS and TACACS+
protocols. Specific levels of access can be granted based on each individual’s role and
responsibility.
• Intelligent software updates — With Gaia, software update times are shortened and
post-update testing is performed automatically. New releases and patches can be
scheduled for automatic download and installed during off-peak hours for minimal
business impact. Notification emails are sent about recommended updates and update
statuses.
• Native IPv4 and IPv6 support — Check Point Gaia allows easy interoperability with
both networking protocols.
• Clustering protocol support — Gaia fully supports ClusterXL, Check Point’s
proprietary network redundancy protocol, and standard VRRP on all Check Point
appliances, open servers, and virtualized environments.
• Manageable dynamic routing suite — Multiple dynamic routing and Multicasting
protocols are supported by Gaia, providing flexible and uninterrupted network
connectivity. All can be managed from both the Gaia portal or the CLI.
_____________________
_____________________ 19
Supported Protocols
Dynamic Routing Protocols Multicasting Protocols

• RIP RFC 1058 • IGMPv2 RFC 2236
• RIPv2 (with authentication) RFC • IGMPv3 RFC 3376
1723 • PIM-SM RFC 4601
• OSPFv2 RFC 2328 • PIM-SSM RFC 4601
• OSPFv3 RFC 5340 • PIM-DM RFC 3973
• OSPF NSSA RFC 3101 • PIM-DM state refresh draft-ietf-pim-refresh-02.txt
• BGP4 RFCs 1771, 1963, 1966,
1997, 2918
Table 1: Gaia Supported Dynamic and Multicasting Protocols
_____________________
_____________________ 20
Upgrades
As a Cyber Security Engineer, it is important to evaluate the overall health, compliance, and
performance of your network. This often entails the task of deciding whether to install new
hardware to fit business needs or to upgrade to newer software versions to ensure the
efficiency of the existing environment. Check Point recommends installing the most recent
software release to stay up-to-date with the latest functional improvements, stability fixes,
security enhancements, and protections against new and evolving attacks.
Upgrades provide added enhancements over an earlier version and eliminate the complexities
of re-creating product configurations, Security Policies, and objects. Before upgrading
appliances or open servers, verify the interoperability and upgrade path of your existing
environment and make use of the appropriate Check Point upgrade tools.
To upgrade from R77.XX to R80.10, an advanced upgrade with database migration process
must be performed. Upgrades from R80 to R80.10, are performed through the software update
agent, CPUSE.
NOTE
Upgrades to R80 and above are not supported from IPSO and
SecurePlatform. For more information, refer to Check Point’s Upgrade
Map.
U p g r a d e Too l s
Upgrade tools back up Check Point configurations, independent of hardware, operating
system, and Check Point security management platform version. Use the upgrade tools to back
up Check Point configuration settings on disk partitions of Check Point appliances and open
servers. Disk space requirements for upgrades vary based on the upgrade version. Before
starting an upgrade, refer to the release notes of the desired platform version to verify the space
requirements for each disk partition, such as the /var/log/ and root partitions.
There is a different package of upgrade tools for each platform. Download the latest version of
upgrade tools from the Check Point support site. Before upgrading, a valid service contract that
includes software upgrades and major releases must be registered to your organization’s Check
Point User Center account.
_____________________
_____________________ 21
The upgrade tools package consists of several files, including the files noted in the table below.
Package File Description

migrate.conf Holds configuration settings for Advanced Upgrade
with Database Migration.
migrate Runs Advanced Upgrade with migration.
pre_upgrade_verifier Analyzes compatibility of the currently installed
configuration with the upgrade version. It gives a report
on the actions to take before and after the upgrade.
Table 2: Upgrade Tools Package Files
Ad va n c e d U p g r a d e w i t h D a t a b a s e M i g r a t i o n
As in all upgrade procedures, it is best practice to upgrade the Security Management Server or
Multi-Domain Server before upgrading the Security Gateways. To upgrade from an earlier
software version, such as R77.30, to Check Point’s R80.10 security management platform, use
the Advanced Upgrade with Database Migration method to migrate the database and install the
software. With this method of upgrading, the current environment must meet these
requirements for database migration:
• Available disk space of at least five times the size of the exported database on the target
machine.
• Size of the /var/log folder of the target machine must be at least 25% of the size of
the /var/log directory on the source machine.
• Source and target servers must be connected to a network and the connected network
interface must have an IP address.
• If the source environments uses only IPv4 or only IPv6, the target must use the same IP
address configuration. For example, you cannot migrate to an IPv6 configuration if the
source environment uses only IPv4.
• The target must have the same or higher version and the same set of installed products.
• The appropriate package of upgrade tools must be download for each source platform.
• The correct ports for SmartConsole must be open in order for SmartConsole to
communicate with the Security Management Server.
After the requirements for database migration have been met, create a backup copy of the
existing system settings from the Gaia WebUI. Gaia operating system settings are not backed
up and must be configured manually if the database is restored later due to issues with the
upgrade. Take note of operating system settings (interfaces, servers, routes, system settings,
etc.) before upgrading.
_____________________
_____________________ 22
It is important to use the correct migration tool package to perform the upgrade. Use the
upgrade tools package for the software version you are upgrading too. For example, if
upgrading from R77.30 to R80.10, use the migration tools package for R80.10. Download and
extract the tools to the old server (R77.30). Use the migrate utility of the upgrade tools
package, to export the source Security Management Server database (R77.30) to a file, and
then import the file to the new server (R80.10).
NOTE
SmartEvent databases are not migrated during an advanced upgrade
because the databases can be very large. Migration of these databases must
be performed separately. Refer to sk110173 for information on how to
migrate the SmartEvent database.
The Upgrade Verification Service

Check Point’s Upgrade Verification Service is an upgrade verification and environment
simulation service created to help customers transition to R80.XX as seamlessly as possible.
The service will use configuration files from your current platform to simulate the environment
and verify that the upgrade can be successfully applied across the key features of the software.
The simulation will also ensure that the database is not corrupted during the upgrade process.
Upon completion, a status update of the simulation results along with advice on how best to
proceed will be provided. For more detailed information regarding the Upgrade Verification
Service, refer to sk110267.
L a b 1 .1
Upgrading to R80.10
_____________________
_____________________ 23
1.1
L
Upgrading to R80.10 A
B
This lab illustrates how to perform an upgrade of a Security Management Server from R77.30 to R80.10.
You will export the configuration of your old server to a Windows machine before installing a new R80.10
server. Once the fresh installation of the new OS is complete, you can then import the rules, objects, and
settings of the previous server into the database of the new, upgraded server.
Once the upgrade of the Security Management Server is complete, use CPUSE to upgrade a Security
Gateway.
Ta sks :
• Save the database information.
• Access the migrate file and transfer via SSH/SCP.
• Perform a clean installation of R80.10 Security Management Server.
• Configure the Security Management Server.
• Install R80.10 SmartConsole.
• Import the database.
• Upgrade the Security Gateway.
Pe r for ma n c e Ob j ec t ive s:
• Use the migrate export command to prepare to upgrade a Security Management Server.
• Perform an installation of a Security Management Server.
• Use the migrate import command to populate the database of a Security Management Server.
• Perform an upgrade of Security Gateways in a clustered environment.
_____________________
_____________________ 24
Migrating Management Server Data

Export the rules and objects off of the existing Security Management Server so that they can be imported
into the new server.
1. From A-GUI, open a Web browser and use HTTPS to connect to A-SMS (10.1.1.101).
2. Use the following credentials to log into the Gaia Portal on A-SMS:
Username: admin
Password: Chkp!234
3. In the navigation pane, click User Management > Users.

4. Use the information below to create a new user:
Login Name: scpadmin

Password: Chkp!234
Home Directory: /home/scpadmin
Shell: /bin/bash
Assigned Roles: adminRole
Access Mechanisms: Web
Command Line
5. Click OK.
6. Sign out of the Gaia Portal.
7. Close the web browser.
_____________________
_____________________ 25
8. From A-GUI, use the following credentials to log into WinSCP and connect to the A-SMS:
File Protcol: SCP

Host Name: 10.1.1.101
User Name: scpadmin
Password: Chkp!234
Figure 3 — WinSCP Login
9. In WinSCP, confirm that the left pane displays the local directory and the right pane displays the
remote directory.
10. In the right pane, navigate to the /var/log directory of the old R77.30 Security Management Server:
11. In the left pane (local directory), browse to the location of the Upgrade Tools.
NOTE
Ask your instructor for the location and name of the upgrade tools file. Though the
name varies, the upgrade tools for R80.10 are called: p1_upgrade_tools.tgz
_____________________
_____________________ 26
12. Create a new directory called tmp in the /var/log directory, if needed.
13. Move the file from A-GUI to the /var/log/tmp directory on A-SMS, and the system displays the
following window:
Figure 4 — Upload
_____________________
_____________________ 27
14. Click the Transfer Settings button, and configure the transfer to be in Binary mode:
Figure 5 — Binary Mode
15. Click OK.

16. Click OK, to continue the file transfer.
17. Highlight the copied file in the right pane of WinSCP and right-click.
_____________________
_____________________ 28
18. From the Context Menu, select Custom Commands > UnTar/Gzip:
Figure 6 — Special Commands - UnTar/Gzip
19. Click OK, to extract the directory to the following location:
/var/log/tmp
_____________________
_____________________ 29
20. After the extraction completes, verify that the following folder now appears in /var/log/tmp:
migrate_tool
Figure 7 — migrate_tool Folder
_____________________
_____________________ 30
21. From the WinSCP window, click the PuTTY Login button.
22. PuTTY logs into the A-SMS server (10.1.1.101) at the /home/admin directory:
Figure 8 — PuTTY Session
NOTE
If you are asked to enter the password for scpadmin, enter the following:
Chkp!234
_____________________
_____________________ 31
23. Verify that all consoles are closed by issuing the following command:
cpstat mg
Figure 9 — cpstat mg
NOTE
The Connected Clients list should be empty. If it is not, execute the cpstop command
to force close all open clients.
24. Change to the following directory by executing the following command:
cd /var/log/tmp/migrate_tool
_____________________
_____________________ 32
25. Type the following command and press Enter, to view the contents of the folder:
ls
Figure 10 — migrate_tool Folder
26. Type the following command:
./migrate export A-SMS-from-r7730-to-r8010.tgz
_____________________
_____________________ 33
27. Press Enter, to run the script. The system asks the following question:
Figure 11 — Warning
_____________________
_____________________ 34
28. Type y, and press Enter. The system exports the data, creates the export file, and identifies its location
on the server:
Figure 12 — Export Complete
NOTE
The time it takes for this process to complete may vary depending on the size of your
Security Policy, number of objects in the database, and database revisions. Once
complete, the system provides the location of the exported file and returns to the
Expert mode command prompt.
_____________________
_____________________ 35
29. While still in the PuTTY session on A-SMS, initiate an FTP session back to A-GUI (10.1.1.201).
NOTE
You can also use the WinSCP session that is still open to transfer the file.
30. Type the following commands and press Enter, to prepare to transfer the file:
bin
hash
31. Type the following command, and press Enter:
put A-SMS-from-r7730-to-r8010.tgz
NOTE
You may want to transfer the file using WinSCP instead of FTP. Just be sure to use
Binary Mode for the transfer.
32. Verify that the A-SMS-from-r7730-to-r8010.tgz file has been transferred to A-GUI.
_____________________
_____________________ 36
33. Close the WinSCP session.

34. In the PuTTY session to A-SMS, issue the following command:
shutdown now -h
Figure 13 — shutdown now -h
35. Exit PuTTY.

36. Verify that the A-SMS virtual machine is powered down before continuing.
_____________________
_____________________ 37
Installing the Security Management Server

Install the R80.10 Management Server. It will manage the Security Gateway cluster for this site.
1. In VMware, verify that the settings for the new A-SMS Virtual Machine is defined as follows:
◦ Name: A-SMS
◦ Memory: 10GB
◦ Processors: 4
◦ Hard Disk: 80GB
◦ CD/DVD (SATA): Points to R80.10 ISO
◦ Network Adapter: One Interface
• Connected
• Connect at power on
• LAN Segment: LAN 1
NOTE
Your classroom configuration may be different. Check with your instructor before
continuing to the next step.
_____________________
_____________________ 38
2. Power on the A-SMS virtual machine, and the Welcome to Check Point Gaia R80.10 screen appears:
Figure 14 — Welcome to Check Point Gaia R80.10
3. Within 60 seconds, highlight the option Install Gaia on this system.
_____________________
_____________________ 39
4. Press the Enter key, to launch the installation:
Figure 15 — Welcome
5. At the Welcome screen, highlight OK, and press Enter.

6. Select the keyboard to suit your region.
7. At the Partitions Configuration screen, modify the Logs partition to be 30GB:
Figure 16 — Partitions Configuration
_____________________
_____________________ 40
8. At the Account Configuration screen, enter and confirm Chkp!234 as the password for the OS Level
admin account.
NOTE
Verify that NumLock is on. It is not on by default after installation. If you haven’t
already turned it on, do so now and re-enter and confirm your password. If you enter
this password without turning NumLock on, you will not be able to log into the
system.
9. Tab to OK, and press Enter.

10. Use the following information to configure the Management Interface (eth0) screen:
IP Address: 10.1.1.101
Netmask: 255.255.255.0
Default Gateway (IP): 10.1.1.1
Figure 17 — Management Interface (eth0) Configured
11. Select OK, and press Enter. The system displays the Confirmation screen.
_____________________
_____________________ 41
12. In the Confirmation screen, select OK, and press Enter to proceed. After the drive is formatted and the
installation is complete, the system displays the Installation Complete screen:
Figure 18 — Installation Complete
13. Press Enter to reboot A-SMS.
_____________________
_____________________ 42
Configuring Security Management Server 

Using the Gaia Portal
Follow these steps to configure the primary Security Management Server for your configuration.
1. From the A-GUI virtual machine, launch an Internet browser.

2. In the address field, type the following:
https://10.1.1.101
NOTE
Be sure that you are using HTTPS. You may also need to verify that the LANs in
VMware are configured properly before you are able to connect. Both the GUI client
machine (A-GUI) and the Security Management Server (A-SMS) reside on LAN 2,
if you are following the recommended classroom topology. Consult your instructor,
if you are using a different configuration.
3. Press Enter, and your browser should warn you that the site’s Security Certificate is from an untrusted
source.
NOTE
Ignore this warning and continue to the site.
_____________________
_____________________ 43
4. Log into A-SMS with the following credentials:
Login: admin
Password: Chkp!234
Figure 19 — R80.10 Gaia Portal Login
_____________________
_____________________ 44
5. Press Enter, and the system displays the following message:
Figure 20 — R80.10 First Time Configuration
6. Click Next, and the system displays the deployment Options page.
7. Verify that the following option is selected:
Continue with Gaia R80.10 configuration
_____________________
_____________________ 45
8. Click Next, and the system displays the Management Connection window:
Figure 21 — Network Connection
9. Use the information below to verify that the Security Management Server’s network connection is
configured properly:
Interface: eth0
Configure IPv4: Manually
IPv4 Address: 10.1.1.101
Subnet Mask: 255.255.255.0
Default Gateway: 10.1.1.1
Configure IPv6: Off
10. Click Next, and the system displays the Device Information window.
_____________________
_____________________ 46
11. Use the following information to configure the Device Information window:
Host Name: A-SMS

Domain Name: alpha.cp
Primary DNS Server: 192.168.11.101
Figure 22 — Device Information Configured
NOTE
Check Point prohibits the use of underscores in object names.
12. Click Next, and the system displays the Date and Time Settings window.
13. Select the option Use Network Time Protocol (NTP).
14. In the Primary NTP server field, type 192.168.11.101.
_____________________
_____________________ 47
15. Select the correct Time Zone for your location:
Figure 23 — Date and Time Settings Configured
16. Click Next, and the system displays the Installation Type window:
Figure 24 — Network Configuration - Host Name Options
_____________________
_____________________ 48
17. Select Security Gateway or Security Management, and click Next. The system displays the Products
window.
18. In the Products window, clear the Security Gateway option.
19. Use the information below to configure the Products window:
Products: Security Management

Advanced: Define Security Management as Primary
NOTE
Clear the Security Gateway option before continuing. This option must NOT be
selected.
20. Verify that the Products window is configured as follows:
Figure 25 — Products Configured
21. Click Next, and enter newadmin for the Administrator name.
_____________________
_____________________ 49
22. Enter and confirm Chkp!234 as the password:
Figure 26 — Security Management Administrator
23. Click Next, and confirm that the option Any IP Address is selected in the Security Management GUI
Clients window.
_____________________
_____________________ 50
24. Click Next, and the system displays the Summary page:
Figure 27 — Summary
25. Clear the following option:
Improve product experience by sending data to Check Point
NOTE
Though this option is recommended, it is not necessary in our lab. We are not in a
production environment and only have limited connection to the Internet.
26. Click Finish, and the system prompts you for a response to the following question:
Figure 28 — First Time Configuration Wizard Message
_____________________
_____________________ 51
27. Click Yes, and the system proceeds with the configuration:
Figure 29 — Summary (Progress)
28. Once complete, a message displays indicating that the configuration was successful:
Figure 30 — Message
_____________________
_____________________ 52
29. Click OK, and the Gaia Portal displays the configuration settings of the newly configured Security
Management Server:
Figure 31 — Check Point Gaia Portal - Security Management Server Configured
_____________________
_____________________ 53
30. In the System Management section, click Messages.

31. Enter the following for the Banner Message:
A-SMS
Unauthorized access of this server is prohibited and punishable by law.
Figure 32 — Messages Configured
32. Click Apply.
_____________________
_____________________ 54
33. In the User Management section of the navigation pane, select Users:
Figure 33 — Users
_____________________
_____________________ 55
34. Click the Add button, and the system displays the Add User window:
Figure 34 — Add User
_____________________
_____________________ 56
35. Use the following information to configure the new user:
Login Name: adminbash

Password: Chkp!234
Real Name: Adminbash
Home Directory: /home/adminbash
Shell: /bin/bash
Access Mechanisms: Web
Clish Access
Figure 35 — Add User Configured
NOTE
When you log into the Security Management Server as adminbash, the correct shell
is now available for adminbash to connect and transfer files. There is no longer a
need to specifically define the shell in the command line. Since this is an OS level
user, you must perform this action on every module you want to have the adminbash
user defined.
_____________________
_____________________ 57
36. Click OK, and the system adds the new user to the Users page:
Figure 36 — Users
_____________________
_____________________ 58
Installing SmartConsole
In this section, you will install SmartConsole on the A-GUI virtual machine.
1. In the navigation pane of Gaia Portal, click Overview.

2. On the Overview page, click the Download Now button to download the SmartConsole installer file:
Figure 37 — Web Portal - Overview
NOTE
You may need to reacquire the configuration lock before downloading the
application. The system will prompt you, if this is necessary.
_____________________
_____________________ 59
3. Save the installer file to the Downloads folder of A-GUI.

4. Log out of the Gaia Portal.
5. Browse the Downloads folder and locate the SmartConsole.exe file:
Figure 38 — Downloads Folder
_____________________
_____________________ 60
6. Double-click the SmartConsole.exe file. The Welcome screen displays.
7. Select the option confirming you agree to the Check Point End User License Agreement.
8. Click Install, to begin the installation process. The system displays installation progress information:
Figure 40 — Installation
_____________________
_____________________ 61
9. Verify that the system displays the Thank You window, once the installation completes:
10. Click the Finish button, to complete the SmartConsole installation.

11. Log into A-SMS with the following credentials:
Login: newadmin
Password: Chkp!234
_____________________
_____________________ 62
12. Click Login, and the system displays the Fingerprint for verification:
Figure 41 — Fingerprint
13. Click Proceed, and the system displays the Welcome to SmartConsole R80.10 page:
Figure 42 — Welcome to SmartConsole
_____________________
_____________________ 63
14. Close the What’s New window.

15. In the Gateways & Servers tab of SmartConsole, identify that there are no Security Gateways managed
by this Security Management Server:
Figure 43 — Gateways & Servers
_____________________
_____________________ 64
16. In the navigation pane, click Security Policies:
Figure 44 — Security Policies
17. Verify that no rules are present in the Rule Base and that only the A-SMS object is present, as is typical
in a default installation before the Security Policy is configured.
18. Close SmartConsole.
_____________________
_____________________ 65
Importing the Check Point Database

Use the migrate import command to load the objects, rules, and settings from the previous server into
the newly configured R80.10 one.
1. From A-GUI, use the following information to connect to the newly configured Security Management
Server via WinSCP:
Host Name: 10.1.1.101

User Name: adminbash
Password: Chkp!234
Figure 45 — WinSCP Login
NOTE
In Gaia, the User Name and Password are both case sensitive.
2. Click Login, and WinSCP logs into A-SMS.
_____________________
_____________________ 66
3. In the right-pane, navigate to the following location:
/var/log
4. In the toolbar, click New > Directory.
Figure 46 — Create Folder
NOTE
An alternative method to performing the import from the /var/log location would be
to move the migrate file into the upgrade_tools folder and perform the import from
that location.
5. Name the new folder Migrate.

6. Click OK.
7. In the left pane of WinSCP, verify that the following file is visible:
A-SMS-from-r7730-to-r8010.tgz
_____________________
_____________________ 67
8. In the right pane of WinSCP, verify that the Migrate folder is visible:
Figure 47 — WinSCP
_____________________
_____________________ 68
9. Copy the A-SMS-from-r7730-to-r8010.tgz file using Binary mode from its location on A-GUI
to the Migrate folder on A-SMS:
Figure 48 — Copy
NOTE
When transferring files, make sure you configure the transfer settings to work in
Binary mode.
10. Exit WinSCP, after the file transfer is complete.
_____________________
_____________________ 69
11. Once the file is copied to the server, log into A-SMS (10.1.1.101).
12. To enter Expert Mode, type the following and press Enter:
expert
NOTE
The system asks you to set the Expert Mode password because, as a new installation
this value is not currently configured.
13. Execute the following command to set the Expert Mode password:
set expert-password
14. Enter and confirm the following as the Expert Mode password:
Chkp!234
Figure 49 — set expert-password
15. Execute the following command:
save config
16. Next, type the following command and press Enter.
expert
17. Enter and confirm the following as the Expert password:
Chkp!234
18. Type the following command, and press Enter, to change the directory to the location of the imported
file:
cd /var/log/Migrate
_____________________
_____________________ 70
19. Execute an ls command to verify that the file is present:
Figure 50 — ls
20. Type the following command, and press Enter, to change the directory to the migration tool
application:
cd $FWDIR/bin/upgrade_tools
Figure 51 — Change Directories
21. Execute an ls command to verify that the file migrate function is present:
Figure 52 — ls
22. To import the file into the new Security Management Server, type the following command:
./migrate import /var/log/Migrate/A-SMS-from-r7730-to-r8010.tgz
23. Press Enter, and the system warns you that services must be stopped.
_____________________
_____________________ 71
24. Type y, and press Enter. The system unzips the file and imports the configuration. Once complete, it
displays the following question:
Figure 53 — Question
25. Press Enter, to restart Check Point services.

26. Wait for the services to start before proceeding to the next section.
_____________________
_____________________ 72
Launching SmartConsole and Reconfiguring

Existing Security Policies
Launch SmartConsole and connect to the Security Management Server.
1. From the Start menu on A-GUI, click All Programs > Check Point SmartConsole R80.10 and the 
system displays the login window.
2. Use the following information to configure the Login window:
User Name: newadmin

Password: Chkp!234
Figure 54 — Login Window
_____________________
_____________________ 73
3. Click the Login button, and the login attempt should fail:
Figure 55 — Check Point SmartConsole
NOTE
The login failure confirms that the database import completed successfully, because
newadmin was not configured in the imported policy.
4. Use the following information to Login:
User Name: admin

Password: Chkp!234
5. Click the Login button.

6. Select the Gateways & Servers tab.
_____________________
_____________________ 74
7. In the navigation pane, click Security Policies:
Figure 56 — Security Policies - Manage Policies - Recent Policies
_____________________
_____________________ 75
8. From the recent Policies list, click Alpha_Standard to view:
Figure 57 — Security Policies - Alpha Standard
9. Verify that the rules and objects previously configured on the old server are present.
10. Edit the Alpha-Net group object and add an “s” to it’s name.
_____________________
_____________________ 76
11. Edit the A-GW-Cluster object.

12. Verify that the Version setting on the General Properties page displays R80.10:
Figure 58 — General Properties Configured
NOTE
If the version displayed is not R80.10, click the Get button to retrieve this
information from the Security Gateways.
13. Click OK.
_____________________
_____________________ 77
14. Click Publish, to commit the changes to the database:
Figure 59 — SmartConsole
_____________________
_____________________ 78
15. Click the Install Policy button in the Alpha_Standard Policy Package and the system displays the
Install Policy window:
Figure 60 — Install Policy
NOTE
If the Threat Prevention option is selected, clear it before installing the 
Security Policy.
_____________________
_____________________ 79
16. As the policy installation is proceeding, identify the Recent Tasks pop-up window displayed by the
system in the bottom left of SmartConsole.
17. For the Policy Installation task, click the Details link. The system displays the following window:
Figure 61 — Install Policy Details
18. Confirm that the Alpha_Standard policy was successfully installed on both A-GW-Cluster members.
19. Close the Install Policy Details window.
20. Next, edit the B-GW object.
21. Test communication and only reset SIC if communication fails.
_____________________
_____________________ 80
22. In the General Properties page, verify that the B-GW displays a Version of R77.30:
23. Click OK.

24. In the toolbar, click the Application Menu button in the upper left corner of SmartConsole.
25. Select Global Properties.
_____________________
_____________________ 81
26. Verify that the following settings are defined:

◦ Accept ICMP First
◦ Log Implied Rules
Figure 63 — Global Properties
27. Click OK.

28. In the Alpha Security Policy, remove the B-GW object from the Stealth Rule, if it is present.
29. Next, publish and install the Alpha Security Policy.
_____________________
_____________________ 82
30. Click the + tab, to view the recent policies available to view:
Figure 64 — Recent Policies
_____________________
_____________________ 83
31. Select Bravo_Standard, and the system displays the following:
Figure 65 — Bravo_Standard Tab
_____________________
_____________________ 84
32. In the Bravo_Standard Security Policy page, click the Install Policy button:
33. Click Install, to install the Bravo_Standard Security Policy.
_____________________
_____________________ 85
34. Confirm that the Security Policy for Bravo installed successfully:
_____________________
_____________________ 86
35. In the navigation pane, select the Gateways & Servers tab.
36. Confirm that all Check Point modules show a status of OK:
Figure 68 — Gateway & Servers
_____________________
_____________________ 87
END OF LAB 1.1
_____________________
_____________________ 88
Hotfixes
Hotfixes are updates that are released to correct an issue discovered within the operating
system or software. They can be released to address security vulnerabilities and
inconsistencies or to provide enhancements and improvements. A Hotfix Accumulator (HFA)
is a collection of stability and quality fixes that resolve multiple issues in different products.
When installed, HFAs will overwrite the current hotfixes installed on the system. The name of
a hotfix identifies the version it is compatible with. For example, R80_JUMBO_HF_1_Bundle
_190 is a very large bundle of hotfixes for R80. In addition to hotfixes, some versions may
have new features which require the installation of an Add-on. Check Point recommends
installing the add-on only if the features enabled are required.
When providing a fix to customers, Check Point supplies the updated file and installation
package which will interactively install the fix. Gaia automatically provides a list of update
packages available for download that are relevant to the operating system version installed.
The Status and Actions page of CPUSE displays hotfixes that are available for download and
hotfixes that have previously been downloaded, imported, and installed.
Figure 69 — CPUSE
T h e C P U S E A ge n t
CPUSE is an advanced and intuitive tool used to update the Gaia operating system and Check
Point software products. It supports the deployment of major and minor software releases,
single hotfixes, and HFAs. A major release introduces new functionalities and technologies.
Examples of a major release would be R77 and R80. Minor releases include the latest fixes
released to customers. R77.30 is an example of a minor release.
_____________________
_____________________ 89
The CPUSE tool automatically locates and displays software update packages and full images
relevant to the Gaia operating system version installed on the computer. It also considers the
role of the computer (management server, gateway, or Gaia standalone) and other properties.
The CPUSE agent is installed on every Gaia-based machine and is responsible for all software
deployment on that machine. The machine must be connected to the Internet to obtain software
updates from the Check Point Cloud.
Prior to every installation, CPUSE runs several verification tests to ensure that the package is
compatible and can be installed on the machine without conflicts. To view available packages,
in the Gaia Portal navigate to the Upgrades (CPUSE) section and select Status and Actions. All
hotfix and minor version packages are displayed in categories and are filtered to show
recommended packages only by default.
Check Point recommends downloading the latest build of the CPUSE agent prior to applying a
hotfix. In most cases, the latest build is downloaded automatically. To check the current build
of the agent, click the Hotfixes link next to the CPUSE version number, near the top of the
Status and Actions page. A pop-up window will appear displaying hotfix information. The
installed build of the deployment agent is displayed at the bottom of the window. The current
build can also be checked by using Clish and running the following command:
HostName:0>show installer status build
Figure 70 — CPUSE > Status and Actions > Hotfixes Link
NOTE
The latest build of CPUSE is gradually released to all customers; therefore,
all machines may not receive the latest build at the same time.
Hotfixes can be scheduled to download automatically, manually, or periodically; however, full

installation and upgrade packages must be installed manually.
_____________________
_____________________ 90
Download and Install Hotfixes

Hotfixes are applied by first downloading or importing the CPUSE package and then installing
the package on the machine. In the Gaia Portal, click the lock icon to obtain the lock over the
configuration database before applying a hotfix and then navigate to the Status and Actions
page.
Every hotfix displayed as available for download may or may not be allowed or needed for
installation onto your machine. Check Point recommends verifying the package to determine if
it can be installed without conflicts. To verify a package, perform one of the following actions:
• Select the package and click the More button on the toolbar. From the list of options,
click Verifier. Or,
• Right-click the package and click Verifier.
The Verifier Results window will display, indicating whether or not installation is allowed. If
installation is allowed, proceed to download the package.
The download progress is displayed in the Status column of the hotfix. The download may be
paused at any time. When paused, the status of the package will change to Pausing Download
and then to Partially Downloaded and may be resumed at any time.
Install the package after it has been successfully downloaded. To install a downloaded
package, select the package and click the Install Update button, or right-click the package and
select Install Update. Hotfixes can also be downloaded and installed all at once, by simply
clicking the Install Update button.
Most Jumbo Hotfix packages and private hotfix packages are posted to the Check Point Cloud.
Click the Add Hotfixes from the cloud button to search, or enter a package identifier posted to
the cloud. Contact Check Point Support to get the package’s CPUSE Identifier, or copy and
paste the file name from the Check Point Download Center. Use the CPUSE Identifier search
string to add the relevant CPUSE package from the Check Point Cloud. Once the package is
added, its status will display as Available for Download.
To import a package, click the More button located on the toolbar of the Status and Actions
page, and select Import Package. In the Import Package window, browse to the package file,
and click Upload.
_____________________
_____________________ 91
CPUSE Software Updates Policy

The WebUI offers different methods for downloading hotfixes via CPUSE:
• Manually — This is the default method. Downloads can also be manually deployed in
Clish.
• Scheduled — The CPUSE agent can check for and download hotfixes at a specified
time, such as daily, weekly, monthly, or on a selected date.
• Automatic — The CPUSE agent will check for updates every three hours and
automatically download hotfixes as they become available.
The CPUSE agent can also send email notifications to administrators, which can inform them
of update events, such as when new packages are available for download and the success or
failure of a package installation. To define the CPUSE update policy and configure email
notifications, under the Upgrades (CPUSE) section, select Software Updates Policy.
Figure 71 — Software Updates Policy
Software update packages can be imported and installed offline if:
• the Gaia machine has no access to the Check Point Cloud.

• the desired CPUSE package is not available in the Check Point Cloud.
• the administrator prefers to manually import the CPUSE package.
_____________________
_____________________ 92
T h e C e n t r a l D e p l oym e n t To o l
System Administrators can automatically install CPUSE offline packages on multiple Security
Gateways and cluster members at the same time using the Central Deployment Tool (CDT).
The CDT is a utility that runs on Gaia operating system Security Management Servers and
Multi-Domain Servers using software versions R77.30 and higher. The tool communicates
with gateways and cluster members over SIC via TCP port 18209. Automatic installation on
multiple managed gateways and cluster members is supported for the following package types:
• Upgrades to R77.30
• Minor version upgrades
• Hotfixes
• Jumbo Hotfixes (bundles) or HFAs
Prior to using the CDT, all Security Gateways and cluster members must be already installed
and configured with SIC established and Security Policies installed. There are also several file
requirements that must be met before the utility can be run. This includes the CDT executable
and configuration files as well as several optional shell script files. The latest build of the
CPUSE agent is also required. CDT uses CPUSE agents to perform package installation on
remotely managed gateways and cluster members. The entire process is monitored and
managed by the CDT. To begin using the CDT, connect to the command line on the
management server, log into Expert mode, and then access the directory that contains the CDT
files.
Do not use CDT for clean installs of a major version. Also, CDT does not support upgrades or
installs of ClusterXL in Load Sharing mode. For more detailed information regarding the CDT
utility, refer to the Check Point Central Deployment Tool Administration Guide.
Lab 1.2
Applying Check Point Hotfixes
Lab 1.3
Configuring a New Security Gateway Cluster
_____________________
_____________________ 93
1.2
L
Applying Check Point Hotfixes A
B
In this lab, you will use the CPUSE utility to patch existing R80.10 gateways.
Ta sks :
• Install the hotfix on the Security Gateway.
• Perform an on-line jumbo hotfix application to the Security Gateway Cluster.
_____________________
_____________________ 94
Installing the Hotfix on the Security Gateways

Locate the hotfixes available for an R80.10 Security Gateway and perform an upgrade on both Alpha
Cluster members.
1. In SmartConsole, define a new Host object with the following information:
Name: A-GUI-NAT
Comment: NATed Alpha SmartConsole
Color: Orange
IP Address: 203.0.113.1
Figure 72 — New Host Configured
2. Click OK, and the system displays the following warning:
3. Click Yes.
_____________________
_____________________ 95
4. In the Bravo Security Policy, add the new Host to the Source field of the Management rule:
5. Publish the changes.
6. Install the Bravo Security Policy.
7. From A-GUI, use HTTPS to log into the Gaia Portal on B-GW (203.0.113.100) and confirm
connectivity:
_____________________
_____________________ 96
8. Next, use HTTPS to connect to the Gaia Portal of A-GW-01:
9. In the navigation pane, locate the Upgrades (CPUSE) section.
_____________________
_____________________ 97
10. In the navigation pane, select Status and Actions. The system displays the following page:
Figure 75 — Status and Actions
11. Identify the hotfix to apply.
NOTE
In this lab, apply the latest Jumbo Hotfix available for your Security Gateway,.
_____________________
_____________________ 98
12. Right-click the hotfix to apply:
Figure 76 — CPUSE Options
13. Select Install Update, and the system displays the following message:
Figure 77 — Package Install
_____________________
_____________________ 99
14. Click OK, and the system begins downloading and then installing the selected hotfix:
Figure 78 — CPUSE Download Progress
NOTE
When the system finishes the installation of the hotfix, it reboots automatically.
_____________________
_____________________ 100
15. After reboot, the system displays the Gaia Portal login page:
Figure 79 — Gaia Portal Login
16. Use the following information to log into the Gaia Portal:
Username: admin
Password: Chkp!234
_____________________
_____________________ 101
17. In the Upgrades (CPUSE) > Status and Actions page, confirm that the hotfix installed displays the
following status:
Installed, self-test passed...
Figure 80 — Upgrades (CPUSE) - Status and Actions
18. Next, repeat this section to upgrade A-GW-02 with the same hotfix you applied to A-GW-01.
END OF LAB 1.2
_____________________
_____________________ 102
1.3
L
Configuring a New Security A
Gateway Cluster B
Install and configure a second cluster member for Bravo. Convert the existing Bravo gateway to be a
cluster member and upgrade it to R80.10. Complete the configuration by defining a Bravo Cluster object in
SmartConsole.
Ta sks :
• Install a second Security Gateway at the Bravo site.
• Reconfigure the Primary Gateway for integration into the cluster.
• Define the Bravo Security Gateway Cluster.
• Upgrade the old Bravo Security Gateway from R77.30 to R80.10.
• Verify Bravo Gateway Cluster status of Active/Standby.
• Install the remote Security Gateway in a distributed environment and establish SIC.
• Configure a new Security Gateway cluster object and verify its status.
_____________________
_____________________ 103
Installing a Second Security Gateway

In this section you will install and configure the second Bravo Security Gateway, which will be managed
by the Alpha Security Management Server.
1. In VMware, verify that the following Virtual Machine (VM) has been created by your instructor:
• Name: B-GW-02
• OS: Other
• Version: Other
• Disk Space: 60GB
• Memory: 2GB
• Four interfaces
◦ eth0
• Do not power on
◦ eth1
• LAN 21
◦ eth2
• LAN 2
◦ eth3
• vmnet8
NOTE
Your classroom configuration may be different. Check with your instructor before
continuing to the next step.
2. Before powering on your VM, verify that it is configured as defined above.
_____________________
_____________________ 104
3. Power on the B-GW-02 virtual machine, and the Welcome to Check Point Gaia R80.10 screen appears:
Figure 81 — Welcome to Check Point Gaia R80.10
4. Highlight the following option:
Install Gaia on this system
5. Press the Enter key, to launch the installation.
_____________________
_____________________ 105
6. When the system is prepared for you to begin the operating system installation, it displays the
Welcome screen:
7. Tab to OK, and press Enter. The system displays the Keyboard Selection screen:
Figure 83 — Keyboard Selection
8. Select the keyboard type to suit your region.
_____________________
_____________________ 106
9. Tab to OK, and press Enter. The system displays the Partitions Configuration screen:
Figure 84 — Partitions Configuration
_____________________
_____________________ 107
10. Tab to OK, and press Enter. The system displays the Account Configuration screen:
Figure 85 — Account Configuration
NOTE
Again, at this step, you are configuring the password for the admin user, the default
OS level administrator.
11. Enter and confirm Chkp!234 as the admin account password.
NOTE
Verify that NumLock is on. It is not on by default after installation. If you haven’t
already turned it on, do so now and re-enter and confirm your password. If you enter
this password without turning NumLock on, you will not be able to log into the
system.
12. Tab to OK, and press Enter. The system displays the Management Port screen.
_____________________
_____________________ 108
13. Use the arrow keys to highlight eth3:
Figure 86 — Management Port
NOTE
In this classroom environment, all external interfaces are eth3. This Security
Gateway is remotely managed by the A-SMS, so the management interface must be
the external interface.
14. Tab to OK, and press Enter. The system displays the Management Interface screen.
_____________________
_____________________ 109
15. Use the following information to configure the Management Interface screen:
IP address: 203.0.113.103
Netmask: 255.255.255.0
Default gateway: 203.0.113.254
Figure 87 — Management Interface
_____________________
_____________________ 110
16. Tab to OK, and press Enter. The system displays the Confirmation screen:
Figure 88 — Confirmation
17. In the Confirmation screen, tab to OK, and press Enter.

18. After the drive is formatted and the installation is complete, the system displays the following screen:
Figure 89 — Installation Complete
_____________________
_____________________ 111
19. Press Enter, to reboot your system.

20. After reboot, the system displays the following prompt:
Figure 90 — Login Prompt
_____________________
_____________________ 112
Configuring the Bravo Security Gateway 

with the First Time Configuration Wizard
Follow these steps to configure the branch office Security Gateway and activate its default trial license.
NOTE
Your instructor will provide alternate directions if you use other licenses.
1. From the A-GUI Virtual Machine, launch an Internet browser, such as Firefox or Internet Explorer.
2. In the address field, type the following:
https://203.0.113.103
NOTE
Be sure that you are using HTTPS.
3. Press Enter, and your browser should warn you that the site’s Security Certificate is from an untrusted
source.
4. Ignore this warning and continue to the Login screen:
5. Log into B-GW-02 with the following credentials:
Username: admin
Password: Chkp!234
_____________________
_____________________ 113
6. Press Enter, and the system displays the following window:
Figure 91 — Gaia First Time Configuration Wizard
_____________________
_____________________ 114
7. Click Next, and the system displays the Deployment Options page:
Figure 92 — Deployment Options
Continue with Gaia R80.10 configuration
_____________________
_____________________ 115
9. Click Next, and the system displays the Management Connection page:
Figure 93 — Management Connection
10. Use the information below to verify that the Security Gateway’s network connection is configured
properly:
Interface: eth3
Configure IPv4: Manually
Configure IPv4: 203.0.113.103
Subnet Mask: 255.255.255.0
Default Gateway: 203.0.113.254
Configure IPv6: Off
_____________________
_____________________ 116
11. Click Next, and the system displays the Connection to UserCenter page:
Figure 94 — Connection to UserCenter
12. Click Next, and the system displays the Device Information page.
13. Use the following information to configure the Device Information page:
Host Name: B-GW-02

Domain Name: Leave Blank
_____________________
_____________________ 117
14. Click Next, and the system displays the Date and Time Settings page:
Figure 95 — Date and Time Settings
15. Verify that the time and date is correct for your area.
_____________________
_____________________ 118
16. Click Next, and the system displays the Installation Type page:
Figure 96 — Installation Type
_____________________
_____________________ 119
17. Select Security Gateway or Security Management, and click Next. The system displays the 
Products page.
18. On the Products page, uncheck the Security Management option.
19. Use the information below to configure the Products page:
Security Gateway: Selected

Security Management: Deselected
Unit is a part of cluster type: ClusterXL
Automatically download Blade Contracts and 
other important data (highly recommended): Selected
Figure 97 — Products
_____________________
_____________________ 120
20. Click Next, and the system displays the Secure Internal Communications (SIC) page:
Figure 98 — Secure Internal Communications (SIC)
21. Enter and confirm sic123 as the Activation Key.
_____________________
_____________________ 121
22. Click Next, and the system displays the Summary page:
Figure 99 — Summary
23. Click Finish, and the system asks you if you want to start the configuration:
Figure 100 — First Time Configuration Wizard
24. Click Yes.

25. Once the configuration process is complete, the system prompts you with a restart message:
Figure 101 — First Time Configuration Wizard
_____________________
_____________________ 122
26. Click OK, and the system displays the Login window after reboot:
1. Log into B-GW-02 with the following credentials:
Username: admin
Password: Chkp!234
2. Click the Log In button, and the Gaia Portal displays the configuration settings of the newly configured
Security Gateway.
_____________________
_____________________ 123
Using the Gaia Portal to Configure 

the Security Gateway
Define the interfaces and login message for the second Bravo gateway.
1. Review Gaia Portal’s Overview page:
Figure 103 — Overview
2. In the Navigation pane, identify the Network Management section.
_____________________
_____________________ 124
3. Click Network Interfaces, and the system displays the Network Interfaces page:
Figure 104 — Network Interfaces
NOTE
Notice how only eth3 is configured. This is your management interface. In this lab,
this also represents your external network.
_____________________
_____________________ 125
4. Select eth1, and click Edit. The system displays the Edit window:
Figure 105 — Edit eth1
5. Use the information below to configure eth1:
Enable: Checked
Comment: Internal
IPv4 Address: 192.168.21.3
Subnet Mask: 255.255.255.0
_____________________
_____________________ 126
6. Click OK, and the system saves the new eth1 configuration.
7. Double-click eth3, and the system displays a warning.

8. Click OK, and the system displays the Edit window.
Enable: Checked
Comment: External
IPv4 Address: 203.0.113.103
Subnet Mask: 255.255.255.0
_____________________
_____________________ 127
10. Verify that the newly configured eth3 appears as follows:
Figure 107 — Edit eth3
11. Click OK, to return to the Network Interfaces page.

12. Select eth2, and click Edit.
Enable: Checked
Comment: Sync
IPv4 Address: 192.168.20.3
Subnet Mask: 255.255.255.0
14. Click OK.
_____________________
_____________________ 128
15. Verify that your interfaces appear as follows:
16. In the Management Interface section of the page, notice that the current Management Interface is set 
to eth3.
_____________________
_____________________ 129
17. In the Navigation pane, under Network Management, click IPv4 Static Routes:
Figure 109 — Network Management - IPv4 Static Routes
18. Verify that the default gateway is 203.0.113.254.
_____________________
_____________________ 130
19. Click the Add Multiple Static Routes button.

20. Add the following Static routes:
10.1.1.0/24 203.0.113.1
192.168.11.0/24 203.0.113.1
192.168.12.0/24 203.0.113.1
Figure 110 — Add Multiple Routes
_____________________
_____________________ 131
21. Click Save, and the system adds the static routes:
Figure 111 — Network Management - IPv4 Static Routes Configured
_____________________
_____________________ 132
22. In the Navigation pane, under System Management, click Messages:
Figure 112 — System Management - Messages
_____________________
_____________________ 133
23. In the Banner Message field add the following text:
B-GW-02

Figure 113 — System Management - Messages
24. Click the Apply button.

25. From the toolbar, click Sign Out.
_____________________
_____________________ 134
Re-configuring the Primary Gateway

Reconfigure the primary Security Gateway at Bravo to function as part of a cluster.
1. From A-GUI, use HTTPS to connect to the Gaia Portal on B-GW (203.0.113.100):
Figure 114 — Gaia Portal - Overview
2. In the navigation pane, select Network Management > Hosts and DNS.
3. In the Hosts and DNS page, change the Host Name to the following:
B-GW-01
_____________________
_____________________ 135
4. Click Apply.
Figure 115 — Hosts and DNS Configured
5. In the navigation pane, select System Management > Messages.
_____________________
_____________________ 136
6. Modify the Banner Message to reflect the new name of this Security Gateway (B-GW-01):
7. Log out of the portal on B-GW-01.
_____________________
_____________________ 137
8. From the virtual system of the first Security Gateway (B-GW-01), run the cpconfig script:
Figure 117 — cpconfig
9. From the Configuration Options, review the available options.

10. If option six reads as follows, type 6 and press Enter:
6 Enable Cluster membership for this gateway
If option six displays the following, exit cpconfig and skip to step 13:
Disable Cluster membership for this gateway
11. Press Y to confirm that you want to enable the cluster membership:
Figure 118 — Cluster Membership Enabled
12. Reboot B-GW-01 to enable the changes.
_____________________
_____________________ 138
13. At A-GUI, open SmartConsole, and remove B-GW from all rules in all Rule Bases.
14. If configured, remove all references of B-GW from the IPSec VPN > MyIntranet > Participating
Gateways fields.
15. Disable the Stealth Rule.
16. In the toolbar, click the application Menu button.
17. Select Manage Policies and Layers, and the system displays the following:
Figure 119 — Manage Policies and Layers
18. Identify the policies that indicate B-GW as an Installation Target.
_____________________
_____________________ 139
19. Select the Bravo_Standard policy and click the Edit icon. The system displays the following:
Figure 120 — Policy - General
20. In the navigation pane, select installation Targets.
_____________________
_____________________ 140
21. Remove the B-GW object from the Specific Gateways list.
22. Select the following option:
All Gateways
Figure 121 — Policy - Installation Targets Configured
23. Click OK.
_____________________
_____________________ 141
24. Perform the above edits on all other policies that have B-GW as a Installation Target:
25. Click Close.

26. Edit the B-INT-NET object.
_____________________
_____________________ 142
27. In the NAT page, change the Install On Gateway setting to All:
Figure 123 — Network Configured
28. Edit all remaining objects that reference B-GW.

29. Publish the changes to the database.
30. Next, locate the B-GW object in the objects list.
31. Right-click B-GW and select Delete. The system displays the following window:
32. Click Yes.

_____________________
_____________________ 143
34. From the Clish prompt on B-GW-01, type the following, and press Enter:
set interface eth3 ipv4-address 203.0.113.102 mask-length 24
Figure 125 — set interface
35. Now, run the following command to reconfigure the internal interface:
36. Run the following command to reconfigure the sync interface:
37. At the prompt, type the following and press Enter:
save config
Figure 126 — Save Config
38. Run cpconfig to reset SIC, using sic123 for the activation key.
39. Exit cpconfig.
40. At the prompt, type the following, and press Enter.
exit
_____________________
_____________________ 144
41. After the services restart, use HTTPS to log back into the Gaia Portal on B-GW-01 (203.0.113.102):
42. Confirm that the newly configured IP addresses appear as follows:
Figure 127 — Re-configured B-GW-01 Interfaces
43. Enable the Sync interface, if it is not already enabled.
_____________________
_____________________ 145
Configuring the Alpha Security Policy to Manage

the Remote Security Gateway Cluster
Define the remote Security Gateway objects and incorporate it into the Alpha and Bravo Security Policies.
1. From SmartConsole on A-GUI, expand the Objects pane from the right sidebar.
2. In the Home page of the Objects pane, click New > More > Network Object > 
Gateways & Servers.
3. Select Gateway.
4. Use the information below to configure the new Security Gateway object:
Name: B-GW-01
Color: Firebrick
IPv4: 203.0.113.102
Comment: Bravo Security Gateway Cluster Member - One
Version: R77.30
_____________________
_____________________ 146
5. Verify that the new object appears as follows:
Figure 128 — Check Point Gateway - General Properties Configured
NOTE
Use the IP address of the management interface to define the cluster member
gateways. In the case of the Bravo cluster, that’s the external interface.
_____________________
_____________________ 147
6. Click OK, and the system displays a message indicating that no interfaces are defined.
NOTE
You will define the interfaces later, after establishing SIC. You are defining this
object here to make the Alpha cluster aware of the Bravo members. This will ensure
that A-GW-Cluster allows control connections to and from the Bravo gateways.
7. Click Yes, to clear the message.

Name: B-GW-02
Color: Firebrick
IPv4: 203.0.113.103
Comment: Bravo Security Gateway Cluster Member - Two
Version: R80.10
_____________________
_____________________ 148
9. Verify that the new object appears as follows:
10. Click OK.

11. Click Yes, to clear the message.
_____________________
_____________________ 149
12. Publish the changes to the database:
13. Install the Alpha Security Policy:
14. Next, edit the B-GW-01 object.

15. Click the Communication button.
_____________________
_____________________ 150
16. Enter and confirm the following One Time Password to establish SIC:
sic123
Figure 132 — Trusted Communication
_____________________
_____________________ 151
17. Click OK, and the system displays imported interface information:
Figure 133 — Get Topology Results
18. Click Close.

19. Click OK.
20. In the Bravo Rule Base, add B-GW-01 to the following rules:
◦ Management
◦ Stealth
_____________________
_____________________ 152
21. Install the Bravo Security Policy on B-GW-01:
22. From A-GUI, use HTTPS to connect to B-GW-01 (203.0.113.102):
23. Log into B-GW-01 as admin.
_____________________
_____________________ 153
24. In the Gaia Portal, navigate to Upgrades (CPUSE) > Status and Actions:
Figure 136 — Upgrade (CPUSE) - Status and Actions
NOTE
If the CPUSE page fails to populate with available packages after some time, it may
be updating the Deployment Agent. If this occurs, log out of the Gaia Portal and wait
about 60 seconds. Then, log back into the Gaia Portal as admin and attempt this step
again.
_____________________
_____________________ 154
25. In the Check Point Upgrade Service Engine (CPUSE) page, locate the Major Versions list of available
upgrade packages.
26. Select the following package:
R80.10 Fresh Install and Upgrade from R7X
27. Right click the package to install:
Figure 137 — Package Menu Options
_____________________
_____________________ 155
28. Select Download, and the system downloads the upgrade package to install:
Figure 138 — Upgrade Package Downloaded
_____________________
_____________________ 156
29. Right-click the downloaded package:
Figure 139 — Downloaded Package Menu Options
30. Select the Upgrade option, and the system displays the following message:
Figure 140 — Image Upgrade
31. Click OK, to begin the upgrade process.
_____________________
_____________________ 157
32. After the system reboots, log into B-GW-01 as admin:
33. Navigate to the Upgrades (CPUSE) - Status and Actions page and confirm that the upgrade completed
successfully:
Figure 142 — Upgrades (CPUSE) - Status and Actions
_____________________
_____________________ 158
34. From SmartConsole, select the Gateways & Servers tab.

35. Confirm that the B-GW-01 object has a status of OK.
NOTE
It is normal for the B-GW-01 object to still appears as a version R77.30 Security
Gateway in this view, at this time. This information will be updated with the correct
information after the server responds to a specific call for information.
36. Select the B-GW-01 object.
_____________________
_____________________ 159
37. In the Summary tab, click the Device & License Information link. The system displays the following
window:
Figure 144 — Device & License Information
38. Notice that the version now shows the correct information.
39. Close the Device & License Information window.
_____________________
_____________________ 160
40. Edit the B-GW-01 object, and the system displays the following message:
NOTE
If the B-GW-01 object does not show a version of R80.10, change it manually here.
41. Click OK, to clear the message.
_____________________
_____________________ 161
42. Confirm that the Platform Version now shows R80.10:
43. Click OK.

44. Next, establish SIC with B-GW-02, using sic123 as the one-time password.
46. Install the Alpha_Standard Security Policy.
_____________________
_____________________ 162
47. From the Home page of the Objects pane, click New > More > Network Object > 
Gateways & Servers:
Figure 147 — Objects Menu
48. Select Cluster, and the system displays the following window:
Figure 148 — Check Point Security Gateway Cluster Creation
_____________________
_____________________ 163
49. Select the following option and click Classic Mode:
Don’t show this again.
Name: B-GW-Cluster
IPv4 Address: 203.0.113.100
Comment: Bravo Security Gateway Cluster
Version: R80.10
Network Security: Firewall
Figure 149 — Check Point Gateway - General Properties
_____________________
_____________________ 164
51. Verify that the version selected for the Bravo Cluster object is defined as R80.10.
52. In the navigation pane, select Cluster Members:
Figure 150 — Gateway Cluster Properties - Cluster Members
53. In the Cluster Members page, click the Add button.
_____________________
_____________________ 165
54. Select Add Existing Gateway, and the system displays the following window:
Figure 151 — Add Gateway to Cluster
55. Select B-GW-01.

56. Click OK, and the system displays the following message:
_____________________
_____________________ 166
57. Click Yes, and the system adds the gateway to the Member Gateways list:
Figure 153 — Member Gateways - Gateway Added
_____________________
_____________________ 167
58. Next, add B-GW-02 to the Member Gateways list:
Figure 154 — Member Gateways - Gateways Added
59. Click OK.
_____________________
_____________________ 168
60. In the navigation pane, select Network Management:
Figure 155 — Network Management
_____________________
_____________________ 169
61. Click the Get Interfaces button, and the system retrieves and displays the interface information from
the cluster members:
Figure 156 — Network Management - Get Interfaces
_____________________
_____________________ 170
62. Double-click eth1, to edit the interface.

Name: eth1
Comment: Internal
Network Type: Cluster
Virtual IPv4: 192.168.21.1/24
Figure 157 — Network eth1
64. Confirm that the interface Topology settings are as follows:
Leads To: This Network (Internal)

Security Zone: None
Anti-Spoofing: Prevent and Log
_____________________
_____________________ 171

Name: eth2
Comment: Sync
Network Type: Sync
Virtual IPv4 Address: N/A
Leads To: This Network (Internal)

Security Zone: None
_____________________
_____________________ 172

Name: eth3
Comment: External
Network Type: Cluster
Virtual IPv4: 203.0.113.100/24
Leads To: Internet (External)

Security Zone: None
_____________________
_____________________ 173
71. Confirm that the interfaces are configured as follows:
Figure 160 — Network Management Configured
_____________________
_____________________ 174
72. Click OK, and verify that the new B-GW-Cluster object appears in the Gateways and Servers section
of the Objects pane:
Figure 161 — Security Policies - Access Control
73. Select the Bravo Security Policy.
_____________________
_____________________ 175
74. Remove all Security Gateway objects from the Stealth and Management rules in the Bravo Security
Policy:
Figure 162 — Security Gateway Removed from Stealth and Management Rules
75. Add the B-GW-Cluster to the Destination column of the Stealth and Management rules:
Figure 163 — Stealth Rule Modified
NOTE
If the Stealth Rule is disabled here, enable it before continuing to the next step.
_____________________
_____________________ 176
76. From the Application Menu, select Manage Policies and Layers. The system displays the following
window:
_____________________
_____________________ 177
77. Select the Bravo_Standard policy.

78. Click the Edit button, and the system displays the Policy window:
Figure 165 — Policy
_____________________
_____________________ 178
79. In the navigation pane, select Installation Targets.

Specific Gateways
81. Add B-GW-Cluster to the Specific Gateways list:
Figure 166 — Policy Configured
82. Click OK.

83. Click Close.
_____________________
_____________________ 179

86. Verify that only the B-GW-Cluster (203.0.113.100) is listed as a policy target.
87. Click the Install button.
88. From the B-Host virtual machine, launch a web browser.
89. Use HTTP to connect to A-DMZ (192.168.12.101).
90. In SmartConsole, select Logs & Monitor from the Navigation bar:
Figure 167 — Logs & Monitor - Logs
_____________________
_____________________ 180
91. View the log showing the accepted HTTP traffic from B-Host to A-DMZ:
Figure 168 — Log Details
92. Close the log file.
_____________________
_____________________ 181
END OF LAB 1.3
_____________________
_____________________ 182
CLI Commands
Check Point Gaia’s powerful CLI commands and Clish shell are designed for users who prefer
to interact with the system by executing commands or scripts.The most common operations
are:
• add
• set
• show
• save
• delete
CLI commands can be entered in two modes; Standard mode and Expert mode.
Standard mode is the default Check Point shell (Clish) and provide commands for easy
configuration and routine administration such as cpstart and cpstop. However, most
system commands are not supported. The prompt for standard mode commands is:
[hostname]>
Expert mode allows advanced Check Point system and underlying Linux functions access to
the Gaia operating system. To enter Expert mode, use the <expert> command in Clish. This
command opens the Bash shell. The prompt for Expert mode is: [Expert@hostname]#
An Expert mode user can run Linux commands such as ls, cd and pwd as they would on any
Linux system to directly manipulate the Gaia operating system file system. Basic Check Point
commands such as fw ver and cpconfig can also be run from the Expert mode CLI,
similar to Gaia Clish.
CLI-inclined users can also use CLI commands and tools in Export mode to create automation
scripts. These tools include:
• dbedit — creates and configures objects and rules in the database for the Security
Policy.
• fwm load — installs the specified Security Policy on Security Gateways.
• send_command — runs functions which are not included with standard Check Point
CLI commands and tools.
CLI commands and multiple shells are available for all Check Point Gaia-based operating
systems, software blades and features. Several useful commands are noted in this section,
however many other commands are discussed in greater detail throughout this course.
_____________________
_____________________ 183
Environment Commands
Use these commands to set the CLI environment for a user. The syntax to set the client
environment is: set clienv <parameter>
To save the client environment permanently:
save client
To acquire the configuration lock from another administrator:
lock database override
To set inactivity timeout when working with CLI:
set inactivity-timeout <value>
With this command, <value> is the timeout in minutes.
Parameter Description
config-lock [on|off] Default value of the Clish configuration lock parameter.
If set to on, Clish will lock the configuration and no
configuration changes can be made in the WebUI.
debug [0 - 6] Debug level. Zero is the default level; do not debug,
display error messages only. Level 6 will show handler
invocation parameters and results.
echo-cmd [on|off] When set to on, echoes all commands before executing
them. The default is off.
on-failure [continue| When the system encounters an error, commands from a
stop] file or script will either continue to run or stop running.
The default is stop.
output [pretty Determines the command line output format. The
|structured|xml] default is pretty.
prompt <value> Command prompt string. Defines the appearance of the
command prompt. Can consist of any printable
characters and a combination of variables.
rows <integer> Number of rows to display in the terminal window.
syntax-check [on|off] When set to on, puts the shell into syntax-check mode.
Commands are checked syntactically and are not
executed, but values are validated. The default is off.
Table 3: Environment Command Parameters
_____________________
_____________________ 184
System Configuration Commands

Gaia system configuration settings can be saved as a ready-to-run CLI script.
To save the system configuration to a CLI script:
save configuration <scriptname>
To restore configuration settings:
load configuration <scriptname>
To see the latest configuration settings:
show configuration
This example shows part of the configuration settings as last saved to a CLI script:
mem103> show configuration

#
# Configuration of mem103
# Language version: 10.0v1
#
Exported by admin on Mon Mar 19 15:06:22 2016
#
set hostname mem103
set timezone London / Europe
set password-controls min-password-length 6
set password-controls complexity 2
set password-controls palindrome-check true
set password-controls history-checking true
set password-controls history-length 10
set password-controls password-expiration never
set ntp active off
set router-id 6.6.6.103
set IPv6-state off
set snmp agent off
set snmp agent-version any
set snmp community public read-only
set snmp traps trap authorizationError disable
set snmp traps trap coldStart disable
set snmp traps trap configurationChange disable
_____________________
_____________________ 185
System Management Commands

There are a multitude of system management tasks that can be performed and configured using
CLI, such as managing users, synchronizing system clocks, configuring SNMP, banner
messages, core dumps, and more. Examples of several of these tasks are noted below.
To add a user account:
add user <username> uid 200 homedir /home/<username>
To modify user accounts:
set user <username>
To set a user password:
set user <username> password
To show the current system date and time:
show clock
To display the current system day, date, and time:
Thu Aug 25 15:25:00 2016 CST
A Banner message can be configured to show users when they log in. To set a banner message:
set message banner <on | off> msgvalue <banner>
Example of a banner message:
set message banner on msgvalue “This system is private and

confidential”
To enable SNMP:
set snmp agent on
To enable or disable core dumps:
set core-dump [enable|disable]
To enable or disable IPv6 support:
set IPv6-state [on|off]

show IPv6-state
_____________________
_____________________ 186
Network Administration Commands

The syntax to configure physical interfaces is:
set interface <IF>

IPv4-address <IP>
mask-length <Mask>
subnet-mask <Mask>
IPv6-address <IF> mask-length <Mask>
IPv6-autoconfig [on |off]
comments <Text>
mac-addr <MAC>
mtu <MTU setting>
state [on | off]
link-speed <Speed_Duplex>
auto-negotiation [on | off]
interface <IF> Configures a physical or virtual interface with an Interface
name.
IPv4-address <IP> Assigns the IPv4 or IPv6 address.
IPv6-address <IP>
IPv6-autoconfig  If on, automatically gets the IPv6 address from the DHCP.
[on|off]
mask-length <Mask> Configures IPv4 or IPv6 subnet mask length using CIDR (/xx)
notation.
subnet-mask <Mask> Configures IPv4 subnet mask using dotted decimal notation.
comments <Text> Adds free text comments to an interface definition.
mac-addr <MAC> Configures the interface hardware MAC address.
mtu <MTU setting> Configures the Maximum Transmission Unit (MTU) size for
an interface with an integer greater than or equal to 68. The
default is 1500.
state [on|off] Sets interfaces status to enabled or disabled.
link-speed Configures the interface link speed in Mbps and duplex status
<Speed_Duplex> values, such as 10M/half or 10M/full.
auto-negotiation Configures automatic negotiation of interface link speed and
[on|off] duplex settings to enabled or disabled.
Table 4: Network Administration Command Parameters
_____________________
_____________________ 187
Examples:
set interface eth2 IPv4-address 40.40.40.1 subnet-mask

255.255.255.0
set interface eth2 mtu 1500
set interface eth2 state on
set interface eth2 link-speed 1000M/full
To delete an interface setting:
delete interface eth2 IPv4-address
Gaia automatically identifies physical interfaces, such as NICs, installed on a computer.

Therefore, they cannot be added or deleted using the WebUI or the CLI.
Gaia devices can also be configured to be a Dynamic Host Configuration Protocol (DHCP)
server. DHCP servers allocate IP addresses and other network parameters to network hosts,
thus eliminating the necessity of configuring each host manually. DHCP server subnets can be
configured on the Gaia device interfaces to allocate network parameters, such as IPv4
addresses and DNS parameters, to hosts behind the Gaia interface. Use DHCP commands to
configure the Gaia device as a DHCP server for network hosts.
To create DHCP server subnets:
add dhcp server <parameter> <value>

netmask <value>
include-ip-pool start <value> end <value>
exclude-ip-pool start <value> end <value>
_____________________
_____________________ 188
To change DHCP server subnet configurations:
set dhcp server subnet <value>
subnet <value> The IPv4 address of the DHCP subnet on an
Ethernet interface of the Gaia device. Hosts behind
the Gaia interface get IPv4 addresses from address
pools in the subnet. For example, 192.168.1.0/24
netmask <value> The IPv4 subnet mask in CIDR notation. For
example, /24
start <value> The IPv4 address that starts or ends the allocated IP
pool range.
end <value>
include-ip-pool <value> The range of IPv4 addresses to include in the IP
pool. For example 192.0.2.20-192.0.2.90
exclude-ip-pool <value> The range of IPv4 addresses to exclude from the IP
pool.
enable Enable or disable the DHCP server subnet, or the
DHCP server process (depending on the context).
disable
default-gateway <value> The IPv4 address of the default gateway for the
network hosts.
domain <value> The domain name of the network hosts. For
example, testdomain.com.
dns <value> The Domain Name Service (DNS) servers that the
network hosts will use to resolve host names.
Optionally, specify a primary, secondary and
tertiary server in the order of precedence.
all All DHCP server configuration settings.
subnet DHCP server subnet configuration settings.
subnet <value> ip-pools The IP pools in the DHCP server subnet, and their
status: enabled or disabled.
status [enabled|disabled] The status of the DHCP server process: enabled or
disabled.
Table 5: DHCP Command Parameters
_____________________
_____________________ 189
Gaia uses the Domain Name Service (DNS) to translate host names in to IP addresses. To
enable DNS lookups, the primary DNS server must be entered for your system. The system
will consult the primary DNS server to resolve host names. A DNS suffix, which is a search for
host-name lookup, can also be defined.
To configure the DNS server:
set dns primary <value>
To configure the DNS suffix:
set dns suffix <value>
The value parameter for both examples is an IPv4 or IPv6 address.
Additional CLI Commands

There are many more CLI commands available, such as commands which allow you to define
static routes and configure system logging. To view a list of all possible CLI commands, log
into Clish and press the Esc tab on your keyboard twice. For operation specific commands,
press the tab key twice.
_____________________
_____________________ 190
CPInfo
CPInfo is a Check Point utility that collects diagnostic data on a machine at the time of
execution. The CPInfo output file allows Check Point’s support engineers to analyze customer
setups remotely. The support engineer opens the CPInfo file in demo mode, while viewing
actual customer Security Policies and objects. This process allows for a more in-depth analysis
of all of the customer’s configuration options and environment settings. CPInfo collects the
entire gateway installation directory, including $FWDIR/log/* files. Some of the other
viewable information includes routing tables, system message logs, and the output of various
command, such as ifconfig and fw ctl pstat commands. CPInfo files are sent to
Check Point Technical Support via email or FTP.
To use CPInfo, make sure that the platform’s current version of cpinfo is installed to extract
the CPInfo file. Run the cpinfo command with the relevant flags in Clish or in Expert mode:
• -l — This flag is to include log records in the output file. Including log records will
yield a very large output.
• -z — This flag instructs the utility to gzip (compress) the output.
• -v — This flag prints version information.
• -n — This flag tells the utility to not collect and create a CPInfo file. It should be used
with -f.
• -f <file> — This flag uploads additional files to the Check Point server. It should
be used in combination with -n and -i. If the file to be uploaded is not compressed,
CPInfo will first compress it and then upload it.
• -o <filename> — This flag directs the output to a file and to the screen. It also
specifies a file name.
• -y — This flag instructs the utility to display all installed hotfixes.
• -k — This flag includes Firewall tables in the output.
• -i — This flag is for non-interactive mode.
• -d — This flag instructs the utility not to check for updates.
• -a — This flag forces the update check. By default, the update check of CPInfo utility
is once a week.
• -u — This flag connects to the User Center with username and password.
• -e <e-mail> — Specifies a single email or multiple emails of people that should be
notified about upload status. Multiple emails must be enclosed in double-quotations
and separated by semi-colons. For example: “<email #1>;<email #2>”
• -s <SR_Number> — Specifies the Service Request number opened with Check
Point Support. For example, -s 28-123456789
• -T <timeout> — Specifies the timeout in seconds for the commands executed by
the utility. This does not apply to collection of the CPInfo output file itself. The default
timeout is 600 seconds (5 minutes).
• -h — The flags displays the built-in help.
_____________________
_____________________ 191
Lab 1.4
Core CLI Elements of Firewall Administration
_____________________
_____________________ 192
1.4
L
Core CLI Elements  A
of Firewall Administration B
Use a selection of common commands and tools to manage the firewall and monitor and capture traffic
logs for troubleshooting purposes.
Ta sks :
• Install the Security Policy and verify status with fw stat.
• Uninstall the Policy and verify status with fw stat.
• Run cpinfo on a Security Gateway.
• Find information from cpinfo output.
• Open cpinfo from InfoView.
• Run the fw ctl pstat command.
• Run basic fw monitor and tcpdump commands on a Security Gateway.
• Perform basic tasks related to Security Policy management from the Command Line Interface.
• Use common commands to evaluate the condition of a Security Gateway.
_____________________
_____________________ 193
Managing Policy and Verifying Status 

from the CLI
Policy status for a Gateway is regularly verified in SmartConsole. The fw stat command is also useful to
verify Policy status. In circumstances where you cannot log in to SmartConsole, fw unloadlocal can be
used to uninstall the Policy.
1. From the A-GW-01 virtual machine, run the following command:
fw stat
Figure 169 — fwstat
2. Run fw unloadlocal from the command line:
Figure 170 — fw unloadlocal
NOTE
Only run the fw unloadlocal command when absolutely necessary. Now that the
Security Policy is no longer installed, all interfaces are currently open and passing
traffic without inspection.
_____________________
_____________________ 194
3. Verify that the policy was removed by executing the fw stat command again:
Figure 171 — fw stat
4. Run fw fetch 10.1.1.101 from the command line:
Figure 172 — fw fetch localhost
NOTE
Ignore any error messages for services that have not started.
5. Run the fw stat command to verify that the Security Gateway was able to fetch the policy from the
Security Management Server:
Figure 173 — fw stat
6. Type the following command and press Enter:
exit
_____________________
_____________________ 195
Using cpinfo
In this section, you will view a list of hotfixes applied to the Security Gateway and collect server
configuration files.
1. From A-GUI, use Putty to log into A-GW-01 (10.1.1.2). Once logged in, enter Expert mode.
2. At the Expert mode prompt for A-GW-01, run the following command:
cpinfo -y all
Figure 174 — cpinfo -y all
3. Review all hotfixes applied to the Security Gateway.
_____________________
_____________________ 196
4. Next, run the following command:
cpinfo -l -o A-GW-01-cpinfo.txt
NOTE
In the command above (cpinfo -l), that is a lower case L, not a number 1.
5. Press Enter, and the system asks if you for an SR number.
Figure 175 — cpinfo -l -o
NOTE
You may not be prompted for an SR number. If not prompted, continue with the next
step by typing n and pressing Enter.
_____________________
_____________________ 197
6. Type s, and press Enter. The file collection runs for about a minute. As cpinfo runs, status messages
will display:
Figure 176 — cpinfo -l -z
7. Once cpinfo has finished, the output file A-GW-01-cpinfo.txt will be created in the following
default directory for the administrator:
/home/admin
_____________________
_____________________ 198
8. From A-GUI, use HTTPS to connect to A-GW-01 (10.1.1.2).
9. Use the following credentials to log into the Gaia Portal:
Username: admin
Password: Chkp!234
_____________________
_____________________ 199
10. In the navigation pane, select User Management > Users:
Figure 178 — Users
_____________________
_____________________ 200
11. In the Users page, click the Add button.
NOTE
If necessary, gain control of the configuration by clicking the Lock in the 
Gaia Portal toolbar.
12. Using the information below, configure a new user:
Login Name: gaiaAdmin

Password: Chkp!234
Real Name: Gaiaadmin
Home Directory: /home/gaiaAdmin
Shell: /bin/bash
Access Mechanisms: Web
Clish Access
Figure 179 — Add User Configured
_____________________
_____________________ 201
13. Click OK, and the system adds the new user to the Users list:
14. Log out of the Gaia Portal.
_____________________
_____________________ 202
15. From A-GUI, use the following credentials to start a WinSCP session to A-GW-01:
Host Name: 10.1.1.2

User name: gaiaAdmin
Password: Chkp!234
Figure 181 — Login - WinSCP
_____________________
_____________________ 203
16. Navigate to and locate the compressed A-GW-01-cpinfo.txt.info.gz file (/home/admin):
Figure 182 — WinSCP Session
17. Transfer the file to A-GUI.
NOTE
If using FTP from the Security Gateway to a FTP server, make sure to use 
Binary mode.
_____________________
_____________________ 204
18. Navigate to the directory to which you transferred the text file, and open it in WordPad:
Figure 183 — CPINFO File
_____________________
_____________________ 205
19. Scroll down to view the CP Status section of the file.

20. Using the Edit menu’s Find option, identify the following:
◦ FireWall-1 Version Information
◦ Version
◦ CP License
Figure 184 — Find
21. Exit WordPad.
_____________________
_____________________ 206
Reconfiguring the Security Policies

Modify both Security Policies to allow FTP traffic between the sites.
1. In the Bravo_Standard policy, add a new rule above the Cleanup rule.
2. Use the information below to configure the new rule:
Name: Incoming
Source: Any
Destination: B-INT-NET
Services & 
Applications: FTP
Action: Accept
Track: Log
Figure 185 — Incoming Rule
1. In the Alpha_Standard policy, add a new rule above the LDAP rule.
_____________________
_____________________ 207
2. Use the information below to configure the new rule:
Name: FTP
Source: Any
Destination: Alpha-Nets
Services & 
Applications: FTP
Action: Accept
Track: Log
Figure 186 — FTP Rule

5. Install the Alpha Security Policy.
_____________________
_____________________ 208
6. From A-GUI, log into the Gaia Portal on A-GW-01.

7. Define a new user called scpAdmin with the adminRole and scponly shell access:
Figure 187 — Add User
_____________________
_____________________ 209
8. Click OK, to add the user to the Users list:
9. Log out of Gaia Portal.
_____________________
_____________________ 210
Using fw monitor
In this section you will test fw monitor. It’s important to remember that in a production environment where
a Security Gateway is already under heavy load, the fw monitor command can dramatically affect
performance because we have to turn off acceleration. It is always best to test packet captures during off-
peak times.
1. Execute the following command to verify that A-GW-01 is the Active gateway:
cphaprob stat
NOTE
In Expert Mode on A-GW-02, if it is the Active gateway, execute the following
commands to force A-GW-01 to become active:
clusterXL_admin down
clusterXL_admin up
2. In Expert Mode on A-GW-01, navigate to the following directory:
cd /var/log/tmp
NOTE
Check Point recommends that you run the fw monitor command from a directory
with plenty of space, such as /var/log, so that you do not fill up the hard drive.
_____________________
_____________________ 211
3. At the prompt, type the following, and press Enter:
fwaccel off
Figure 189 — fwaccel off
NOTE
This command turns off SecureXL acceleration and ensures a complete capture in
the next step.
4. Type the following at the prompt to start fw monitor:
fw monitor -o monitorfile.pcap
Figure 190 — fw monitor
5. Generate FTP traffic from B-Host (192.168.21.201) to A-GUI (10.1.1.201).
_____________________
_____________________ 212
6. From A-GW-01, type CTRL + C to end monitoring.

7. Use WinSCP to transfer the monitorfile.pcap to A-GUI from A-GW-01.
Figure 191 — monitorfile.pcap Transferred
_____________________
_____________________ 213
8. On A-GUI, double-click the transferred pcap file to review the created output in Wireshark:
Figure 192 — monitorfile.pcap in Wireshark
_____________________
_____________________ 214
9. Locate the FTP traffic from 192.168.21.201 to 10.1.1.201:
Figure 193 — FTP Traffic Identified
NOTE
To identify the FTP traffic in WireShark, use the following filter:
tcp.port==21
_____________________
_____________________ 215
10. Log in to A-GW-01, and type the following in Expert mode:
fw monitor -e "accept src=203.0.113.100 or dst=10.1.1.201 and dport=21;" 

-ci 20 -o monitorfile2.pcap
NOTE
This monitors traffic to and from specific addresses and only captures twenty 
inbound events.
11. Generate FTP Traffic from:

◦ A-GUI to B-Host
◦ B-Host to A-GUI
12. From A-GW-01, type CTRL + C to end monitoring.
NOTE
When you return to A-GW-01, the fw monitor may have already ended. This
happens when it reaches the specified number of records collected, which, in this
case, is 20.
13. From A-GUI, use WinSCP to transfer the monitorfile2.pcap off the Security Gateway.
_____________________
_____________________ 216
14. Review the created output file to see that only the FTP traffic to and from 192.168.21.201 is shown:
Figure 194 — monitorfile2.pcap in WireShark
_____________________
_____________________ 217
Using tcpdump
Use tcpdump to retrieve Layer 2 information from the Security Gateway.
1. From A-GW-01, run the following command in expert mode:
tcpdump -i eth0 icmp -w dumpfile.pcap
2. Generate ICMP traffic from A-GUI to the B-Host virtual machine.

3. On A-GW-01, type CTRL + C to end monitoring:
Figure 195 — Ending tcpdump
_____________________
_____________________ 218
4. Use WinSCP to transfer the newly created tcpdump file to A-GUI.

5. Use WireShark to view the contents of the tcpdump file.
6. From A-GW-01, type the following, and press Enter:
fwaccel on
END OF LAB 1.4
_____________________
_____________________ 219
Advanced Firewall
The Check Point Firewall Software Blade builds on the award-winning technology first
offered in Check Point’s Firewall solution and provides the industry’s best cyber security.
Having demonstrated industry leadership and continued innovation since the introduction of
the Firewall-1 in 1994, Check Point Firewalls are trusted by 100% of the Fortune 100
companies.
C h e c k Poi n t F i r ewal l I n f r a s t r u c t u r e
As a security expert considering the needs of your organization, in-depth knowledge of
Security Gateways must be applied as you implement them beyond a simple distributed
deployment. To establish a framework for assessing gateway performance in a complex
network topology, you must understand the infrastructure.
You should recall from the CCSA that fundamentally, Check Point security components are
divided into the following components:
• GUI Client
• Security Management
• Security Gateway
GUI Client
GUI applications, for object manipulation, log viewing and reporting, such as SmartView
Monitor and SmartEvent, are all unified into one console (SmartConsole). These GUI
applications offer you the ability to configure, manage and monitor security solutions, perform
maintenance tasks, generate reports and enforce corporate policy in real-time.
Check Point periodically releases new executables that include updates for SmartConsole
applications. These updates are not always related to or aligned with Security Gateway
hotfixes and are considered a separate, unrelated release track.
Security Management
The management component is responsible for all management operations in the system. It
contains several elements, such as the management server, reporting suite, log server, etc. All
of the functionality of the Management server is implemented in User-Mode processes, where
each process is responsible for several operations.
_____________________
_____________________ 220
Check Point Management (cpm) is the main management process. It provides the architecture
for a unified security environment. CPM allows the GUI client and management server to
communicate via web services using TCP port 19009. It empowers the migration from legacy
Client-side logic to Server-side logic. The cpm process performs database tasks, such as
creating, deleting, and modifying objects, and compiling policy. Processes controlled by CPM
include:
• web_services — Transfers requests to the dle_server.

• dle_server — Contains all the logic of the server and validates information before it is
written into the database.
• object_store — Translates and writes data to the database.
CPM saves all data in the Postgres SQL database and stores most of the data in Solr, a
standalone search server powered by the Lucene Java search library. The Postgres SQL
database contains objects, policies, users, administrators, licenses, and management data.The
data is segmented into multiple database domains. Solr generates indexes of the data to be used
for full text searching capabilities.
Figure 196 — CPM Architecture
_____________________
_____________________ 221
Additional significant management processes include:
• fwm — Firewall Management (fwm) is on all management products, including Multi-

Domain Security Management, and on products that require direct GUI access, such as
SmartEvent. The fwm process is used mainly for backward compatibility of gateways.
It provides GUI client communication, database manipulation, policy compilation, and
Management High Availability synchronization.
• fwd — Check Point Firewall Daemon (fwd) allows other processes, including the
kernel, to forward logs to external Log servers, as well as the Security Management
Server. It communicates with the kernel using command line tools, such as the fw
commands, kernel variables, and kernel control commands.
• fwssd — A child process of fwd. It is responsible for managing Firewall Security
Servers which provide a higher level of protocol enforcement.
• cpd — Check Point Daemon (cpd) is a core process on every Check Point product. It
allows Secure Internal Communication (SIC) functionality, pulls application
monitoring status, transfers messages between Firewall processes, fetches and installs
policy, and more.
• cpwd — Check Point WatchDog (cpwd) invokes 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 cpwd are cpd, fwd, and fwm. The cpwd_admin
utility shows the status of processes and configures cpwd.
_____________________
_____________________ 222
Security Gateway
The Security Gateway, sometimes referred to simply as the Firewall, is the component in the
system responsible for security enforcement, encryption/decryption, authentication, and
accounting.
The functionality of the Security Gateway is implemented both in User-Mode and in the
kernel. The Security Gateway is a network device running an operating system which makes it
vulnerable to possible Network layer attacks. To mitigate this vulnerability, some of the
Firewall functionality is implemented in the kernel mode. This allows the traffic to be
inspected before even getting to the operating system IP stack.
Figure 197 — Operating System Kernel
The Firewa ll Kernel

The Firewall kernel is responsible for the majority of the Security Gateway’s operations, such
as security enforcement, encryption/decryption, NAT, etc. In order to detect which part of the
kernel might be responsible for a specific issue, start by considering the inner structure of the
Firewall kernel and its interaction with the operating system kernel (Gaia), the hardware, and
other kernel components, such as acceleration. There are certain processes that operate at the
operating system level in the User Mode space and others that operate in kernel mode space.
_____________________
_____________________ 223
User and Kernel Mode Processes

The Kernel Mode resides in the Data Link layer of the OSI model. The Firewall kernel inspects
packets between the Data Link layer and the Network layer. Every packet that goes through the
Firewall is inspected. In the Network layers, you would not see all those packets.
User Mode is not mandatory, however, it allows the Firewall to function more efficiently in the
Application layer. The Firewall employs services of the operating system and allows easier
inspection of files on open connections.
It is possible and, in some cases, required for user and kernel processes to communicate. To
allow this, there are two mechanisms: Input/Output Controls (IOctl) and traps. When a Kernel
process wishes to signal to a User Mode process, it sets a trap by changing a value in a registry
key. The User Mode process monitoring that flag stumbles on the trap and performs the
requested operation. When a User Mode entity needs to write information to a kernel process,
it uses IOctl, which is an infrastructure allowing the entity to call a function in the kernel and
supply the required parameters.
Figure 198 — Processes
As administrators trying to debug the Firewall, the first observation to make is to decide which
Firewall functionality is implemented in the user space and which is implemented in the
kernel. Once that distinction is made, decide the best approach to use in addressing the
problem, including which tool is the most appropriate to use.
_____________________
_____________________ 224
Pa c ket F l ow
To understand how packets are inspected, consider the Firewall kernel more closely.
Inbound and Outbound Packet Flow

Traffic first arrives into the Firewall through one of the Firewall Network Interface Cards
(NICs). The Check Point Firewall kernel is installed on each Firewall NIC that is enabled in
the operating system. The Firewall kernel consists of two completely separate, logical parts
called the Inbound and Outbound, which represents the process of packets coming in and out
of the Firewall. These processes work on each packet through another process called
inspection. Each part acts independently and does not assume that a packet was inspected or
processed by the other. Therefore, some functionality is implemented both on the Inbound and
on the Outbound. Some key points include:
• Each direction has its own ordered chain of modules, or packet processing handlers.
• Handlers decide whether to continue, terminate or hold the processing of a packet.
• Inspection is performed on virtually defragmented packets.
The inspection process does expect that a packet in the Outbound that has not entered the
Inbound first originated from the Security Gateway itself. It also assumed that a packet not
originating from the gateway was Inbound.
Figure 199 — Check Point Firewall Kernel Inspection Points
_____________________
_____________________ 225
Packet Inspection Flow

The following diagram describes a packet flow through the Firewall kernel and how the User
Mode processes work to control the traffic.
Figure 200 — Packet Inspection Flow
1. The packet arrives at the Security Gateway and is intercepted by the NIC on the Inbound.
2. The Firewall kernel Inbound chain begins inspecting the packet.
3. The packet is matched against the Rule Base. A log is generated and sent from the kernel
to the User Mode process, fwd, located in the Security Gateway.
4. The fwd process on the Security Gateway sends the log to the fwd process on the Man-
agement server, where it is forwarded to cpm via cpd.
5. cpm sends the log to the relevant SmartConsole GUI application, such as SmartView
Monitor.
6. At the same time, depending on routing decisions made by the operating system and
excluding specific scenarios such as VPN routing, the packet is routed to a selected NIC.
The packet must go through the Firewall kernel again, only this time through the Out-
bound chain to the appropriate NIC and to the network.
_____________________
_____________________ 226
Chain Modules
Chain Modules are packet processing handlers. Handlers decide which modules will inspect
the packet and, based on the inspection, may then modify, pass, or drop the packets. Each
module in the chain has an unique job. The number of chains on a Security Gateway is based
on the number of blades and features enabled for that gateway. Inbound and outbound packets
are inspected in both directions by chain modules. Familiarity with the elements of a chain
module is an important step in understanding how traffic moves through the firewall, and will
ultimately be of great assistance when debugging is required.
Consider the following chain module example. The location of the module in the chain is a
relative, serial number to the location of this chain module for this particular gateway
configuration. For example, above the fw VM outbound is the 6th chain module. It may be in a
different location in other gateway scenarios. The chain position is an absolute number that
never changes. In the Firewall kernel, each kernel is associated with a key, which specifies the
type of traffic applicable to the chain module. For Wire Mode configuration, chain modules
marked with 1 will not apply and for Stateful Mode, the chain modules marked with 2 will not
apply. Chain Modules marked ffff, such as IP Options Strip/Restore, and 3 will apply to all
traffic.
Figure 201 — Chain Module Example
To take a look at an actual chain, use the fw ctl chain command. This will show you the
chain modules actually loaded on your machine and their order.
_____________________
_____________________ 227
Inbound fw ctl Chain Modules

View the chain modules displayed below. In this figure, we see the Inbound chain, though this
is just one example and in different configurations some chain modules will not appear and
others might be added. Between different releases, chain modules are added or removed,
depending on the version specific design decisions.
Figure 202 — Inbound Chain
Outbound Chain Modules

View the chain modules displayed below. Shown in this figure, the Outbound chain shows
roughly the same chain modules as seen on the Inbound. The most significant difference is that
in the Inbound, the vpn decrypt and vpn decrypt verify chain modules are present.
This makes sense because it is expected that a packet would be decrypted on the Inbound. In
addition, the Outbound chain also has the vpn encrypt chain module, if the packet needs to
be encrypted on the Outbound.
Figure 203 — Outbound Chain
_____________________
_____________________ 228
Wire Mode
Wire Mode enables VPN connections to successfully maintain a private and secure VPN
session without employing Stateful Inspection. Using Wire Mode, the Firewall can be
bypassed for VPN connections by defining internal interfaces and communities as “trusted”.
This improves the performance of the VPN tunnel and reduces downtime. With Stateful
Inspection no longer taking place, dynamic-routing protocols that do not survive state
verification in non-Wire Mode configurations can now be deployed. Wire Mode is based on a
trusted source and destination and uses internal interfaces, such as the Security Gateway and
VPN Communities.
Lab 1.5
Viewing the Chain Modules
_____________________
_____________________ 229
1.5
L
Viewing the Chain Modules A
B
One way to help understand how the Security Gateway handles traffic is to review the inbound and
outbound chain modules. These modules show how the kernel processes traffic as it enters and exits the
gateway. In this lab, you will make changes to the Security Policy and identify how those changes affect
the chain modules.
Ta sks :
• Evaluate the Chain Modules.
• Modify the Security Policy.
• Review Changes to the Chain Modules.
• Demonstrate an understanding of how different Check Point software blade deployments can affect
traffic inspection on the Security Gateway.
• Evaluate how changes in the environment affect the Chain Modules.
_____________________
_____________________ 230
Evaluating the Chain Modules

Review the chain module in place for kernel level traffic inspection.
1. Connect with SSH and use the following credentials to log into the A-GW-01 virtual machine:
Username: admin
Password: Chkp!234
2. Type the following command and press Enter:
fw ctl chain
Figure 204 — fw ctl chain
_____________________
_____________________ 231
3. Consider the following questions when evaluating the chain modules:

◦ Can you see how the traffic flows through the kernel?
◦ Besides the Firewall, what other modules are engaged?
◦ Can you tell if IPS is currently deployed?
◦ Could you tell if this is a cluster by looking at the inspection chain?
_____________________
_____________________ 232
Modifying the Security Policy

Make changes to the Security Policy that will be visible in the chain modules.
1. From A-GUI, use the following credentials to log into SmartConsole:
Username: admin
Password: Chkp!234
2. In SmartConsole, edit the A-GW-Cluster object.

3. In the Network Security tab, clear the following option:
IPSec VPN
_____________________
_____________________ 233
4. Verify that the object is configured as follows:
5. Click OK.
6. In the Alpha Security Policy, add the A-SMS to the Source field of the Management rule.
_____________________
_____________________ 234
7. Add SSH to the Services & Applications field of the Management rule:
Figure 206 — Management Rule Configured
_____________________
_____________________ 235
8. Publish the changes and install the Alpha Security Policy.
Figure 207 — Installation Process
_____________________
_____________________ 236
Reviewing Changes to the Chain Modules

Run the fw ctl chain command to view the chain modules.
1. In the Gateways & Servers tab, expand the A-GW-Cluster object.

2. Right-click the A-GW-01 and select Actions:
Figure 208 — Actions Menu
_____________________
_____________________ 237
3. Select Open Shell, and the system displays the following window:
Figure 209 — Open Shell
4. Use the following information to log into the shell:
Username: admin
Password: Chkp!234
Remember Password: Selected
5. Click Login, and the system displays the Fingerprint Confirmation window:
Figure 210 — Fingerprint Confirmation
_____________________
_____________________ 238
6. Click Yes, and the system opens an SSH session with A-GW-01:
Figure 211 — SSH Connection
_____________________
_____________________ 239
7. Type the following command and press Enter, to view the chain modules:
fw ctl chain
8. Review the inbound chain and the outbound chain and consider the following questions:
◦ What changes do you see since making modifications to the A-GW object?
◦ Can you tell if VPN is a deployed product?
◦ When comparing the chain after configuration changes were made, what differences can you see?
9. Close the session.
_____________________
_____________________ 240
10. From SmartConsole, edit the A-GW-Cluster object.

11. Select the QOS option in the Network Security tab:
12. Click OK.
NOTE
You will see an error because QOS is not properly deployed. Disregard this error in
this instance.
13. Publish the changes.

_____________________
_____________________ 241
15. Re-launch the session to A-GW-01.

fw ctl chain
NOTE
In Expert Mode, you can also send the output of the fw ctl chain command to 
a file.
17. Review the inbound chain and the outbound chain and consider the following questions:
◦ What changes do you see since making modifications to the A-GW object?
◦ Which line in each module indicates that QOS is deployed?
◦ What do you need to do to successfully deploy QOS?
_____________________
_____________________ 242
fw monitor
_____________________
_____________________ 243
19. From a new Putty session to A-GW-01, execute the following command:
fw ctl chain | more
20. Identify where in the chain fw monitor inserts itself.

21. From the session running fw monitor, press Ctrl + C.
22. Close the Putty session.
_____________________
_____________________ 244
23. In SmartConsole, edit the A-GW-Cluster object.

24. In the Network Security tab, clear the QOS option:
25. Click OK.
_____________________
_____________________ 245
26. Remove A-SMS from the Source field of the Management Rule:
Figure 218 — Rule Base Configured

END OF LAB 1.5
_____________________
_____________________ 246
S t a te f u l I n s p e c t i o n
Stateful Inspection was invented by Check Point to provide accurate and highly efficient traffic
inspection. Apart from checking the IP Header of a packet, Stateful Inspection also implements
checks on other characteristics of a packet, such as TCP stream, sequence numbers, UDP
communication and port numbers to monitor the state of a packet operating primarily at the
Transport layer of the operating system. The Inspection Engine examines every packet as they
are intercepted at the Network layer. The connection state and context information are stored
and updated dynamically in the kernel tables. Kernel tables are also known as State tables.
To see the process flow of the Inspection Engine, review the flow chart below.
Figure 219 — Inspection Process Flowchart
1. Packets pass through the Network Interface Card (NIC) to the Inspection Module, which
inspects the packets and their data.
2. Packets are matched to the policy Rule Base. Packets that do not match any rule are
dropped.
3. Logging and/or alerts that have been defined are started.
4. Packets that pass inspection are moved through the TCP/IP stack to their destination.
5. For packets that do not pass inspection and are rejected by the rule definition, a negative
acknowledgment (NACK) is sent (i.e. RST packet on TCP and ICMP unreachable on
UDP).
6. Packets that do not pass inspection and do not apply to any of the rules are dropped with-
out sending a NACK.
_____________________
_____________________ 247
S e c u r i t y S e r ve r s
Security servers are a necessary and crucial element to Firewall functionality. Some Firewall
features require a higher level of protocol enforcement and RFC compliance, such as in the
Application Layer.
Security servers are the individual processes within the Firewall system that are responsible for
the detailed protocol-specific security inspection such as FTP, HTTP, or SIP and other
inspection services like DLP.
NOTE
When Identity Awareness is deployed, this process operates differently.
How a Security Server Works

Essentially, when a client initiates a connection to a server, the Firewall kernel signals the fwd
process using a trap. fwd spawns the fwssd child service, which runs the Security server.
Then, the Security server binds to a socket and manages the connection.
fwd waits for connections on the ports of other servers (daemons) and starts the corresponding
server when the connection is made. fwd also talks to its children processes on other servers
using a pipe and signals.
The $FWDIR/conf/fwauthd.conf file contains the structure of the security servers

showing the port numbers, corresponding protocol name, and status. If the real port is 0, then a
higher random port is assigned.
Figure 220 — Example of $FWDIR/conf/fwauthd.conf
_____________________
_____________________ 248
Ker n el Ta b le s
There are dozens of kernel tables, each storing information relevant to a specific Firewall
function. Using the information saved in the kernel tables, very elaborate and precise
protections can be implemented. To view all existing kernel tables, type the command fw
tab -t <tablename> at the command prompt. To view only the table names and get a
perspective on the number of kernel tables available, use the fw tab -s command.
Most traffic related information is saved in the kernel tables. Information is also stored in
htabs, ghtabs, arrays, kbufs, and other devices. Tables may be created, deleted,
modified, and read. In particular, consider the Connections table.
Connections Table
The Connections table is essentially an approved list of connections. The Firewall, as a
network security device, inspects every packet coming in and out of each interface. After the
first packet is matched against the Rule Base, we assume that the returning packet might not be
accepted in the Rule Base.
For example, we allow 74.100.100.1 to connect with 212.150.141.5 using Telnet on port 23 in
the Rule Base and drop everything else. The syn packet will match the Rule Base and pass; but
the Syn-Ack packet comes back with the reversed tuple (source IP 212.150.141.5, Destination
IP 74.100.100.1) and source port 23 with a random destination port. (Reference the
Connections Table figure in the following section).
To mitigate this, for every recorded connection, a matching, reversed-tuple entry is also added
to the list of approved connections. Some scenarios such as NAT, data connections and
elaborate protocols, such as Voice over IP (VoIP), introduce more complexity to the logic
behind maintaining the Connections table.
The Connections table provides enhanced performance. As we saw in the Inspection Process
Flowchart, the action of matching a packet against the Rule Base may be very costly
(especially if there is a very large Rule Base with dynamic objects and logical servers that need
to be resolved). By maintaining the list of approved connections in the Connections table, the
gateway can enforce an intelligent analysis for assumed rule-matching, thus saving valuable
time and computing power.
_____________________
_____________________ 249
The Connections table also allows server replies. We noted earlier that sometimes Server to
Client (S2C) packets might not match the Rule Base. In these cases, they would be handled by
the Connections table. To view the Connections table, use the following command:
fw tab -t connections -f
NOTE
Using the fw tab -t connections -f command could impact
performance.
The following Stateful features are provided with the Connections table:
• Streaming based applications

• Sequence verification and translation
• Hide NAT (Explicit entries to the Connections table may need to be added when the
S2C packets returning to the Firewall may not match the Rule Base.)
• Logging, accounting, monitoring, etc.
• Client and server identification
• Data connections
_____________________
_____________________ 250
Connections Table Format

Each new packet is recorded in the table in all available entries. In FireWall-1 version 4.1, only
one entry was made to each new connection. Each packet had to go through the Connections
table several times to verify all available types of connection. Today, each packet goes through
a single lookup as all available entries are already recorded in the table.
Figure 221 — Connections Table
The Symbolic Link format provides the 6-tuple of the connection we want to pass. The arrow
is a pointer to the tuple of the Real Entry in the Connections table. The first six attributes in
every entry in the Connections table state the connection’s 6-tuple. The 6-tuple is a unique
identification of the connection within the system. The direction can be either 0 for Inbound or
1 for Outbound.
In the Connections Table figure, we see a simple connection representation in the Connections
table. The first entry is called the Real Entry and holds all of the relevant information for that
traffic, such as state, sequence numbers and matching rule.
The Real Entry allows the Client to Server (C2S) packet to enter the Firewall on the Inbound.
The second entry is a Symbolic Link, allowing for the same C2S packets to enter the Firewall
on the Outbound. The third entry is another Symbolic Link that allows for the S2C traffic to
enter the Firewall on the Inbound. The last entry is also a Symbolic Link and allows for the
S2C packet to enter the Firewall on the Outbound.
_____________________
_____________________ 251
Po l i c y I n s t a l l a t i o n
The policy installation process is divided into three main stages: Verification & Compilation,
Transfer (CPTA), and Commit.
Figure 222 — Policy Installation Process
_____________________
_____________________ 252
Verification & Compilation

The Verification & Compilation stage of policy installation occurs on the management side. It
involves the following steps:
1. Initiation — Policy installation is initiated either from SmartConsole or from the com-
mand line. Information required for the policy installation, such as the list of gateways on
which the policy is to be installed, is provided. User permissions for policy installation
will also occur prior to continuing to the next step in the process.
2. Database Dump — A database dump from postgres to old file formats for cpmi-
table only if changes occurred. A dump from non cpmi will occur any time.
3. Verification — Information in the database is verified to comply with a number of rules
specific to the application and package for which policy installation is requested. If this
verification fails, the process ends here, and an error message is passed to the initiator. The
system can also issue warnings in addition to fail/success messages.
4. Conversion — The information in the database is converted from its initial format to the
format understandable by later participants in the flow, such as code generation and gate-
way.
5. Fwm rexec — Fwm loader takes a lot of memory. To release memory after verification
and conversion, fwm state is saved to a file located in the $FWDIR/tmp/ directory.
fwm is then re-executed as a fwm load command to push the files for code generation
and compilation.
6. Code Generation and Compilation — Policy is translated to the INSPECT language and
compiled with the INSPECT compiler. Also, some additional data transformations are
completed. After verifying and converting the database, the fwm process compiles the rel-
evant files, such as objects_5_0.C, and AccessCTRRules_0.C, into several com-
piled files (local.ft, local.set, etc.). The complied policy will be copied to the
$FWDIR/state/<gateway name> directory on the management server.
Transfer (CPTA)
The Transfer stage occurs between both the management server and the gateway. Once the
policy is successfully compiled and moved to $FWDIR/state/<gateway> on the
management server, the Check Point Policy Transfer Agent (CPTA) transfers the compiled
policy to the gateway using SIC. Using SIC will ensure that the management server is eligible
to install policy on the gateway. It also encrypts the connection via SSL so that the policy data
transferred to the gateway is trusted. Once SIC is initialized, SIC authentication will occur for
every policy installation.
_____________________
_____________________ 253
Commit
During the Commit stage, the Firewall is instructed to load the new policy it has just received
from the management server. The following steps will occur:
• The cpd process on the gateway will execute the following command to load the
policy which was just transferred to the gateway:
fw fetchlocal -d $FWDIR/state/_tmp/FW1
• The policy will then be loaded into the kernel.
• If successful, the new policy will be copied to the $FWDIR/state/FW1 folder on the
gateway.
• If the fetchlocal process fails, cpd will get a notification regarding the failed
process and will inform the fwm process that loading the policy has failed.
_____________________
_____________________ 254
Policy Installation Flow

The graphic below displays a general process flow for policy installation. Differences are
version specific, so $FWDIR is replaced with the compatibility package when other products
or versions are used.
Figure 223 — Policy Installation Flow
1. The policy is defined in SmartConsole.

2. After the policy is published, it is saved in the postgres database. At a push, verifica-
tion of user permission is performed.
3. Database dump from postgres to old file formats (object_5_0.C and others) for
cpmitable, only if changes occurred, and a dump for non cpmi will occur. All *.W files
are stored in rulebases_5_0.fws.
4. After the policy is saved, files are created under $FWDIR/conf/*.W.
5. fwm_gen compiles the new $FWDIR/conf/*.W into a machine language, creating a
new file called $FWDIR/conf/*.pf. The $FWDIR/conf/*.pf is actually the input
from the $FWDIR/conf/*.W and the $FWDIR/conf/objects.C files. The
$FWDIR/conf/*.W file is the exact same information defined in the GUI, just in a text
format instead of a graphic one.
6. c_preprocessor compiles the *.pf and lib/*.def files, creating a new file called
*.cpp.
7. All new generated files are stored under $FWDIR/state/ on the management server.
*.ccp is compiled and translated to a machine language and transferred to the gateway.
8. $FWDIR/state/ directory is pushed to the enforcement module (gateway).
9. cpd and the kernel on the enforcement module performs an automatic load.
_____________________
_____________________ 255
Policy Installation by Management Processes

Now we will examine how policy installation is handled by the Management processes.
Figure 224 — Policy Installation by Management Processes
When policy installation is initiated from SmartConsole:
1. The Check Point Management Interface (cpmi) policy installation command is sent to
fwm on the Management server.
2. fwm performs verification and conversion of the database information for the installation
targets for which policy installation is requested.
3. After conversion, fwm invokes fw loader to perform code generation, compilation,
transfer to all applicable gateways, and commit.
4. cpd on the Security Gateway listens for install policy connections and receives the files.
5. cpd invokes fw fetchlocal to load the new policy into the kernel.
6. cpd waits for fw fetchlocal to complete the process and then informs the Manage-
ment server of the command’s status (installation succeeded or failed).
NOTE
Additional steps may be included for debugging purposes.
_____________________
_____________________ 256
Rul e Mat c h in g
The Security Gateway determines the rule to apply to a connection; therefore, it is important to
understand how rules are matched. The columns of a rule contain the expected elements of a
connection and dictate what happens to the connection.
Column Based Matching

Security Gateway versions prior to R80.10, inspect and match connections row by row (left to
right), based on the order of rules within the Rule Base. The Rule Base is examined top-to-
bottom and the first matching rule is executed.
R80.10 and later Security Gateways match rules by column, such that only the rules within the
Rule Base that may possibly match a connection are considered. Column based matching
eliminates the process of examining rules which do not contain the applicable elements of the
connection.
The Matching Process

Access Control Policy rules use the following columns to filter and match traffic entering and
exiting the network:
• Source
• Destination
• VPN (if enabled)
• Services & Applications (if Appl Control & URL Filtering Software Blades are
enabled)
• Content (Content Awareness must be enabled)
• Time
• Installed On (target gateway)
Inspection starts in the first ordered layer of the Access Control policy (usually Policy or
Network). If a matched rule contains an inline layer, that inline layer is processed. Matching
continues with each additional ordered policy layer after a successful match. Any drop stops
the matching process and drops the connection.
Currently, the Security Gateway begins examining the fields of the Destination column to
identify rules that may match the connection. When possible matches are filtered, matching
continues with the Source column. Final inspection on the filtered results occurs when all
columns are matched and the first rule (top to bottom) that matches is executed for that layer,
and subsequent inline or ordered layers are processed.
_____________________
_____________________ 257
The illustration below displays the matching process for traffic connecting to the A-Host from
the B-Host using FTP.
Figure 225 — Column Based Matching Illustration
A Unified Access Control policy may contain application or data criteria that cannot be
matched on the first packet connection. The integration of application and data criteria requires
deep packet inspection.
To optimize the matching process, the Firewall may need to turn on one or more inspection
engines and inspect the header and body of the connection before determining the final match.
Otherwise, the Rule Base may decide to block the connection at an early stage. An early block
may indicate that the connection did not contain enough applicable data criteria for the engine
to make a proper detection, or that all potential rules matching the connection result in a Drop
or Reject action.
Additional levels of inspection include matching by port and matching by protocol signatures.
_____________________
_____________________ 258
Rule Matching by Port

By default, a service object is matched by port in the first packet of the transport protocol.
When matching by port, the Firewall blade does not consider the actual protocol that runs over
the port, although service names and port numbers typically identify services (like HTTP,
HTTPS, and FTP) that run over transport protocols (such as TCP and UDP). For example, if
the Firewall log indicates that HTTP service was matched on port 80, this means that the first
packet contained port 80 in the transport protocol.
Rule Matching by Protocol Signature

For R80.10 and later gateways, more advanced inspection of the protocol for a service is
possible if Protocol Signature is enabled for that service. Matching a rule by protocol signature
or by service provides an additional level of security when the Rule Base contains rules
including:
• an application, a URL site, or a service with a protocol signature in the Services &
Applications column
• a data type in the Content column
Matching by protocol signature and services is discussed in greater detail in the CCSM.
NOTE
The match by protocol signature feature is disabled by default for R80 and
higher gateways. The Firewall cannot match services by protocol signature
for R77.30 and lower gateways.
_____________________
_____________________ 259
Rule Matching in the Threat Prevention Policy

R80.10 and higher Threat Prevention policies may contain multiple Ordered layers in which
the Security Gateway installs as one Rule Base. The unified Rule Base determines how all
connections are inspected. When a connection matches rules in more than one layer, the
gateway enforces the strictest action and settings.
Figure 226 — Threat Prevention Policy Rule Matching Example
When Threat Emulation and Threat Extraction run in Mail Transfer Agent (MTA) mode, the
action of the first rule matched is enforced. Threat Emulation runs in tandem with Threat
Extraction for R80.10 and higher gateways. To enable the Threat Extraction Software Blade,
the gateway must be established as an MTA.
Threat Prevention solutions are discussed in greater detail in a later chapter.
_____________________
_____________________ 260
N et wo rk Ad d r es s Tr a ns l a t i on
Network Address Translation (NAT) and Network Address Port Translation (NAPT) are the
two primary technologies traditionally used as methods to hide networks so actual IP addresses
are not revealed or required to be publicly routable. This reduces the need for more publicly
routable IPs, and allows access to internal (sometimes non-routable) resources from an
external network.
How NAT Works

NAT is regarded as an infrastructure of services used, for example, to create clustering
solutions, security servers, office mode connections, etc.
Infrastructure Features
• INSPECT rules and tables • NAT Rule Base is efficient
• Performed on the first packet • Dual NAT (automatic rules)
• Rule priorities
Table 6: NAT
When NAT is defined on a network object, NAT rules are automatically added to the NAT Rule
Base. Those rules are called Automatic NAT rules. NAT is translated during policy installation
to tables and performed on the first packet of the connection. The NAT Rule Base is very
efficient and can match two NAT rules on the same connection. This is called bi-directional
NAT and only applies for Automatic NAT rules.
NOTE
Even though NAT merges two Automatic NAT rules into one, this feature
may be disabled and NAT rules may be manually defined for additional
options.
NAT rules are prioritized according to the list below:
1. Manual/Pre-Automatic NAT
2. Automatic Static NAT
3. Automatic Hide NAT
4. Post-Automatic/Manual NAT rules
_____________________
_____________________ 261
Hide NAT Process

Consider first the original packet. When the packet arrives at the Inbound interface, it is
inspected by the Security Policy. If accepted, the packet is entered into the Connections table.
The first packet of the connection is matched against NAT rules. The packet is translated if a
match is found. Then the packet arrives at the TCP/IP stack of the Firewall Module machine
and is routed to the Outbound interface.
Figure 227 — Hide NAT
During the NAT Rule Base traversal, both NAT source and destination are decided. However,
they are actually performed at the following locations:
• src nat on the server side

• dst nat depending on the relevant GUI property
The Reply packet arrives at the Inbound interface of the Firewall machine. The packet is
passed by the Security Policy since it is found in the Connections table. The packet's
destination, which is the source of the original packet, is translated according to the NAT
information. This takes place when the packet was translated in the first initial connection. The
packet arrives at the TCP/IP stack of the Firewall machine and is routed to the Outbound
interface. The packet goes through the Outbound interface and its source, the destination of the
original packet, is translated according to the information in the NAT tables. The packet then
leaves the Firewall machine.
_____________________
_____________________ 262
Manual NAT
Many organizations prefer to define their own NAT rules rather than relying on the system
generated rules. There are also certain situations when manual NAT rules must be used, such as
when:
• Rules exist that are restricted to specified destination IP addresses and to specified
source IP addresses.
• Both source and destination IP addresses translate in the same packet.
• Static NAT occurs in only one direction.
• Rules exist that only use specified services (ports).
• IP addresses translate for dynamic objects.
The NAT Rule Base is processed one rule at a time from top to bottom, similarly to the
Firewall Rule Base. Therefore, Manual NAT rules must be placed in the right order to be
applied correctly. Manual NAT rules are added to the NAT Rule Base either above or below
any already existing Automatic NAT rules. For example, in the figure below, the first NAT rule
was manually created and the other NAT rules were automatically generated based on the NAT
settings applied to the respective network objects. The Manual NAT rule is placed at the top of
the NAT Rule Base so that it is the first rule to be matched.
Figure 228 — Manual NAT Example
The NAT Rule Base consists of the source, destination, and services information for the
original packet and the translated source, destination and services information after NAT has
been applied. The processing order for the overall inspection and routing of packets by the
Security Gateway is as follows:
1. Firewall — Inspection on the Original Packet.

2. NAT — Translate the IP and/or port number as required.
3. Routing — Forward on the resulting packet.
_____________________
_____________________ 263
When configuring Manual NAT in Global Properties, check the Translate destination on client
side checkbox in the Manual NAT rules section.
Figure 229 — Global Properties for NAT Rules
_____________________
_____________________ 264
Proxy ARP for Manual NAT

For Manual NAT rules, it is necessary to configure proxy ARPs to associate the translated IP
address. A proxy ARP allows the Security Gateway to answer ARP queries for a network
address that is located on that same network. The ARP proxy is aware of the location of the
traffic’s destination, offering its own MAC address as the destination. When the data is
received from the external network, the Security Gateway forwards the data to the relevant
host on the internal network.
The configuration of proxy ARPs is necessary for situations such as when a manual Static NAT
rule has been created and the Security Gateway does not answer the ARP requests for the
Static NAT’d IP address in the Manual NAT rule. Another situation would be when a Security
Gateway replies to ARP requests with an incorrect MAC address, mostly for the NAT traffic.
To configure a proxy ARP:
1. Match the IP addresses of the relevant hosts on the internal network to the MAC address
of the Security Gateway on the external network. This is saved in the $FWDIR/conf/
local.arp file.
2. Create the relevant Manual NAT rules.
3. Install the Security Policy.
_____________________
_____________________ 265
Firewa ll Admi ni stra ti on

In addition to understanding the Firewall kernel structure, it is important to familiarize yourself
with configuration file structure and commands typically used for troubleshooting problems.
To begin with, lets consider how the Firewall configuration files are broken down. The main
sub-grouping of configuration files are divided into directories located under /opt.
• CPsuite-R80 — Manages Firewall modules (R75.20 - R80). CPsuite is the generic
installation.
• CPshrd-R80 — Stores what used to be called SVN foundation, including cpd database,
licenses, registry and generic low level Check Point infrastructure. (not version related).
• CPEdgecmp-R80 — Manages Edge devices.
The /lib and /conf directories store definition files that are important to take into
consideration. For instance, the $FWDIR/lib/*.def files include Rule Base and protocol
definitions. User definitions are stored in $FWDIR/conf/fwauth.NDB and Security server
configuration settings are stored in $FWDIR/conf/fwauthd.conf.
$FWDIR/conf/classes.C defines fields for each object used in the objects_5_0.C

file, such as color, num/string and default value. Though the $FWDIR/database/ directory
on the Management server has no relevancy, this directory is particularly noteworthy on the
gateway itself, where specific object entries are stored for that particular gateway. There are
different ways to view and edit database files such as these.
• dbedit — A command line utility on the Management server itself.

• GuiDBedit.exe — An executable tool on the Windows-based GUI client machine
under: 
C:\Program Files (x86)\CheckPoint\SmartConsole\R80\Program.
NOTE
The objects_5_0.C file is still used for legacy gateways on R77.30 and
older. The database for R80.10 is located in PostgreSQL. x86 was added to
the path because most computers now run in 64-bit mode.
_____________________
_____________________ 266
Common Commands
• cpconfig — This command is used to run a command line version of the Check
Point Configuration tool and configure or reconfigure a Security Gateway/Management
installation.
• cplic print — Located in $CPDIR/bin, this command prints details of Check
Point licenses on the local machine. cplic print -x prints the licenses with
signatures and cplic del <signature> deletes a license.
• cpstart — This command is used to start all Check Point processes and applications
running on a machine.
• cpstop — This command is used to terminate all Check Point processes and
applications running on a machine.
The commands cpstop and cpstart are actually calling fwstop and fwstart scripts
for all Check Point products, including the Firewall stop/start scripts located in $FWDIR/bin.
These are scripts that run when you perform cpstop, cpstart and cprestart with
different flags. cprestart is an internal command used for Dynamically Assigned IP
(DAIP) devices, such as Edge devices. Not all Check Point processes are brought down when
cprestart is used; therefore, cpstop and cpstart should always be used.
_____________________
_____________________ 267
FW Monitor
The Check Point tool, fw monitor, is a packet analyzer tool which is on every Check Point
Security Gateway and is essential for packet capture and Firewall traffic analysis. It provides
kernel level inspection; but will not run in indiscriminate mode. fw monitor works for
layers 3 and above in the OSI Network layer stack. The syntax is the same regardless of the
platform and supports the.pcap output format used in Ethereal and Wireshark packet
analyzer tools.
The easiest way to use fw monitor is to invoke it without any parameters. However, in a
busy system, running fw monitor without any filters can create a great detail of output and
makes the analysis difficult. Filter expressions are used to specify packets to be captured and
limit the amount of output. The general syntax is:
fw monitor -e “accept <expression>;” -o <filename>
Filter expressions include:
• host [<IP_Address>]
• net [<Network_IP_Address>, <Mask_Length>]
• port [<IANA_Port_Number>]
NOTE
Check Point recommends turning SecureXL (fwaccel off) when using
fw monitor to avoid misleading traffic captures. If SecureXL is on, the
tool will only show non-accelerated packets. SecureXL is discussed in a
later chapter.
_____________________
_____________________ 268
For example, to capture everything between host X and host Y:
[Expert@HostName]# fw monitor -e “host(x.x.x.x)and

host(y.y.y.y),accept;” -o/var/log/fw_mon.cap
For more fw monitor capture examples, refer to sk30583.
C2S Connections and S2C Packets

fw monitor captures packets as they enter and leave the Firewall kernel and when the
packet enters and leaves the Inbound and Outbound chains. In the case of Client-to-Server
(C2S) communication, a client designated as Host1, according to the policy, sends traffic
destined for a web server located behind the Firewall. Since the traffic is permitted passage
through the Firewall based on the policy Rule Base, the packet must traverse and be inspected
by both chains of the Firewall.
The command fw monitor works by loading a special filter that is applied to suspicious
packets. This filter is different from the INSPECT filter used to implement a Rule Base. Where
the Rule Base determines which packet is accepted, rejected or dropped, the INSPECT filter
generated by fw monitor simply captures kernel packet flows. You can capture everything
through the kernel using fw monitor, even a particular type of traffic or source.
Once fw monitor is executed, the specified INSPECT filter is compiled and loaded to the
kernel. Any parameters following accept in the fw monitor command will be displayed by
fw monitor. The same filter is executed on all interfaces in all directions. The fw
monitor output uses specific expressions to explain the location of the packet as it moves
through the Firewall.
Figure 231 — C2S and S2C Connections
_____________________
_____________________ 269
There are four inspection points as a packet passes through the kernel:
• i — Before the virtual machine, in the Inbound direction (pre-Inbound)

• I — After the virtual machine, in the Inbound direction (post-Inbound)
• o — Before the virtual machine, in the Outbound direction (pre-Outbound)
• O — After the virtual machine, in the Outbound direction (post-Outbound)
In our C2S scenario, i represents the packet as it left the client. The I represents the packet
already checked against the tables and Rule Base. In case of Static NAT, the destination IP
address will be changed. The o means the packet is before the Outbound kernel (same as I) and
O means the packet is in the Outbound kernel chain, as it will appear at the web server. In the
case of Hide NAT, the source IP address will be different here.
For packets traveling from Server-to-Client (S2C), the inspection points are the reverse. I
could be the NAT’d packet on its way out of the Inbound chain in the Firewall in the case of
Static NAT. At this point, the packet has already been checked by the tables and Rule Base.
The O is the packet as it will appear to the client.
Lab 1.6
Configuring Manual NAT
_____________________
_____________________ 270
Configuring Manual 
1.6
L
A
Network Address Translation
B
In some circumstances, you may want to define your own NAT rules rather than rely on the automatic
system generated NAT rules. In this lab, you will configure manual NAT for HTTP traffic incoming to the
DMZ server.
Ta sks :
• Configure Manual NAT in the Security Policy.
• Configure the ARP file to facilitate NAT functionality.
• Test Manual NAT for HTTP traffic to the A-DMZ server.
• Complete the tasks necessary to perform Manual Network Address Translation.
• Create the ARP entries necessary for Manual NAT.
_____________________
_____________________ 271
Configuring the Security Policy

Follow these steps to define manual NAT in the Security Policy.
1. In the Alpha_Standard Security Policy, disable the DMZ rule:
Figure 232 — DMZ Rule Disabled
2. Edit the A-DMZ object:
Figure 233 — A-DMZ
_____________________
_____________________ 272
3. In the navigation pane, select NAT.

4. In the NAT page, clear the following option:
Add automatic address translation rules
Figure 234 — A-DMZ - Automatic NAT Disabled
5. Click OK.
_____________________
_____________________ 273
6. In the Alpha_Standard Security Policy, select Access Control > NAT.

7. Confirm that A-DMZ is not included in the Static NAT rules:
Figure 235 — Network Address Translation Rules

9. In the objects pane of SmartConsole, create a new Host object.
_____________________
_____________________ 274
10. Use the information below to define the General page of the new Host:
Name: A-DMZ-NAT
Comment: Static NAT address of A-DMZ
Color: Dark Blue
IP Address: 203.0.113.171
Figure 236 — A-DMZ-NAT
11. Click OK.
_____________________
_____________________ 275
12. In the Rule Base, add a new rule above the disabled DMZ rule:
Figure 237 — Default Rule Added
_____________________
_____________________ 276
13. Use the following information to configure the new rule:
Name: Incoming
Source: Any
Destination: A-DMZ-NAT
Services & 
Applications: http
Action: Accept
Track: Log
Install On: A-GW-Cluster
Figure 238 — Incoming Rule
_____________________
_____________________ 277
14. View the NAT Rule Base:
Figure 239 — NAT Rule Base
_____________________
_____________________ 278
15. Add a new rule to the top of the NAT Rule Base:
Figure 240 — Default Rule Added to NAT Rule Base
NOTE
To add the first manual NAT rule to the NAT Rule Base, select the Add Rule to Top
button from the toolbar directly above the NAT Rule Base.
16. In the Original Destination field, add the A-DMZ-NAT object.

17. In the Original Services field, add HTTP.
18. In the Translated Destination field, add A-DMZ.
19. In the Install On field, add A-GW-Cluster.
_____________________
_____________________ 279
20. Verify that the new rule appears as follows:
Figure 241 — Manual NAT Rule Configured
_____________________
_____________________ 280
21. Add a new rule below the first manual NAT rule.
22. In the Original Source column, add A-DMZ.
23. In the Original Services column, add HTTP.
24. In the Translated Source column, add A-DMZ-NAT.
25. In the Install On column, add A-GW-Cluster.
26. Verify that the new reciprocal manual NAT rule appears as follows:
Figure 242 — Reciprocal Manual NAT Rule Configured
_____________________
_____________________ 281
27. Publish the changes to the database:
_____________________
_____________________ 282
Configuring the ARP Table

Configure the ARP table for manual NAT to work successfully.
1. From A-GUI, connect to the Gaia Portal on A-GW-01:
_____________________
_____________________ 283
2. In the navigation pane, select ARP:
Figure 245 — Gaia Portal - ARP
_____________________
_____________________ 284
3. In the Proxy ARP section of the page, click the Add button.
4. Use the information below to configure the Add New Proxy ARP Entry window:
IPv4 Address: 203.0.113.171

Advertise IP via: Interface Name eth3
Real IP Address: 203.0.113.2
Figure 246 — Add New Proxy ARP Entry Configured
_____________________
_____________________ 285
5. Click Save, to add the entry to the ARP table:
Figure 247 — Proxy ARP Entry Added
6. Log out of the Gaia Portal on A-GW-01.
_____________________
_____________________ 286
7. Log into the Gaia Portal on A-GW-02.

8. In the navigation pane, select ARP.
9. In the Proxy ARP section of the page, click Add.
10. Use the information below to configure the Add New Proxy ARP Entry:
IPv4 Address: 203.0.113.171

Advertise IP via: Interface Name eth3
Real IP Address: 203.0.113.3
Figure 248 — Add New Proxy ARP Entry Configured
_____________________
_____________________ 287
11. Click Save, to add the entry to the ARP table:
Figure 249 — Proxy ARP Entry Added
12. Log out of the Gaia Portal on A-GW-02.
_____________________
_____________________ 288
13. In SmartConsole, select Global Properties from the Application Menu.

14. In the navigation pane, select NAT - Network Address Translation.
15. On the NAT page, select the following option:
Merge manual proxy ARP configuration
Figure 250 — Global Properties - NAT Configured
16. Publish the changes and install the Alpha_Standard Security Policy.
_____________________
_____________________ 289
17. From B-Host, open a Web browser.

18. Use HTTP to connect to the static NAT address of A-DMZ (203.0.113.171).
19. From A-GUI, identify the accepted HTTP traffic from B-Host to A-DMZ.
20. View the log details to see the NAT taking place.
_____________________
_____________________ 290
Reconfigure the Alpha Rule Base

Remove the manual NAT configuration and configure automatic Static NAT for the DMZ object.
1. In the Alpha Security Policy, delete the Incoming rule.

2. Enable the DMZ rule.
3. Add the following to the Services & Applications field of the DMZ rule:
ftp
4. Configure the Destination column of the DMZ rule to include only the A-DMZ object:
Figure 251 — DMZ Rule Configured
_____________________
_____________________ 291
5. Edit the A-DMZ object.

6. Use the information below to configure the NAT settings for A-DMZ:
Add automatic address translation rules: Selected

Translation Method: Static
Translation IP Address: 203.0.113.171
Install on Gateway: A-GW-Cluster
Figure 252 — Host - NAT Configured
7. Click OK.
8. In SmartConsole, view the NAT Rule Base.
9. Delete the two manual NAT rules.
10. Delete the A-DMZ-NAT object.
_____________________
_____________________ 292
11. Confirm that the Alpha NAT Rule Base appears as follows:
Figure 253 — NAT Rule Base Configured
END OF LAB 1.6
_____________________
_____________________ 293
Review Questions
1. What is CPUSE and what is it used for?
2. Name at least three Stateful features provided with the Connection table.
_____________________
_____________________ 294
C
2
H
P
Automation & Orchestration T

E
R
Trusted Application Programming Interfaces (APIs) enable enterprises using network or

orchestration systems to securely integrate a security management solution that has
automation capabilities into their workflow processes. The Check Point API makes it easy
to integrate securely with orchestration, change management and ticketing systems. With
the ability to control exactly what that integration can and cannot do, organizations have
the confidence to embed security into their IT ecosystem.
Learning Objectives
• Recognize how Check Point’s flexible API architecture supports automation and orchestration of
daily operations.
• Understand how to use the management API command line tools and web services to read
information, create objects, work on Security Policies, and send commands to the Check Point
Security Management Server.
_____________________
_____________________ 295
Automation & Orchestration

Automation is the process of automating tasks normally performed by human intervention to
be performed by a machine as a means to providing efficiency and minimizing human error.
Orchestration is the choreography of automating the arrangement, coordination and
management of processes performed within complex computer systems and services into a
logical workflow. It reduces the time and effort for deploying multiple instances of a single
task by automatically performing a series of tasks which previously could only be performed
by multiple administrators.
How Automation and Orchestration Differ

Automation and Orchestration differ in that automation relates to codifying tasks whereas
orchestration relates to codifying processes. Automation is concerned with executing a single
task, such as launching a web server or stopping a service, in a repeatable, consistent manner.
Orchestration takes a series of automated tasks developed through automation and puts them
all together into a process workflow which can simplify the complex management of today’s
network security infrastructures. For example, an organization may use a cloud orchestrator
programming to manage the interconnections and interactions among their cloud-based and
on-site business units. Orchestration also involves the process of coordinating an exchange of
information through web service interactions, such as XML and JSON.
C h e c k Poi n t A P I s
Check Point’s R80.10 Security Management platform provides the framework to support both
Automation and Orchestration through its flexible API architecture. An API is a set of
routines, protocols, and tools for building software applications. Check Point provides a
complete CLI and API interface for security management which will enable the automation of
daily operations and full integration with 3rd party and other systems, such as network
management systems, ticketing systems, virtualization servers, and cloud orchestrators.
Automation and SmartConsole management operations are allowed based on the same
privilege profile.
Check Point APIs allow system engineers and developers to make changes to their
organization’s Security Policy with CLI tools and Web Services. An API can be used to:
• Execute an automated script to perform common tasks.

• Integrate Check Point products with 3rd party solutions.
• Create products that use and enhance the Check Point solution.
_____________________
_____________________ 296
There are different APIs for various Check Point products:
• Management API — Used to read information, create objects, work on Security

Policies and send commands to the Check Point Security Management Server. The
Management API has a JSON/XML web services option, a Gaia CLI from the R80.10
SmartConsole, the new mgmt_cli tool, and the Gaia Clish.
• Threat Prevention API — A cloud-based service used to control Threat Emulation,
Antivirus, and Threat Extraction products.
• Identity Awareness Web Services API — A web services API used to add, remove,
and show the status of identity parameters. For example, using the API, a new user can
be added to an Access Role or a user can be allowed to connect to the internal network
from a different IP address.
• OPSEC SDK — These APIs are used to open and monitor connections between the
Security Management Server and gateways, and other hosts and objects.
During this course, we will focus solely on the Management API.
NOTE
OPSEC SDK contains APIs for commands that were originally used with
SecurePlatform. These commands can also be used on the Gaia operating
system.
_____________________
_____________________ 297
C h e c k Poi n t A P I A rc hi te c t u r e
The Check Point API Architecture consists of the API server and API interaction mechanisms.
The API server communicates with CPM in the same way as SmartConsole. An API
automated session will generate audit logs and will display the validation errors and warnings.
The API architecture also supports Concurrent Administration. The same permission profiles
that control the GUI are enforced when using an automation session.
The API server uses JavaScript Object Notation (JSON) for data interchanges. JSON is a
lightweight data-interchanging format which is easy for individuals to read and write, and for
machines to parse and generate. Interaction mechanisms are command sources, such as Web
Services and Management CLIs. All API clients use the same port as the Gaia Portal.
Figure 254 — API Architecture
Command Sources
Command sources allow you to communicate with the API server and perform many tasks
using management APIs.
• The SmartConsole GUI console — From SmartConsole, click the Command Line
button to open a CLI window and enter API commands. For example, you can use the
add host command to create a new host and then publish the changes.
• The mgmt_cli Tool — Runs in Expert mode and lets you enter commands from a
Windows or Linux computer. mgmt_cli uses the same authentication (username and
password) as the GUI client; however, it does not require a GUI installation.
• Gaia CLI — Log in to Gaia with an administrator account on the Security
Management Server and enter API commands using Clish.
• Web Services — Send HTTPS Post requests to the Security Management Server.
_____________________
_____________________ 298
RESTful API
RESTful APIs allow systems to use web services to access, manipulate, delete, change, and
add resources. They use standard HTTP methods sent by script to GET, PUT, POST, and
DELETE data. The management API uses RESTful API to send calls using the POST method.
An example of using a RESTful API to call the login would be:
HTTP POST https://<mgmt>/web_api/login

Content-Type: application/json
The content type Header tells the client how to compose requests in the body to the server.
_____________________
_____________________ 299
Operational Flow
The chart below diagrams the operational flow of an API session.
Figure 255 — API Operational Flow
_____________________
_____________________ 300
API Server Configuration

The management API server is part of the R80.10 management server installation. To manage
security through API and CLI, you must first configure the API server.
The API server runs scripts that automate daily tasks on the Security Management Server. It
also integrates Check Point products with third party systems. To configure the API server, in
SmartConsole, go to Manage & Settings > Blade. In the Management API section, click
Advanced Settings and the Management API Settings window will open. Configure the Startup
Settings and the Access Settings.
Startup Settings start the API server when the Security Management Server starts. The
Automatic start setting is selected by default in the following environments:
• Security Management Servers (without gateway functionality) with at least 4GB of

RAM
• Standalone Security Management Servers (with gateway functionality) with at least
8GB of RAM
NOTE
Verify your installation requirements prior to configuring the API
server.
_____________________
_____________________ 301
Access Settings configure IP addresses from which the API server accepts requests. The
Management server only option is selected by default. This option instructs the API server to
accept scripts and web requests only from the Security Management Server. To send an API
request, open a command line interface on the server and use the mgmt_cli utility.
Figure 256 — Configure API Server
To verify that the API server is running, run the following command in Expert mode:
api status
To start the API server, run the following command in Expert mode:
api start
To stop the API server, run the following command in Expert mode:
api stop
_____________________
_____________________ 302
Management API Commands

To type API commands from the SmartConsole GUI, click the command line interface button
located in the bottom left corner to open the Command Line interface window.
Figure 257 — Command Line Interface
Basic API Commands include:
• login
• add
• set
• show
• delete
• publish
• discard
• logout
_____________________
_____________________ 303
In the GUI, scripting begins with a login dialog to receive a session token. A login command
creates a session. User name and password parameters are always required. Here is the syntax
for a login script:
login user <username> password <password> --format json
The output for this example is as follows:
{
“sid” : “97BVpRfN4j8logN-V2XqGYMW3DDwIhoSN0Og8PiKDiM”,
“url” : “https://192.0.2.1:443/web_api”,
“uid” : “7a13a360-9b24-40d7-acd3-5b50247be33e”,
“session-timeout” : 600,
“last-login-was-at” : {
“posix” : 1430032266851,
“iso-8601” : “2015-04-26T10:11+0300”
}
}
NOTE
“--format json” is optional.
The sid string represents the session unique identifier. This identifier is entered in the ‘X-
chkp-sid’ header of each request. The url parameter identifies the URL which was used
to reach the API server. The uid string is the session object identifier. It may be used in
discard API to discard changes that were made in the session, when the administrator is
working from another session.
API commands can be used to create scripts for key security management components,
including:
• Network Objects — Hosts, Networks, Groups, Access Roles

• Services and Applications — Service TCP, Service UDP, Application
• Policy — Install policy, policy package management
• Access Control and NAT — Access rules, NAT rules
• VPN — VPN Community Meshed, VPN Community Star
For example, to create a new host, use the following command:
add host name <New Host Name> ip-address <ip address>
_____________________
_____________________ 304
The mgmt_cli Tool

The mgmt_cli tool uses the same syntax that is used inside the SmartConsole GUI. The only
difference is that when using the tool, for a command to run, you must to provide login
credentials or use a session-id token that was obtained previously using the login command.
The mgmt_cli tool transforms the arguments it receives to RESTful API calls.
The mgmt_cli tool can be run on any Linux or Windows machine. A Linux version of the
command line tool is included in all R80.10 Gaia installations. The executable mgmt_cli is
included in the R80.10 SmartConsole installation. The mgmt_cli.exe does not require a
GUI installation. It can be copied to run on most Windows-based computers.
The following API script example uses the mgmt_cli tool to log in and create a new host:
mgmt_cli login user “AdminUser1” password “teabag” > id.txt

mgmt_cli add host name “New_Host_1” ip-address “1.1.1.1 -s
id.txt
mgmt_cli publish -s id.txt
mgmt_cli logout -s id.txt
In the example above, the output from the login command is redirected to a file called
id.txt. By using the -s parameter, the rest of the commands read id.txt and
automatically extract the session-id from this file.
Users logged in to a management server as Root, can run mgmt_cli commands without
providing their credentials. These are users with Super Administrator permissions. To use this
option, add --root true to the end of the mgmt_cli command.
All mgmt_cli commands can use CSV files for automation purposes as well. For example,
the following command can be used to create multiple host objects from a Microsoft Excel
spreadsheet:
# mgmt_cli add host --batch hosts1.csv
Gaia CLI (Clish)

To run management API commands in Gaia’s shell, you must first log in as a administration
user. The syntax is identical to the commands that you run in the SmartConsole GUI; however,
all management commands begin with the mgmt command. For example: mgmt add host.
_____________________
_____________________ 305
Web Services
Using Web Services to build an application that communicates with the Check Point
management server requires the following components for the web request:
• HTTP Post to — Identifies the management server and port. The default port is 443.
• HTTP Headers — Consists of the content-type, such as application/json, and
the x-chkp-sid header. The x-chkp-sid is the session ID token and is mandatory
in all API calls, except login.
• Request payload — Text containing the different parameters in the specified format
(json or xml).
Management API Support

Check Point Management API utilizes the full potential of the R80.XX Security Management
Server and can be used within any programming environment. To assist you in building
automation tools for your organization, Check Point recommends the following reference
tools.
The Management API Reference Guide

This online guide provides an introduction to Check Point Management API. The guide may
be accessed via the Check Point User Center and the management server (/api_docs).
Figure 258 — Management API Reference Guide
_____________________
_____________________ 306
The Check Point CheckMates Community

Join the Check Point CheckMates community to browse the latest scripts built by experts in the
field, get code samples, network with developers, and access additional API documentation. A
direct link to Check Point CheckMates is located on the Check Point website, or enter this
URL into your browser: https://community.checkpoint.com/
Figure 259 — Check Point CheckMates
L a b 2 .1
Managing Objects Using the Check Point API
_____________________
_____________________ 307
2.1
L
Managing Objects Using  A
the Check Point API B
Check Point’s Application Programming Interface (API) allows administrators to quickly and easily
perform common tasks through a command line interface.
Ta sks :
• Configure the Check Point API.
• Create and edit objects using the Check Point API.
• Demonstrate how to define new network and group objects using the Check Point API.
• Demonstrate how to modify existing objects using the Check Point API.
_____________________
_____________________ 308
Configuring the Check Point API

Activate the API software blade.
1. Select the Manage & Settings tab.

2. Select the Blades icon.
3. In the Blades page, identify the Management API section:
Figure 260 — Management API Settings
_____________________
_____________________ 309
4. Click the Advanced Settings button, and the system displays the following window:
Figure 261 — Management API Advanced Settings
5. Use the information below to confirm the Management API settings:
Startup Settings: Automatic Start

Accept API calls from: Management Server Only
6. Launch a Putty session from A-GUI to A-SMS.

7. Log into the server as admin:
Figure 262 — Putty Session
_____________________
_____________________ 310
8. At the prompt, type the following command and press Enter:
api status
Figure 263 — api status
NOTE
The API should be running by default. If it is not, you can stop and start it using the
following commands:
• api start
• api stop
Check Point recommends restarting the API with the api restart command after
making major changes.
9. Close the Putty session.
_____________________
_____________________ 311
Defining and Editing Objects in the API

Create and edit basic objects through the API.
1. In SmartConsole, click the Command Line icon in the lower left of the screen. The system displays the
following window:
Figure 264 — Command Line
_____________________
_____________________ 312
2. To define a new host from the API, execute the following command:
add host name “myHost1” ip-address 192.168.0.201
Figure 265 — add new host
NOTE
All object names in this lab are case sensitive
_____________________
_____________________ 313
3. To define a new network object, execute the following command:
add network name “myNetwork” subnet 192.168.0.0 subnet-mask 255.255.255.0
Figure 266 — add network name
_____________________
_____________________ 314
4. In the objects panel, verify that the following new objects are now listed:
◦ myHost1
◦ myNetwork
Figure 267 — Objects Panel
_____________________
_____________________ 315
5. From the API, execute the following command:
add group name “myGroup” members myHost1
Figure 268 — add group name
NOTE
This will create a new group object and will include myHost1 a member of
this group.
_____________________
_____________________ 316
add host name "My Test Host" ip-address 192.168.0.111 groups myGroup
Figure 269 — add host name
NOTE
By defining the new object name with surrounding quotation marks, the
system allows the name to include spaces.
_____________________
_____________________ 317
7. To edit an existing object, use the set command:

set host name “myHost1” color "blue"
Figure 270 — set host
_____________________
_____________________ 318
8. To define a group with multiple member objects, execute the following command:
add group name "myGroup1" members.1 "My Test Host" members.2 "A-GUI"
Figure 271 — add group name
9. Close the Command Line window.

10. In SmartConsole, view the myGroup object to view the added member objects:
Figure 272 — myGroup
_____________________
_____________________ 319
11. Click OK.

12. View the myGroup1 object to confirm its member objects:
Figure 273 — myGroup1
13. Click OK.

14. Next, discard all the changes without publishing:
15. Click Discard.
_____________________
_____________________ 320
16. Verify that the objects created in the API are no longer listed in the objects pane:
Figure 275 — Objects Discarded
END OF LAB 2.1
_____________________
_____________________ 321
Review Questions
1. What are the four command sources which allow you to communicate with the manage-
ment server using management API?
2. What does the sid command string identify?
_____________________
_____________________ 322
C
3
H
P
Redundancy T
E
R
Security Gateways can be configured to provide redundancy to prevent network down-

time. The failure of a Security Gateway or VPN connection can result in the loss of active
connections, many of which can be mission critical and result in the loss of critical data.
Whether your preferred network redundancy protocol is Check Point ClusterXL
technology or standard Virtual Routing Redundancy Protocol (VRRP), it is no longer a
platform choice you will have to make with Gaia. Both ClusterXL and VRRP are fully
supported by Gaia. The concept of clustering was introduced in the CCSA course. During
this chapter we will explore clustering in greater detail.
Learning Objectives
• Discuss advanced ClusterXL functions and redundancy.
• Describe VRRP network redundancy and its advantages.
_____________________
_____________________ 323
Advanced ClusterXL
ClusterXL supplies an infrastructure that ensures no data is lost in event of a system failure.
This Check Point cluster solution uses unique physical IP and MAC addresses for its cluster
members and virtual IP addresses to represent the cluster itself. The virtual IP addresses do not
belong to an actual machine interface, and it is recommended that each cluster member have at
least three interfaces: one external interface, one internal interface, and one for
synchronization.
ClusterXL is part of the standard Security Gateway installation and can be configured for Load
Sharing or High Availability mode.
Advantages of Using ClusterXL

Both ClusterXL and VRRP are fully supported by Gaia and available to all Check Point
appliances, open servers and virtualized environments. While both platforms provide the
ability to monitor the state of their clusters, ClusterXL provides more in-depth operational and
monitoring capabilities. For example, when using ClusterXL, System Administrators know
when their cluster has failed over and can also see why it failed over by using the cphaprob
list command. In addition, if an interface goes down, System Administrators can determine
if it is fully down or partially down by using the cphaprob -a if command. They can see
which firewall is currently active, or in the case of Load Sharing, which gateway is carrying
the load and the percentage of the load carried using the cphaprob stat command.
Advantages of using ClusterXL include:
• Tight integration with Check Point management and enforcement points

• Transparent failover
• Higher performance
• Easy deployment
• Cost-effective
Load Sharing
ClusterXL Load Sharing distributes traffic within a cluster so that the total throughput of
multiple members is increased. In Load Sharing clusters, all functioning members are active
and handle network traffic. This is referred to as an Active/Active configuration. Load Sharing
clusters increase linear performance for CPU-intensive applications such as VPNs, security
servers, policy servers, and User Directory (LDAP).
With Load Sharing, if any member of a cluster becomes unreachable, transparent failover
occurs to the remaining operational members in the cluster, thus providing High Availability.
All connections are shared between the remaining Security Gateway, without interruption.
_____________________
_____________________ 324
ClusterXL Load Sharing configurations require all machines to be synchronized, which differs
from High Availability. Machines in a ClusterXL High Availability configuration do not have
to be synchronized, however connections will be lost upon failover if they are not.
ClusterXL offers two different Load Sharing solutions: Multicast and Unicast. These modes
differ in the way members receive the packets sent to the cluster.
Multicast Load Sharing

In ClusterXL Multicast Load Sharing mode, every member of the cluster receives all of the
packets sent to the cluster IP address. The Multicast mechanism allows several interfaces to be
associated with a single Multicast MAC address. Therefore, when a router or Layer 3 switch
forwards packets to all of the cluster members using Multicast mode, a ClusterXL decision
algorithm on the cluster members decides which cluster member should perform enforcement
processing on the packet. Only that machine processes the packet and sends the packet to its
destination. The other machines drop the packet. This decision-making process is the core of
the Multicast Load Sharing mechanism. It has to ensure that at least one member will process
each packet so that the traffic is not blocked, and no two members will handle the same
packets, so that traffic is not duplicated. Only routers or Layer 3 switches that accept a
Multicast MAC address as a response to an ARP request with a Unicast IP address are
supported for Multicast Load Sharing.
Unicast Load Sharing

In ClusterXL Load Sharing Unicast mode, one machine, called the Pivot machine, receives all
traffic from a router with a Unicast configuration and redistributes the packets to the other
machines in the cluster. The Pivot machine is chosen automatically by ClusterXL.
The Pivot is the only machine that communicates with the router. In this scheme, the router
uses the Pivot’s Unicast MAC address to communicate to the cluster. The Pivot functions as a
cluster router, both from the internal network outwards and vice versa. This functionality also
applies to DMZ networks.
After the Pivot first receives the packet from the router or switch, the Pivot’s Load Sharing
decision function decides which cluster member should handle the packet. This decision
function is made in a similar fashion to the Multicast Load Sharing decision. The Pivot may
also decide to handle the packet itself. In such a case, Pivot Load Sharing will give the packet
to the Pivot’s Firewall component for processing. If the Pivot encounters a problem, a regular
failover event occurs and another cluster member assumes the role of the new Pivot. The Pivot
member is always the active member with the highest priority. Therefore, when the original
pivot recovers, it will resume its previous role. The non-pivot members are also active, but do
not make decisions.
_____________________
_____________________ 325
Because the Pivot is busy distributing traffic, the Pivot participates to a lesser extent in the
actual Load Sharing function. The other cluster members take on more traffic load. Since the
Check Point Pivot feature is based on Unicast addresses only, it can work with all routers and
Layer 3 switches. The following diagram and steps outline how a packet travels through a
Unicast Load Sharing cluster.
Figure 276 — Unicast Load Sharing Mode Packet Path
_____________________
_____________________ 326
When the router sends a packet through the cluster, the following occurs:
1. The router sends an ARP request for the cluster IP address.

2. The Pivot returns an ARP reply with its own Unicast MAC address, to the router.
3. The router sends the packet to the Pivot. The Pivot decides which cluster member should
handle the packet.
4. The Pivot forwards the packet to the designated cluster member without changing the
packet. The destination IP address of the packet remains unchanged and neither decryp-
tion nor NAT functionality is performed on the forwarded packet. When sending the
packet, the Pivot uses the virtual MAC address of the designated cluster member. The
packet is forwarded through the original interface.
5. The receiving cluster member performs inspection and sends the packet to its destination.
6. The return packet first reaches the Pivot. The return packet then goes through the same
process although it may not necessarily be forwarded by the Pivot to the same cluster
member.
7. The Pivot assigns the cluster member to handle the packet.
8. The receiving cluster member performs inspection and sends the packet to its destination.
P roxy A R P
Address Resolution Protocol (ARP) is a communications protocol used to map an IP address to
a physical machine address (MAC address) that is recognized by the local network. When a
packet arrives at a gateway, the gateway will ask ARP to find a physical host or MAC address.
ARP will try to locate the address and provide it so that the packet can be converted and sent to
the host machine. An ARP cache table is used to maintain a correlation between each MAC
address and its corresponding IP address. If ARP does not find an entry for the IP address, it
will broadcast a request packet for the MAC address.
By design, in ClusterXL High Availability mode or Load Sharing Unicast/Multicast mode,

Gratuitous ARP request packets for specified hosts, will be sent with the Source IP addresses
of the specified hosts. These requests update the ARP cache tables and do not expect a reply.
Cluster synchronization does not rely on ARP.
Proxy ARP enables a host or router to reply to any ARP requests with its own MAC address. In
many cases the network will configure a gateway to act in proxy as the host. The gateway will
accept the ARP requests and reply with its own MAC address. The Proxy ARP recognizes the
destination of the network traffic and provides its MAC address as the final destination. The
traffic is then routed to the intended destination using another interface or via tunnel. Proxy
ARP is also useful for environments that have NAT’d Firewalls.
_____________________
_____________________ 327
When using static NAT, a cluster can be configured to automatically recognize the hosts hidden
behind it and issue ARP replies with the cluster MAC address, on their behalf. This process is
referred to as Automatic Proxy ARP. If using ClusterXL VMAC mode or different subnets for
the cluster IP, the Proxy ARP must be configured manually.
Configuration for Proxy ARP entails:
1. Configuring Data Link layer to Network layer matching on each cluster member, thus
matching the IP addresses of the relevant hosts on the network where they are located to
the MAC address of the Security Gateway on the network where the IP addresses of these
hosts should be published.
2. Creating relevant Manual NAT rules. The policy must be installed.
Proxy ARP can create denial-of-service (DoS) attacks on a network if mis-configured.
V M AC
Cluster Virtual MAC (VMAC) is a variation of the High Availability (HA) and Load Sharing
Unicast mode for ClusterXL. Upon failover in High Availability/Load Sharing Unicast mode,
a new Active/Pivot member will send Gratuitous-ARP requests (G-ARPs) for the virtual IP
with the physical MAC address of the new Active/Pivot. When this occurs, a member with a
large number of Static NAT entries can transmit too many G-ARPs and network components
may start to ignore them or refrain from updating them fast enough in their ARP cache table.
As a result, traffic outages may occur. Configuring the cluster to use VMAC mode allows all
cluster members to use the same Virtual MAC address and minimizes possible traffic outages
during a failover. In addition, G-ARPs for NAT’d IP addresses are no longer needed.
VMAC that is advertised by the cluster members through G-ARP requests, keeps the real
MAC address of each member and adds another VMAC address on top of it. Keeping the real
MAC address of each member is necessary in that connectivity to the IP address of the member
itself is required. VMAC failover time is shorter than a failover that involves a physical MAC
address.
_____________________
_____________________ 328
Configuring VMAC
VMAC can be configured via SmartConsole or CLI. To configure VMAC via SmartConsole,
select the cluster object and navigate to the Gateway Cluster Properties window. Select the
ClusterXL and VRRP menu option, and then enable the Use Virtual MAC option located under
the Advanced Settings section.
Figure 277 — Gateway Cluster Properties - Use Virtual MAC
To configure VMAC using the command line, you must first set the value of the global kernel
parameter, fwha_vmac_global_param_enabled to 1. (The default value is 0. The
default value means that VMAC is disabled).
To ensure that VMAC mode is enabled, run the following command on all members:
fw ctl get int fwha_vmac_global_param_enabled
If the value returned is 1, the feature is enabled. If not enabled, use the following command:
fw ctl set int fwha_vmac_global_param_enabled
_____________________
_____________________ 329
To view the VMAC address of each virtual cluster interface, run the following command:
cphaprob -a if
C l u s ter S y n c h ro n i z a t i o n
To make sure each Gateway cluster member is aware of the connections going through the
other members, a mechanism called State Synchronization exists, which allows status
information about connections on the Security Gateways to be shared between the members.
State Synchronization enables all machines in the cluster to be aware of the connections
passing through each of the other machines. It ensures that if there is a failure in a cluster
member, connections that were handled by the failed machine will be maintained by the other
machines. Since the synchronization network carries the most sensitive Security Policy
information in the organization, it is critical that system engineers protect it against malicious
and unintentional threats. Check Point recommends using one of the following strategies to
secure the synchronization interfaces:
• Use a dedicated synchronization network.

• Connect the physical network interfaces of the cluster members directly using a cross-
cable. In a cluster with three or more members, use a dedicated hub or switch.
Every IP-based service, including TCP and UDP, recognized by the Security Gateway is
synchronized. State Synchronization is used both by ClusterXL and by third-party OPSEC
Certified clustering products. State Synchronization works in the following two modes:
• Full Synchronization — Transfers all Firewall kernel table information from one
cluster member to another. Full synchronization is used for initial transfers of state
information for thousands of connections. If a cluster member is brought up after
failing, it will perform full sync. Once all members are synchronized, only updates are
transferred via delta sync. Full synchronization between cluster members is handled by
the Firewall kernel using TCP port 256.
• Delta Synchronization — Transfers changes in the kernel tables between cluster
members. Delta sync is much quicker than full sync. It is handled by the Firewall
kernel, using UDP Multicast or Broadcast on port 8116.
Running cphastart on a cluster member activates ClusterXL on the member is the

recommended way to start a cluster member. It does not initiate full synchronization.
cphamcset turns off the cluster process. State Synchronization also stops. It is still possible
to open connections directly to the cluster member. These commands should only be run by the
Security Gateway, not directly by the user.
To monitor the synchronization mechanism on ClusterXL or third-party OPSEC Certified

clustering products, run the following command:
fw ctl pstat
_____________________
_____________________ 330
Synchronized Cluster Restrictions

The following restrictions apply to synchronizing cluster members:
• Only cluster members running on the same platform can be synchronized.
• The cluster members must be of the same software version.
• With CoreXL enabled, the number of cores must be the same.
• A user-authenticated connection through a cluster member will be lost if the cluster
member fails. This is because the user-authentication state is maintained by a process
on the Security Gateway and it cannot be synchronized on members the same way that
kernel data is synchronized. All other synchronized cluster members will be unable to
resume the connection. However, a client-authenticated or session-authenticated
connection will be maintained, because the states of these authentications are saved in
kernel tables and can be synchronized.
• The state of connections using system resources cannot be synchronized for the same
reason that user-authenticated connections cannot be synchronized.
• Accounting information is accumulated on each cluster member and sent to the
Security Management Server, where the information is aggregated. In case of a failover,
accounting information that was accumulated on the failed member but not yet reported
to the Security Management Server is lost. To minimize the risk, reduce the period in
which accounting information is sent. Navigate to the cluster object’s Logs >
Additional Logging window, and edit the number of seconds to update the Account
Log.
To Synchronize or Not to Synchronize

In general, all connections on a cluster are synchronized between members. There are a few
exceptions. System engineers may choose not to synchronize certain types of connections for a
variety of reasons, such as:
• A significant load on the network is caused by the use of a particular service.

• A service may open many short connections, whose loss may not be very important, or
even noticed. For example, DNS over UDP or HTTP.
• Bi-directional stickiness is employed for all connections. For example, any cluster in
High Availability mode or ClusterXL in a Load Sharing mode with no VPN or static
NAT. Sticky connections are discussed later in this chapter.
For all TCP services whose protocol type is HTTP or None, you can configure the Security
Gateway to delay a connection so that it will only be synchronized if it still exists after the
connection is initiated for x seconds. This capability is only available if a SecureXL-enabled
device is installed on the gateway. SecureXL is discussed in greater detail in a later chapter.
_____________________
_____________________ 331
C l u s ter C o n n e c t i v i t y U p g ra d e
There are several methods available for upgrading ClusterXL deployments. The simplest
method is to upgrade each cluster member as an independent gateway, but this will cause
system downtime. Other methods involve at least one Active member or two cluster members
handling traffic during the upgrade. With these methods, connections that are initiated during
or after the upgrade process could possibly be dropped.
The Connectivity Upgrade (CU) method synchronizes existing connections to maintain

connectivity and eliminate downtime during cluster upgrades. In a Cluster Connectivity
Upgrade, there is always at least one Active cluster member that handles the traffic, and
connection failover is guaranteed. Connections are even synchronized between cluster
members running different Check Point software versions. Using CU, cluster members can be
upgraded to Check Point software versions R77.20 and above. For more detailed information
regarding software versions that support CU, refer to the Check Point Connectivity Upgrade
Administration Guide.
NOTE
Cluster CU supports Dynamic Routing synchronization when upgrading to
R80.10.
Before upgrading with CU, it is important to make sure that the cluster has 2 or more members,
with one member Active and all other members in Standby mode. The state of a cluster
member can be checked by running the cphaprob state command. When the upgrade is
complete, a message will display the upgrade status as ready for failover. At this point, the
CCP will work in broadcast mode. To return it to multicast mode, on all cluster members, run
the cphaconf set_ccp multicast command.
If error messages are displayed in the connectivity upgrade script, discontinue the upgrade and
contact Check Point Support.
There are several features that do not survive after failover to an upgraded cluster member
when using CU. These features include, but are not limited to the following:
• General failover limitations such as Security servers, and connections handled by

services marked as non-synced
• Connections initiated by individual cluster members
• TCP connections that are TCP streamed
• VPN connections for Mobile Access, Remote Access, and Traditional VPN mode
• FTP control connections with NAT
• Sessions authenticated with Identity Awareness
• DLP connections
_____________________
_____________________ 332
In addition, Software Blade information is not synchronized during failover to an upgraded

cluster member. If the blade is configured to maintain connectivity over security, the
connection will be accepted without inspection and forwarded to the destination member.
However if the destination member is not available, the connection will be dropped. For
additional limitations related to a general failover, refer to the Check Point ClusterXL
Administration Guide.
A d d a M e m b e r to a n E x i s t i n g C l u s te r
ClusterXL can support up to eight cluster members. To add a member to an existing cluster:
1. Run cpconfig to enable ClusterXL on the cluster member.

2. Change the IP address of the new cluster member to reflect the correct topology.
3. Ensure that all Check Point products are installed on the new cluster member. All Check
Point software components must be identical on each member of the cluster.
4. In the Cluster Members page of the cluster object, create a new cluster member with the
appropriate properties if the Security Gateway is new, or convert an existing gateway to a
cluster member. If the member is a new Security Gateway, ensure that SIC is initialized
and the topology is correctly defined.
5. Ensure that the proper interfaces on the new cluster member are configured as cluster
interfaces if the cluster mode is Load Sharing or New High Availability.
6. Install the Security Policy on the cluster. The new member is now part of the cluster.
Sticky Connections
A connection is sticky when all of its packets are handled, in either direction, by a single
cluster member. This is the case in High Availability mode, where all connections are routed
through the same cluster member.
In Load Sharing mode, there are cases where it is necessary to ensure that a connection that
starts on a specific cluster member will continue to be processed by the same cluster member
in both directions. To that end, certain connections can be made sticky by enabling the Sticky
Decision Function (SDF).
In a non-sticky connection, the reply packet returns via a different Security Gateway than the
original packet. The synchronization mechanism knows how to properly handle these
connections. In a non-sticky connection, a cluster member can receive an out-of-state packet,
which the Security Gateway normally drops because it poses a security risk. In Load Sharing
cluster configurations, Static NAT and encrypted connections may be non-sticky when the
source and destination IP addresses change. Non-sticky connections will also occur if the
System Administrator has configured asymmetric routing, where a reply packet returns
through a different Security Gateway than the original packet. Asymmetric routing occurs
when a packet is NAT’d or encrypted.
_____________________
_____________________ 333
The Sticky Decision Function

The SDF is required in cases of Asymmetric Routing. In these cases, the packet is modified by
the cluster member, and since the packet entering the Firewall is not the same as the one
leaving, the regular decision function will not be able to make sure that the packet will go back
through the original member. The SDF will try to match each packet to numerous kernel tables
in an attempt to decide which member should handle the packet.
The SDF enables certain services to operate in a Load Sharing deployment. For example, it is
required for Layer 2 Tunneling Protocol (L2TP) traffic, or when the cluster is a participant in a
Site-to-Site VPN tunnel with a third-party peer.
The following services and connection types are supported by enabling the SDF:
• VPN deployments with third-party VPN peers

• Endpoint Connect/SSL Network Extender encrypted connections
The SDF is not supported when employing either acceleration technologies, such as SecureXL
and CoreXL, or a hardware-based accelerator card. Enabling the SDF disables these
acceleration products.
M a n a g e m e n t H i g h Ava i l a b i l i t y
The Security Management Server consists of several databases with information on different
aspects of the system, such as objects, users, and policy information. This data changes each
time the System Administrator makes modifications to the system. It is important to maintain a
copy of this data so that crucial information is not permanently lost in the event of an Security
Management Server failure.
Moreover, if the management server fails or is down for administrative purposes, a secondary
server must be in place to take over its activities. In the absence of the Security Management
Server, essential operations performed by the gateways, such as the fetching of the Security
Policy and the retrieval of the Certificate Retrieval List (CRL), cannot take place. Installing a
secondary Security Management Server and deploying Management High Availability (HA)
provides Security Management Server redundancy.
In a Management High Availability environment, the Active Security Management Server,

which is specified as the Primary, always has one or more standby management servers ready
to take over in the event of a failure. The Standby Security Management Servers must all be of
the same operating system and version. The existence of the Standby Security Management
Server allows for crucial backups to be in place. When a Standby Security Management Server
is installed, configure and specify it as Secondary. Initially, the Primary and Secondary
Security Management Servers must be manually synchronized. If additional Standby servers
are installed, configure automatic synchronization in the Global Properties.
_____________________
_____________________ 334
Once the Secondary Security Management Server has been installed and manually
synchronized, the Primary and Secondary are both prepared to function as the Active Security
Management Server.
Secondary and Standby Security Management Servers

The Secondary Security Management Server is created with empty databases that are filled
with information that it receives from the Active Security Management Server. The Secondary
Security Management Server is ready when:
• It is represented on the Primary Security Management Server as a network object.

• SIC has been initialized between it and the Primary Security Management Server.
• Synchronization has been completed with the Primary Security Management Server for
the first time.
In a situation where the Primary Security Management Server becomes permanently

unavailable, it is not sufficient to do the failover procedure and change the Standby server to
Active. The Secondary server must be promoted to Primary, or a new Primary must be
established. The database can only be exported from a Primary server.
All management operations, such as editing and installing the Security Policy and modifying
users and objects, are done by the Active Security Management Server. If the Active server is
down and any of these operations need to be performed, the Secondary or one of the Standby
Security Management Servers should be made active by the System Administrator. This
transition from Standby to Active must be initiated manually.
The Standby servers are synchronized to the Active server so they are kept up-to-date with all
changes in the databases and Security Policy. Security Gateways can fetch the Security Policy
and retrieve a CRL from both the Active and the Standby servers.
Security Management Server Failover

Security Management Server failover is a manual procedure. If the Active Security
Management Server fails or it is necessary to change the Active to Standby, the following steps
must be taken to prevent data loss.
If the Active Security Management Server is responsive:
1. Manually synchronize the Active and Standby Security Management Servers.

2. Change the Active Security Management Server to Standby.
3. Change the Standby Security Management Server to Active.
_____________________
_____________________ 335
If the Active Security Management Server has failed and is unresponsive to changes, manually
change the Standby Security Management Server to Active. Make sure that no peer server is
Active before making the change.
NOTE
If two Security Management Servers are set to Active at the same time,
unexpected behavior can occur.
Before making changes to the High Availability environment, make sure that the status of each
Security Management Server is known.
Synchronizing Management HA Active and Standby Servers

Synchronization can be performed manually or automatically. Manual synchronization is a
process initialized by the System Administrator. It can be set to synchronize databases and the
installed Security Policy. After Standby servers are installed, the first synchronization must be
performed manually even if the system is configured for automatic synchronization.
Automatic synchronization is configured by the System Administrator to allow the Standby

Security Management Server to be synchronized with the Active Security Management Server
at set intervals. This is the standard mode of synchronization because it keeps the Standby
Security Management Server updated. The synchronization schedule is based on when the
Security Policy is installed, which can be set to every time the policy is saved or on a set
scheduled time, such as daily at 2:00 AM. It is always possible to synchronize manually, even
when automatic synchronization has been selected.
When synchronization is in progress, all databases are locked, and a snapshot of the databases
are saved to a local disk. The system then compresses the snapshot data and copies the
snapshot from the Active Security Management Server to all Standby management servers.
The Standby servers will overwrite their databases with the snapshot and send a Restore status
notification to the Active Security Management Server.
For Management HA to function properly, the following data is backed up and synchronized:
• Network Security Management Databases (such as the Network Objects, policy settings,
and the Security Policy itself)
• Configuration and Internal Certificate Authority (ICA) data (such as Objects and Users
databases, certificate information, and the CRL, which is available to be fetched by the
Check Point Security Gateways)
• Endpoint Security databases, if applicable
_____________________
_____________________ 336
Synchronization Status
The synchronization status indicates the status of the peer Security Management Server in
relation to that of the selected Security Management Server. This status can be viewed in the
Management High Availability window or in SmartView Monitor, depending on whether you
are connected to the Active or Standby Security Management Server. The following statuses
may be displayed:
• Never been synchronized — Immediately after the Secondary Security Management

Server has been installed, it has not yet undergone the first manual synchronization that
brings it up-to-date with the Primary Security Management Server.
• Synchronized — The peer is properly synchronized and has the same database
information and installed Security Policy.
• Lagging — The peer Security Management Server has not been synchronized since the
Active Security Management Server had changes applied to it.
• Advanced — The peer Security Management Server is more up-to-date.
• Collision — The Active Security Management Server and its peer have different
installed policies and/or databases. The System Administrator must perform manual
synchronization and decide which of the servers to overwrite. For example, when
Security Management Server-A fails before a synchronization takes place, the changes
made to databases or to the Security Policy cannot be synchronized with Security
Management Server-B. When Security Management Server-B takes over from Security
Management Server-A, the System Administrator may decide to modify the Security
Policy.
Synchronization Troubleshooting
Synchronization can fail for technical reasons, such as when the Active Security Management
Server does not connect with the Standby Security Management Server. To resolve issues such
as this, perform one of the following actions:
• Manually synchronize the Standby Security Management Server.

• Install the Security Policy on the Active Security Management Server again. Use this
option if automatic synchronization is configured. Once the policy is re-installed, the
synchronization should occur automatically.
_____________________
_____________________ 337
Synchronization can also fail if a collision occurs. In this case the System Administrator
should manually synchronize the servers and choose which database is the dominant database.
The CA is merged to prevent security issues. If a collision occurs between the servers, and one
of the Security Management Servers is overwritten, use the Audit Logs to better understand the
situation. Review the management operations which were recently performed on the
overwritten server and perform them again, on the dominant server, if necessary.
O P S E C C e r ti f i e d C l u s ter i n g P ro d u c t s
Products that carry the OPSEC Certified seal have been tested to guarantee integration and
interoperability with Check Point software and hardware platforms. There are a number of
OPSEC Certified High Availability and Load Sharing products which are used to configure
HA Security Gateway clusters and to distribute traffic evenly among the clustered gateways.
These clustering applications vary in monitoring, management, and performance capabilities.
Their role however, is the same in that they each:
1. Decide which cluster member will deal with each connection.

2. Perform health checks, which involves checking cluster member status (Active, Standby
or Down) and member interface status.
3. Perform failover.
As with ClusterXL, OPSEC Certified clustering products use Check Point State
Synchronization to exchange and update connection data and other Security Gateway states
between cluster members.
L a b 3 .1
Deploying a Secondary Security Management Server
_____________________
_____________________ 338
3.1
L
Deploying a Secondary 
A
Security Management Server
B
You will now configure a secondary Security Management Server and install it at the Alpha site for full
Management High-Availability.
Ta sks :
• Install a secondary Security Management Server at the Alpha site.
• Configure Alpha’s secondary Security Management Server for High Availability.
• Test Management High Availability.
• Install and Configure Management High Availability.
_____________________
_____________________ 339
Installing the Secondary Management Server

Configure the secondary Security Management Server for Alpha.
1. Verify that your instructor has pre-installed the secondary SMS at the Alpha site.
NOTE
If the instructor has not previously installed the secondary SMS, perform the
installation and configure the new machine to match the hardware settings (Hard
Disk size, RAM allotment, etc.) of the primary SMS. The log partition should be at
least 30 GB. It’s IP address should be 10.1.1.102/24 and it’s default gateway should
be 10.1.1.1. Only the default admin user is needed and should be configured with
Chkp!234 as the password.
2. A-GUI, connect to the newly installed server (10.1.1.102) through HTTPS.

3. Log into the Gaia Portal using the following credentials:
Username: admin
Password: Chkp!234
4. Begin the First Time Configuration wizard for A-SMS-02.
_____________________
_____________________ 340
5. Use the following information to configure the Device Information page:
Host Name: A-SMS-02

Primary DNS Server: 192.168.11.101
Figure 278 — Device Information
6. Configure the NTP server to be:
192.168.21.101
7. On the Products page, clear the Security Gateway option.

8. Select only the Security Management option.
_____________________
_____________________ 341
9. In the Clustering section, select Secondary from the Define Security Management as drop-down list:
Figure 279 — Products
NOTE
It is important to define this server as secondary prior to establishing SIC.
10. Click Next.

11. Enter and confirm sic123 as the Activation Key.
12. Click the Finish button, and begin the configuration process.
_____________________
_____________________ 342
13. In the Messages page, add the following text:
A-SMS-02
14. Click Apply.

15. Sign out of the Gaia Portal.
_____________________
_____________________ 343
Configuring Management High Availability

Configure the secondary Security Management Server for Management High Availability functions.
1. On A-GUI, launch SmartConsole and log into A-SMS (10.1.1.101).

2. In the Objects pane, click New > More > Network Object > Gateways and Servers > Check Point Host.
Figure 281 — Objects Pane Menu
3. Use the information below to configure the Check Point Host:
Name: A-SMS-02
IPv4 Address: 10.1.1.102
Comment: Alpha Secondary Security Management Server
_____________________
_____________________ 344
4. In the Management tab of the Host object, select Network Policy Management.
NOTE
By default, the system selects the Secondary Server and Logging & Status options.
5. Verify that the A-SMS-02 object is configured as follows:
Figure 282 — Check Point Host
_____________________
_____________________ 345
6. Click on the communication button and establish SIC with the server, using the following activation
key:
sic123
7. Select the option Don’t show this message again.

9. Click OK to close the object.
10. Publish the changes, and the system begins initialization of A-SMS-02:
Figure 283 — Peer Initialization
_____________________
_____________________ 346
11. After the secondary SMS is initialized, the system automatically beings the full synchronization
process:
Figure 284 — Full Sync Task Details
_____________________
_____________________ 347
12. Click the Menu icon to view the Application Menu:
Figure 285 — Application Menu
13. Select Management High Availability, and the system displays the following window:
Figure 286 — High Availability Status
_____________________
_____________________ 348
14. Confirm that the synchronization completed successfully.

15. Close the status window.
_____________________
_____________________ 349
Testing Management High Availability

View the Alpha Security Policy on the secondary SMS to verify High Availability functionality.
1. From SmartConsole, click Application Menu > Management High Availability to view the
synchronization status:
Figure 287 — Management High Availability status
NOTE
If you get a synchronization error, wait a minute, and try again.
2. Close all other SmartConsole applications that may be open at this time.
NOTE
The only application running should be the one initiating the synchronization. If
other applications are open, the change action will fail.
3. In the Status window, click the Actions button associated with A-SMS.
_____________________
_____________________ 350
4. Click Set Standby, and the system displays the following message:
6. Click OK to close SmartConsole.

7. Re-launch SmartConsole and use the information below to connect to the secondary Security
Management Server:
Username: admin
Password: Chkp!234
NOTE
If you are unable to log into A-SMS-02 and receive an “Internal Error,” Reboot 
A-SMS and wait five minutes after the reboot completes before attempting to log
into A-SMS-02.
_____________________
_____________________ 351
8. Click Login, and approve the fingerprint message to continue:
Figure 290 — Fingerprint
9. Click Proceed, and SmartConsole displays the Gateways & Servers tab of A-SMS-02:
_____________________
_____________________ 352
10. Click the Application Menu.

11. Select Management High Availability, and the system displays the status screen showing A-SMS-02
set to Standby:
12. In the A-SMS-02 section, click Actions > Set Active, and the system displays the following message:
_____________________
_____________________ 353
13. Click Yes, and the system displays the following window:
14. After the change over completes, the system displays the following message:
15. Click OK.

16. Verify that the High Availability Status window confirms a successful changeover:
_____________________
_____________________ 354
17. Close SmartConsole.

18. Log into SmartConsole, connecting to A-SMS-02 (10.1.1.102):
_____________________
_____________________ 355
19. Verify policy synchronization:
Figure 298 — Full Sync Task Details
NOTE
Wait for the full sync to complete before proceeding to the next step. Check the
synchronization status by viewing the Recent Tasks list in the lower left corner of
SmartConsole.
_____________________
_____________________ 356
20. Next, use the information below to configure a new Host object:
Name: Test
Comment: Management HA Test Object
Color: Pink
IP Address: 192.168.0.201
Figure 299 — New Host Configured
_____________________
_____________________ 357
21. Publish and install the Alpha Security Policy.
_____________________
_____________________ 358
22. Verify successful policy installation from A-SMS-02:
23. From the application menu, select Management High Availability:
24. In the A-SMS-02 section of the window, click the Actions button.
_____________________
_____________________ 359
25. Click Set Standby, and the system displays the following message:
26. Click OK, and the system switches A-SMS-02 to standby.
27. Click OK, to close SmartConsole.
_____________________
_____________________ 360
28. Next, log into A-SMS:
Figure 305 — SmartConsole Login
NOTE
Verify that you are logging into A-SMS (10.1.1.101) before continuing.
_____________________
_____________________ 361
29. Once connected to A-SMS, view the list of Host objects to see the new Test object exists:
Figure 306 — Test Object Confirmation
30. Click the Application Menu.

31. Select Management High Availability, and the system displays the status screen showing A-SMS set to
Standby:
_____________________
_____________________ 362
32. In the A-SMS section, click Actions > Set Active, and the system displays the following message:
33. Click Yes, and the system displays the following window:
34. Click OK.

35. Confirm that A-SMS shows a status of Active:
36. Publish any changes to the database and close SmartConsole.

37. Open SmartConsole again, this time connecting to 10.1.1.101. The Management High Availability
Status window shows A-SMS as Active and A-SMS-02 as Standby.
_____________________
_____________________ 363
38. Publish and install the Alpha_Standard Security Policy.
NOTE
If your environment is not fully functional, contact your instructor for assistance. Do
not proceed if your configuration has problems.
39. Once the primary server is shown as active and synchronized, power off the secondary Security
Management Server.
NOTE
Make sure that all synchronization and policy installation events are completed
before powering off A-SMS-02.
40. Delete the A-SMS-02 object.

END OF LAB 3.1
_____________________
_____________________ 364
VRRP Clusters
Virtual Routing Redundancy Protocol (VRRP) and ClusterXL are mutually exclusive. VRRP
is a network management protocol that is used to increase the availability of default gateway
servicing hosts on the same subnet. It improves the reliability and performance of the host
network by enabling a virtual router to act as the default gateway for that network.
VRRP enables you to set up a group of routers as a default gateway router for backup or
redundancy. As a cluster solution, it makes the group of physical routers appear as a single
virtual router, allowing hosts to configure the virtual router as their default gateway. The
VRRP routing platforms share the IP address corresponding to the default route configured on
the hosts. Similarly to ClusterXL, one of the VRRP routing platforms is the Master (active)
and the others are backups (standby). If the Master fails, one of the backup routers becomes the
new Master router, providing a virtual default gateway and enabling traffic to be routed
without relying on the failed router. A priority algorithm is used to determine if failover to a
backup is necessary, when the Master or its interfaces fails. VRRP increases redundancy,
making it significantly beneficial in situations where the availability of the default path for
network hosts is critical. It can be implemented in Ethernet, multi-protocol label switching,
and token ring networks.
As with ClusterXL, VRRP clusters can be configured for High Availability. Each VRRP
cluster, known as a virtual router, has a unique Virtual Router Identifier (VRID).The VRID is a
number used to group the routers. A virtual router can have one or more virtual IP (VIP)
addresses to which other network nodes connect as a final destination or the next hop in a
route. Only the Master is assigned a VIP. The backup is assigned a VIP upon failover when it
becomes the Master. Check Point’s implementation of VRRP includes additional functionality
called Monitored Circuit VRRP. Monitored Circuit VRRP prevents black holes caused by
asymmetric routes created when only one interface on the Master router fails, as opposed to the
Master itself. Gaia releases priority over all interfaces on a virtual router to let failover occur.
NOTE
You cannot have a standalone deployment in a Gaia VRRP cluster.
_____________________
_____________________ 365
VRRP Features
VRRP is specifically designed to enable data routing, forwarding, and switching among a pool
of virtual routers. When using VRRP, a higher availability default path is gained without
requiring the configuration of dynamic routing or router discovery protocols on every host.
While there are methods such as Proxy ARP that can help clients find their default router,
many security engineers simply configure a static route to a single router on each client
because it is easier. However, if the single router goes down, the client will be unable to reach
other networks.
VRRP features include:
• Minimized failover time and bandwidth overhead when a primary router becomes
unavailable
• Support of up to 255 virtual routers on a router physical interface, subject to the
platform supporting multiple MAC addresses
• Minimized service disruptions during failover
• Provision for election of multiple virtual routers on a network for Load Sharing
• No need to make configuration changes in the end nodes if a gateway router fails
• Router discovery protocols to support failover operations is no longer required
• Failover problems are addressed at the router level instead of on the network edge
• Functionality over a wide variety of multi-access LAN technologies capable of
supporting IP traffic
V R R P Typ e s
VRRP can be configured using one of these types:
• Simple Monitored Circuit VRRP — This configuration contains all of the basic
parameters and is applicable for most environments. Each virtual router is configured
as one unit.
• Advanced VRRP — This procedure requires users to manually configure a virtual
router for each monitored interface. Use Advanced VRRP if you are working with:
◦ A system on which VRRP has already been configured using this method.
◦ An environment where it is necessary to monitor each interface individually.
◦ The preempt VMAC mode.
Simple Monitored Circuit VRRP and Advanced VRRP cannot be used together on the same
Security Gateway.
_____________________
_____________________ 366
Monitored Circuit VRRP

Monitored Circuit VRRP is a functionality included in the Check Point VRRP implementation.
It eliminates connection issues caused by asymmetric routes when only one interface on the
Master fails, as opposed to the entire platform. This problem occurs in environments where a
gateway is a member of two or more virtual routers, typically one with internal interfaces and
the other with external interfaces. For example, when an external interface fails or becomes
unreachable, the Master fails over to the backup for the external virtual router while the
internal virtual router stays on the Master. This can cause connectivity issues when the internal
virtual router accepts traffic and is unable to connect to the new external Master.
Simple Monitored Circuit VRRP monitors all VRRP interfaces on the Security Gateways.
When using Advanced VRRP, each interface in a virtual router can be configured separately. If
one interface fails, the Master releases its priority over all of its VRRP interfaces. This allows
the Master to fail over on all virtual routers that include the failed Master.
To release priority, Gaia subtracts the Priority Delta, a Check Point proprietary parameter
which is defined when the virtual router is configured, from the Priority Value to calculate an
Effective Priority. If configured properly, the Effective Priority will be lower than that of the
backup routers in the other virtual routers and the VRRP election protocol is triggered to select
a new Master. If the Effective Priority for the current Master and backup are the same, the
gateway with the highest IP address becomes the Master.
Security Policies
Security policies must be configured to accept VRRP packets on the Gaia platform if it is a
Firewall blade-enabled Security Gateway. The Multicast destination assigned by the Internet
Assigned Numbers Authority (IANA) for VRRP is 224.0.0.18. If the policy does not accept
packets to 224.0.0.18, Firewall platforms in one Virtual Router take on Master state. If your
Security Gateways use dynamic routing protocols such as OSPRF or RIP, create new rules for
each multicast destination IP address.
_____________________
_____________________ 367
Advanced VRRP
Advanced VRRP allows virtual routers to be configured at the interface level. Every virtual
router must be configured to monitor every VRRP interface. Advanced VRRP can be changed
to Simple Monitored Circuit VRRP by deleting all existing virtual routers and creating new
ones. When changing, it is important to understand that a backup address cannot be moved
from one interface to another while a Security Gateway is a Master. The following steps are
performed to delete and add new interfaces with the necessary IP addresses:
1. Cause a failover to the backup.

2. Reduce the priority or disconnect an interface.
3. Delete the virtual router on the interface.
4. Create a new virtual router using the new IP address.
5. Configure the virtual router.
Advanced VRRP can be configured via WebUI or CLI. Use set and show commands to
configure global and advanced VRRP settings via CLI, such as:
set vrrp interface VALUE

show vrrp interface VALUE
_____________________
_____________________ 368
VRRP Configuration Parameters

Regardless of the type of VRRP method used, VRRP configuration parameters must be
defined and configured on each node. The values for each parameter are described in the table
below.
VRID Range is 1- 255. Choose a numbering scheme for the virtual routers
that will make sense to your organization.
Priority Range is 1 - 254. The default value is 100. The priority value
determines which router takes over in the event of a failure. The router
with the higher priority becomes the new master. To provide a faster
transition is the event of a failure, set the priority to 254 for at least
one platform in each VRID, and choose values on the higher end of
the scale for the backups. Effective Priority = Priority - the Priority
Delta.
Priority Delta This parameter applies only to Monitored Circuit VRRP. Check Point
recommends using a standard priority delta, such as 10, to simplify
configuration. Choose a value that will ensure that when an interface
fails, the priority delta subtracted from the priority results in an
effective priority that is lower than that of all of the backup routers.
Hello Interval Range is 1 - 255 seconds. The default setting is 1 second. The Hello
Interval is the time interval in seconds at which the master sends
VRRP advertisements. Set the same value for all nodes in the VRID.
Authentication Choose to require no authentication for VRRP advertisements or to
require a simple password before a VRRP advertisement is accepted
by the interface. Select the same authentication method for all nodes
in the VRID.
Backup Address This parameter applies only to Monitored Circuit VRRP. The backup
(Virtual IP Address) address must be in the same network as the interface used for the
VRID. When entered, the system will use the interface that is in that
subnet for the VRID.
Table 7: VRRP Configuration Parameters
Lab 3.2
Enabling Check Point VRRP
_____________________
_____________________ 369
3.2
L
Enabling Check Point VRRP A
B
In this lab, you will add Check Point VRRP to your ClusterXL deployment to add additional functionality
and reliability.
Ta sks :
• Define a virtual router for the VRRP configuration.
• Configure the Bravo Security Policy to allow VRRP traffic between cluster members.
• Demonstrate how to configure VRRP as the failover method for a Security Gateway Cluster.
_____________________
_____________________ 370
Viewing ClusterXL Failover

Before deploying VRRP, review the behavior of a Cluster deploying only ClusterXL.
1. Log into B-GW-01.

2. Type the following command and press Enter, to identify the status of the Bravo cluster:
cphaprob stat
Figure 311 — cphaprob stat
3. Identify the Active cluster member.
_____________________
_____________________ 371
4. Next, review the synchronization status of each interface configured in the Bravo cluster by executing
the following command:
cphaprob -a if
Figure 312 — cphaprob -a if
_____________________
_____________________ 372
5. On the Active cluster member, force failover by clearing the following option on Network Adapter 2
(Internal Interface):
Connected
Figure 313 — Internal Interface Manipulated
6. Click OK.
_____________________
_____________________ 373
7. On the system disconnected in the steps above, review the state of the interfaces by executing the
following command:
cphaprob -a if
Figure 314 — cphaprob -a if
8. Next, confirm that the member gateways have failed over:
cphaprob stat
9. Reconnect Network Adapter 2 on the system that was disconnected in the steps above.
_____________________
_____________________ 374
Defining a Virtual Router for VRRP

Use the Gaia Portal to reconfigure both Security Gateways in preparation for switching to a VRRP fail-
over solution.
1. From A-GUI, use HTTPS to connect to B-GW-01 (203.0.113.102)

2. Log in using the following credentials and the system displays the Overview page:
Username: admin
Password: Chkp!234
_____________________
_____________________ 375
3. In the navigation pane, click Network Interfaces:
4. Make a note of the following IP addresses associated with the interfaces on this machine.
eth1: ____________________
eth2: ____________________
eth3:_____________________
NOTE
Remember, the synchronization network for our configuration is 192.168.20.0. That
makes eth2 our sync interface.
_____________________
_____________________ 376
5. In the navigation pane, locate the High Availability section.

6. Click VRRP, to view the following page:
Figure 318 — VRRP
_____________________
_____________________ 377
7. In the Virtual Routers section, click Add:
Figure 319 — Add Virtual Router
8. In the Virtual Router ID field, type 1.
_____________________
_____________________ 378
9. Verify that the Virtual Router is configured with the following information:
Virtual Router ID: 1

Priority: 100
Priority Delta: 10
Hello Interval: 1
Preempt Mode: Selected
Auto-deactivation: Unchecked
Authentication: None
Figure 320 — Add Virtual Router Configured
NOTE
The Priority and Delta values determine how the system fails over. In this scenario,
we have two gateways, the first with a priority of 100 and the second with a priority
of 95. If the first gateway fails, it’s priority changes to 90 and the second gateway
with the higher priority (95) takes over.
_____________________
_____________________ 379
10. In the Backup Address section of the window, click Add.

11. Enter the cluster IP address (203.0.113.100) and select VRRP for the mode:
Figure 321 — Add Backup Address Configured
12. Click OK.

13. Next add the following backup address, with VMAC Mode of VRRP, for the internal interface:
192.168.21.1
14. Verify that the Add Virtual Router window is configured as follows:
_____________________
_____________________ 380
15. Click Save, and the system adds the Virtual Router to the configuration:
Figure 323 — VRRP - Virtual Router Configured
NOTE
Since eth2 is the sync interface, it should not have a cluster IP address.
16. Log out of the Gaia Portal for B-GW-01.
_____________________
_____________________ 381
17. Use HTTPS to log into the Gaia Portal for B-GW-02 (203.0.113.103).
18. From the Overview page, make a note of the interfaces configured for B-GW-02:
19. Make a note of the IP addresses associated with the following interfaces on this machine.
eth1: ____________________
eth2: ____________________
eth3: ____________________
NOTE
Remember, the synchronization network for our configuration is 192.168.1.0. That
makes eth3 our sync interface.
20. Navigate to the VRRP page and add a Virtual Router.
_____________________
_____________________ 382
21. Use the information below to configure the Virtual Router settings:
Virtual Router ID: 1

Priority: 95
Priority Delta: 10
Hello Interval: 1
Preempt Mode: Selected
Auto-deactivation: Unchecked
Authentication: None
Backup Addresses: 203.0.113.100
192.168.21.1
_____________________
_____________________ 383
22. Verify that the new Virtual Router is configured as follows:
NOTE
To work, the priority of this gateway must be higher than the diminished priority of
the gateway we just configured (100 - 90 < 95).
_____________________
_____________________ 384
23. Click Save, and the system displays the Virtual Router in the VRRP page:
Figure 326 — VRRP
NOTE
The Virtual Router ID must be the same, 1 in our configuration, for all gateways in
the cluster.
24. Sign out of this session.
_____________________
_____________________ 385
25. Log into the B-GW-01 virtual machine, and type the following command:
cpconfig
26. View the configuration options:
27. Verify that item number six reads as follows:
Disable cluster membership for this gateway
NOTE
If item six reads Enable cluster membership for this gateway, type 6 and press Enter.
If not, this feature is already configured, so continue to the next step.
28. Exit cpconfig.

29. After exiting cpconfig, reboot the virtual machine and save the configuration.
30. Repeat steps 25-29 for B-GW-02.
_____________________
_____________________ 386
Configuring the Security Policy for VRRP

In a previous lab, you defined a cluster object for use in the Bravo ClusterXL configuration. Confirm the
cluster configuration and modify the object to work with VRRP High Availability.
1. In SmartConsole, edit the B-GW-Cluster object.

2. Select Network Management, and verify that the interfaces are configured as follows:
Figure 328 — Gateway Cluster Properties - Topology Configured
_____________________
_____________________ 387
3. Select General Properties, and verify that the object’s OS is defined as “Gaia”.
4. In the Network Security tab, clear the ClusterXL option:
Figure 329 — Gateway Cluster Properties - General Properties Configured
_____________________
_____________________ 388
5. In the navigation pane, click 3rd Party Configuration.

6. Select High Availability for the Cluster Mode.
7. In the 3rd Party Solution drop-down list, select Check Point IPSO VRRP:
Figure 330 — 3rd Party Configuration
8. Verify that the following options are selected:

◦ Hide Cluster Members’ outgoing traffic behind the Cluster IP Address
◦ Forward Cluster’s incoming traffic to Cluster Members’ IP Addresses
9. Click OK.
10. View the Bravo Security Policy.
_____________________
_____________________ 389
11. Create a new rule below the Noise rule.

12. Use the following information to configure the new rule to allow VRRP traffic between cluster
members:
Name: VRRP
Source: B-GW-Cluster
Destination: Any
Service: VRRP
Action: Accept
Track: Log
Figure 331 — VRRP Traffic Rule
13. Publish and install the Bravo Security Policy.
_____________________
_____________________ 390
14. In the Gateways & Servers tab of SmartConsole, view the B-GW-Cluster object:
_____________________
_____________________ 391
15. Click the Device & License Information link for B-GW-01:
16. Confirm that the ClusterXL section displays the following Working Mode status:
Sync only (OPSEC)
_____________________
_____________________ 392
17. Click the ClusterXL arrow to view more specific information.

18. Confirm that both Security Gateways in the cluster show the Working Mode for ClusterXL as Sync
only (OPSEC):
NOTE
The Sync only status indicates that the VRRP Virtual Router is controlling failover.
_____________________
_____________________ 393
19. In Clish on each gateway, perform the cphaprob stat command. Both gateways should show as
Active and the system should display a Cluster Mode of sync only (OPSEC):
NOTE
The status of both gateways show all interfaces as Active. This just means that the
“heartbeat” between the interfaces indicates that both are servers are up and
available.
_____________________
_____________________ 394
20. To check the status of the VRRP configuration, type the following command and press Enter:
show vrrp
Figure 336 — show vrrp
NOTE
Here, you’ll see the behavior of VRRP. For example, we see two interfaces
configured. On this machine, all two are in the Master state. The other router should
show two in the backup state.
21. Initiate an FTP session from A-GUI to B-Host and transfer an ISO or other large file. During the data
transfer, force down one of the gateways to see the failover take place.
NOTE
You can also failover individual interfaces. Try this by initiating the FTP transfer
again, but this time, change the LAN setting of the External interface to be LAN X.
When you run the show vrrp command on the secondary machine, the status will
show one master and one backup.
END OF LAB 3.2
_____________________
_____________________ 395
Review Questions
1. What happens when the Sticky Decision Function (SDF) is enabled?
2. Describe what a cluster VMAC is and how it works.
_____________________
_____________________ 396
C
4
H
P
Acceleration T
E
R
Check Point provides two software-based acceleration features to optimize performance:

SecureXL and CoreXL. SecureXL is a software acceleration product installed on Security
Gateways, to create a SecureXL device layer. The Check Point Security Gateway enables
security decisions to be made at this lower application level to remove performance
bottlenecks. CoreXL is a performance-enhancing technology for Security Gateways on
multi-CPU-core processing platforms. When enabled, CoreXL empowers the processing
CPU cores to simultaneously perform multiple tasks, which enhances Security Gateway
performance without requiring changes to management or to network topology. This
chapter also introduces Multi-Queue, which allows each network interface to use more
than one CPU for acceleration.
Learning Objectives
• Understand how SecureXL acceleration technology enhances and optimizes Security Gateway
performance.
• Understand how CoreXL acceleration technology enhances and improves Security Gateway
performance.
_____________________
_____________________ 397
SecureXL: Security Acceleration

SecureXL is a patented Check Point security acceleration technology that accelerates multiple,
intensive security operations, including operations carried out by Check Point’s Stateful
Inspection Firewall. When enabled on a Security Gateway, some CPU-intensive operations are
processed by virtualized software instead of the Firewall kernel. Using SecureXL, the Firewall
can inspect and process connections more efficiently by offloading operations to performance-
optimized software or hardware devices, dramatically increasing throughput without
compromising security. SecureXL is included in Gaia and does not require an additional
license.
Figure 337 — Traffic Flow With and Without SecureXL
Using SecureXL
SecureXL accelerates packet processing performance by remembering certain attributes of
packets and packet flows that have already been validated by the blades. Validation of related
packets and connections is then delegated to the SecureXL API, which enables offloading of
security processing to optimized processing units. This validation is done at the hardware
interrupt level on x86 hardware, or supervises execution of further optimized code in IP
security appliances that support them. Both of these approaches involve substantially less
computing overhead than is required by the Security Gateway.
_____________________
_____________________ 398
From SecureXL’s perspective, there are three paths of traffic flow:
• Firewall Path — Packets and connections that are inspected by the Firewall. These
packets and connections are not processed by SecureXL. This path is also referred to as
the Slow Path.
• Accelerated Path — Packets and connections that are offloaded from the Firewall to
SecureXL. These packets and connections are quickly processed.
• Medium Path — Packets that cannot use the accelerated path because they require
deeper inspection. Although it is not necessary for the Firewall to inspect these packets,
they can be offloaded by another feature. For example, packets that are examined by
IPS cannot use the accelerated path and can be offloaded to the IPS Passive Streaming
Library (PSL), which provides stream reassembly for TCP connections. As a result,
SecureXL processes these packets quicker than packets on the slow path.
SecureXL’s purpose is to minimize connections that are processed on a slow path and
accelerate the connection rate. As a connection is being established, if a packet is examined
using traditional security methods and is determined to be safe, the SecureXL device layer
takes over responsibility for examining any remaining packets to reduce latency. SecureXL
can be implemented at both a hardware layer, such Gaia-based appliances or at a virtual
software layer on open servers.
Pa c ket A c c e l e r a t i o n
Packet acceleration, which is also referred to as throughput acceleration, identifies connections
by five attributes:
• Source address
• Destination address
• Source port
• Destination port
• Protocol
When the packets in a connection match all five attributes, the traffic flow can be processed on
the accelerated path. However, only packets during the specific TCP/UDP connection can be
accelerated.
Packets attempting to establish a new TCP connection, or a comparable UDP connection table
entry in the Firewall, are handled in the slow path because they require more processing. Once
the first packet is seen by the Firewall and suitable connection information is offloaded to an
appliance operating system, further packets are handled at the operating system's interrupt-
level code.
SecureXL improves non-encrypted Firewall traffic throughput and encrypted (VPN) traffic
throughput by a significant amount, particularly for small packets flowing in long duration
connections.
_____________________
_____________________ 399
There are several factors that preclude a packet from being accelerated, such as:
• The ClusterXL Sticky Decision Function (SDF) feature is enabled

• The first packet of any new TCP or UDP session, unless a template exists
• Connections destined to or originating from the Security Gateway
• Connections that require Security servers (Authentication, Antivirus, URL Filtering,
Anti-Spam, DNS protocol enforcement)
• Connections that have a Handler (ICMP, FTP, H.323, etc.)
• Some IPS features (IP, ID, TTL)
• Multicast packets
S e s s i o n R a te A c c e l e r a t i o n
SecureXL also reduces the overhead in establishing certain kinds of new connections,
improving new connection rate (connections per second), connection setup/tear-down rate
(sessions per second), and throughput in certain high-connection rate traffic environments.
The principle involved is a simple extension of SecureXL’s approach to one-time validation of

a Firewall flow. The one-time validation is extended from a particular 5-attributes to a range,
or block, of one or more of these attributes. This means that to accelerate the rate of new
connections, connections that do not match a specified 5-attributes are still processed by
SecureXL.
As an example, the source port of a packet flow may be masked off, effectively providing a
global match for source port. Once a flow is validated and established, SecureXL creates and
saves a template of that flow with the source port masked off. Any new connection setup
packet that matches the other 4 attributes is processed on the accelerated path, thus avoiding
Firewall inspection and additional computing overhead. Security is not impacted because the
operating system continues to track the state of the new connection using Stateful Inspection.
_____________________
_____________________ 400
Masking the Source Port

To examine how ports are used in establishing TCP connections, consider the following
scenario. A client requesting a connection to a server initiates the TCP three-way handshake.
The client addresses the server, typically at a well-known port number depending on the
service provided by the server, such as port 23 for Telnet or port 80 for HTTP. Together the
server’s IP address and the well-known port number form a socket address. The client assigns
and pairs an OS-selected port number with the client’s IP address to create a socket address for
the reverse direction.
Figure 338 — Port Connections
Application Layer Protocol - An HTTP Example

Consider higher-level application protocols that involve numerous TCP connections between
the client and server, either simultaneously (in parallel), sequentially, or both. HTTP, which
accounts for most Internet traffic, is one of these protocols. HTTP generates most of the new
connection requests in enterprise and Internet traffic.
Web pages consist of multiple HTTP components, text, and perhaps dozens of graphic
elements. Using HTTP, each component is downloaded from server to client using a separate
TCP connection. This action involves substantial overhead in connection setup and tear-down
and in protective-Firewall connection tracking (Firewalls at both ends).
_____________________
_____________________ 401
In all cases between a web client and a web server, TCP connection establishment is initiated
by the web client, which then sends an HTTP request. The web server responds by sending the
HTTP component:
• HTTP Request (->) — Each of the packets from the web client that requests an HTTP
component from the web server has the same source address, destination address,
destination port (80), and protocol (HTTP). Only the source port, assigned (one per
connection) by the web client's operation system, differs to create unique socket
addresses at the client for each HTTP request/component (via separate TCP
connections for each component).
• HTTP Component (<-) — Going the other direction, each of the packets from the
web server that build the web page components on the web client has the same source
address, destination address, source port (80), and protocol (HTTP). Only the
destination port differs (it's been assigned by the client operating system to that
connection).
Once a connection involving a flow to port 80 is approved by the Firewall for the web client
(resulting from the first HTTP request), a template is created and stored. All subsequent
connection setups carrying those additional requests can share that same template approval,
because it’s okay that the source ports differ. Establishing those subsequent connections does
not involve a round trip to the Firewall, resulting in faster processing through the server
Firewall.
Similarly, at the client Firewall, once a connection involving a flow to port 80 is approved by
the Firewall (as above), all subsequent connections carrying these additional requests can share
that same approval. Establishing those subsequent connections does not involve a round-trip to
the Firewall. SecureXL accelerates subsequent connections through both Firewalls when
multiple connections share the same source address, destination address, destination port, and
protocol.
S e c u r e X L C o n n e c t i o n Tem p l a tes
SecureXL connection templates create the opportunity to generate extremely impressive
connection rate performance. Given the benefit of connection templates in heavy HTTP
environments, the significant performance increase can be reflected in real-world traffic
settings, such as in web server farms and enterprises where there is a great deal of web traffic
to a small, concentrated set of servers.
_____________________
_____________________ 402
To accelerate the rate of connection establishment, SecureXL groups all connections that
match a particular service and whose sole differentiating element is the source port. This type
of grouping enables even the very first packets of a TCP handshake to be accelerated. The first
packets of the first connection on the same service will be forwarded to the Firewall kernel,
which will then create a template of the connection. SecureXL has three different templates:
• Accept Templates — Created when a connection is established by matching a new

connection to a particular set of tuple attributes. Subsequent connections are established
without performing a rule match and are therefore accelerated. Accept templates are
enabled by default and generated from active connections according to policy rules.
Accept template acceleration is only on connections with the same destination port.
• Drop Templates — Generated by policy rules to accelerate the speed at which a
connection is dropped by matching a new connection to a set of tuple attributes.
Subsequent connections are dropped without performing a rule match and are therefore
accelerated. Drop template acceleration is also performed only on connections with the
same destination port. These templates are disabled by default. Drop templates are
discussed in greater detail in the CCSM course.
• NAT Templates — Generated to achieve high session rate for NAT. These templates
are supported in cluster HA/VRRP and Load Sharing modes. NAT templates are
controlled by global kernel parameters and disabled by default. NAT templates are
discussed in greater detail in the CCSM course.
Factors that Preclude Templating

There are factors that can preclude templating if all other parameters are met for packet
acceleration, such as:
• Source port ranges

• IPS features not supported in Acceleration
• NAT’d traffic, unless NAT templates are enabled
• Encrypted connections
Once templating is disabled in the Rule Base, all connections matching rules lower in the Rule
Base cannot be templated. Use fwaccel stat to determine at which rule templating is
disabled and move the most used rules above that rule to take advantage of session
acceleration.
_____________________
_____________________ 403
Pa c ket F l ow
The figure below shows the decision logic for packets flowing through SecureXL accelerated
IP security appliances.
Figure 339 — Packet Flow Decision Logic
A new packet arrives at the Inbound interface. The packet is checked against the Connections
table, which mirrors the Firewall’s Connections table. If there is a 5-tuple match, the new
packet is part of an existing flow and is forwarded to the Outbound interface for handling
(forward, drop, or reject). This path involves the least amount of forwarding overhead and
accelerates throughput for packets that are part of an existing flow.
If the new packet does not match an entry in the Connections table, it represents a new flow
and requires a new Connections table entry. However, if the packet matches an existing
connection template, then the new Connections table entry can be created (based on
information in the connection template table entry) without a round trip to the Firewall
application. The packet is then forwarded to the Outbound interface for handling. This path
reduces the overhead involved in creating a new connection table entry and accelerates the
connection rate for new connections that match existing connection templates.
If the new packet does not match an existing connection template, then a round trip to the
Firewall application is required in order to apply the Security Policy. This path involves the
greatest overhead.
_____________________
_____________________ 404
VPN Capabilities
SecureXL adds VPN routing capabilities and enhances connectivity to support VPN in
dynamic routing environments.
VPN Link Selection

VPN Link Selection allows multiple external interfaces to be configured for tunneling the VPN
packets. It allows the Firewall to create, maintain, and update a table of Link Selection entries.
The Firewall can specify which link needs to be used for a given Security Association. If that
link goes down, the Firewall can update the Link Selection entries to start using a different link
for the same tunnel.
Dynamic VPN Routing

Dynamic VPN routing allows the VPN domain to be determined dynamically instead of
configuring a static VPN domain. With Dynamic VPN routing enabled, connections can
transition from clear text to encrypted or from encrypted to clear text, based on the route taken
by the connection. The connection properties adapt to the route changes between an external
interface (untrusted) and an internal (trusted) interface by communicating in encrypted or clear
text respectively.
Wire Mode Connections

Wire Mode Connections allow trusted traffic to pass through without Stateful Inspection. If an
internal interface and the VPN Community are configured as wired (trusted), then the traffic
passing through the internal interface and getting encrypted using the VPN Community will
skip any Stateful Inspection. This increases the connectivity speed at lower security for traffic
between wired interfaces and a wired VPN Community.
L a b 4 .1
Working with SecureXL
_____________________
_____________________ 405
4.1
L
Working with SecureXL A
B
In this lab you will learn methods of troubleshooting SecureXL, Check Point’s method of accelerating
traffic through a Security Gateway.
Ta sks :
• Use fwaccel to review the current configuration.
• Use fwaccel to identify acceleration.
• Demonstrate how fwaccel affects traffic flow.
• Review the status of traffic acceleration on a Check Point Security Gateway.
_____________________
_____________________ 406
Identifying Status of Current Connections

Use the fwaccel command to identify if acceleration is currently deployed for connections in your
environment.
1. Log into A-GW-01.

2. In Clish, type the following command and press Enter:
cpconfig
3. Verify that item number 9 shows the following:
Disable Check Point SecureXL
4. Exit cpconfig.
5. In Clish, type the following and press Enter:
fwaccel stat
Figure 340 — fwaccel stat
NOTE
The fwaccel stat command shows you if acceleration is enabled or disabled.
_____________________
_____________________ 407
6. Verify that the Accelerator Status is displayed as On and that Accept Templates is Enabled.
NOTE
If acceleration is not enabled, execute the following command: fwaccel on
fwaccel stats -s
Figure 341 — fwaccel stats
NOTE
By adding the -s filter, the system displays a summary of connections accelerated
versus those that are not.
8. From B-Host, use FTP to connect to A-DMZ (203.0.113.171).
_____________________
_____________________ 408
fwaccel conns
Figure 342 — fwaccel conns
NOTE
The fwaccel conns command identifies existing connections in SecureXL. By
adding the -s filter, the system would display the number of connections handled by
SecureXL.
10. Consider the following questions:

◦ What are the most frequent source and destination IP addresses?
◦ What flags to you see and what do they indicate?
◦ What does the C2S and S2C columns indicate?
_____________________
_____________________ 409
11. Press the Shift button and use the Page Up and Page Down buttons to navigate the data.
Figure 343 — fwaccel conns

◦ Can you identify the FTP connection from A-GUI to B-Client?
◦ Is the connection accelerated?
_____________________
_____________________ 410
13. Launch CPView to identify the numbers of current connections:
Figure 344 — CPView
14. Exit CPView.

fw tab -t cphwd_db -s
Figure 345 — fw tab -t cphwd_db -s
NOTE
This command displays the kernel table for SecureXL.
_____________________
_____________________ 411
fw tab -t connections -u -s

◦ What information does the fw tab function provide?
◦ Can you identify the FTP connection from this information?
◦ Can you tell if it is accelerated?
END OF LAB 4.1
_____________________
_____________________ 412
CoreXL: Multicore Acceleration

As the first security technology to fully leverage general purpose multi-core processors,
CoreXL introduces advanced, core-level load balancing that increases throughput for the deep
inspection required to achieve intrusion prevention and high throughput. With CoreXL, high
performance and high security can be achieved simultaneously. Like SecureXL, CoreXL is
also included with the Gaia operating system and does not require additional licensing.
Figure 346 — CoreXL Configuration for Machine with Eight CPU Cores
Using CoreXL
Multi-core CPU support enables Check Point Security Gateways to share traffic among cores
of a single system, providing superior performance on a single server. The combination of
multi-core CPUs and multi-threaded SecureXL security application technology is the
foundation for the next generation of security acceleration: Application layer security. By
joining a multi-core CPU with SecureXL security acceleration, Security Gateways can deliver
more than 10 Gbps of Intrusion Prevention throughput.
_____________________
_____________________ 413
Using CoreXL, the Firewall kernel is replicated multiple times. Each replicated copy, or
instance, of the Firewall kernel runs on one processing core. The instances handle traffic
concurrently, and each instance is a complete and independent inspection kernel. Regarding
network topology, management configuration, and Security Policies, a CoreXL gateway
functions as a regular Security Gateway. All of the kernel instances of a gateway handle traffic
going through the same interfaces and apply the same Security Policy. Traffic entering
Network Interface Cards (NIC) is directed to a processing CPU core running the Secure
Network Distributor (SND), which will distribute non-accelerated packets among the Firewall
kernel instances and securely accelerate packets authorized to be processed using SecureXL.
CoreXL acts as a load balancer and improves Security Gateway performance in situations
where much of the traffic cannot be accelerated by SecureXL or when the gateway has many
IPS features enabled, which disables SecureXL functionality. It also improves performance for
gateways with a large Rule Base and NAT rules. CoreXL does not benefit the gateway when
the traffic consists mostly of VPN or VoIP traffic.
CoreXL is not supported when one of the following features is enabled:
• VPN Traditional mode

• Overlapping NAT
Configuring CoreXL
CoreXL is enabled or disabled using cpconfig and requires a reboot to take effect. When
enabled, enter the number of Firewall kernel instances for the gateway. The default number of
kernel instances is derived from the total number of cores in the system, as described in the
following table:
Number of Cores Number of Kernel Instances

1 CoreXL is disabled
2 2
4 3
6 - 20 (Number of CPU cores) - 2
More than 20 (Number of CPU cores) - 4
No more than 40 total.

Table 8: Kernel Instances Configuration
_____________________
_____________________ 414
If using CoreXL with ClusterXL, the number of kernel instances must be identical on all
members of the cluster. This is because State Synchronization between cluster members is
performed per CoreXL Firewall kernel instance. For example, Instance #2 on cluster member
A can only synchronize with Instance #2 on cluster member B.
Figure 347 — CoreXL and ClusterXL Example
P ro c e s s i n g C o r e A l l o c a t i o n
The CoreXL software architecture includes the Secure Network Distributor. The SND is
responsible for processing incoming traffic from the network interfaces, securely accelerating
authorized packets (if SecureXL is running), and distributing non-accelerated packets among
kernel instances. In other words, the SND is essentially a CPU core running both SecureXL
and CoreXL.
Traffic entering the NIC is directed to a processing core running the SND. The association of a
particular interface with a processing core is called the interface's affinity with that core.
Affinity is a general term used to describe binding NIC interrupts to processors. Affinity
settings for all interfaces are set automatically by default when the CoreXL architecture
includes processing incoming traffic from NICs. This affinity causes the interface's traffic to be
directed to that core and the SND to run on that core. Setting a kernel instance or a process to
run on a particular core is called the instance's, or process's, affinity with that core. Traffic from
all NICs is directed to the core running the SND.
_____________________
_____________________ 415
The default affinity setting for all interfaces is automatic. If SecureXL is running, the affinity
for each interface is automatically reset every 60 seconds and balanced between available
cores. If SecureXL is not running, the default affinities of all interfaces are with one available
core. In both cases, any processing core running a kernel instance, or defined as the affinity for
another process, is considered unavailable and will not be set as the affinity for any interface.
In some cases, SND cores can be overloaded due to high traffic on multiple interfaces assigned
to the same SND core. Manual sim affinity can alleviate this symptom. Use the sim
affinity -l command to see affinity distribution. Each busy interface should be assigned
its own Interrupt ReQuest (IRQ) value and distributed among SND cores. The assignment of
interfaces to IRQs can be verified in the /proc/interrupts file.
In some cases, it may be advisable to change the distribution of kernel instances, the SND, and
other processes among the processing cores. This is done by changing the affinities of different
NICs and/or processes. However, to ensure CoreXL’s efficiency, all interface traffic must be
directed to cores not running kernel instances. Therefore, changing affinities of interfaces or
other processes will require resetting the number of kernel instances and ensuring that the
instances run on other processing cores.
Under normal circumstances, it is not recommended for the SND and an instance to share a
core. However, it is necessary for the SND and an instance to share a core when using a
machine with exactly two cores.
Adding Processing Cores to the Hardware

Increasing the number of processing cores on the hardware platform does not automatically
increase the number of kernel instances. If the number of kernel instances is not increased,
CoreXL does not utilize some of the processing cores. After upgrading the hardware, increase
the number of kernel instances using cpconfig.
Reinstalling the Security Gateway will change the number of kernel instances if you have
upgraded the hardware to an increased number of processing cores, or if the number of
processing cores stays the same but the number of kernel instances was manually changed
from the default.
In a clustered deployment, changing the number of kernel instances, such as by reinstalling

CoreXL, should be treated as a version upgrade. Follow the instructions in the Upgrade Guide
and perform either a Minimal Effort Upgrade using network downtime or a Zero Downtime
Upgrade, substituting the instance number change for the version upgrade in the procedure. A
Full Connectivity Upgrade cannot be performed when changing the number of kernel instances
in a clustered environment.
_____________________
_____________________ 416
Allocating an Additional Core to the SND

In some cases, the default configuration of instances and the SND will not be optimal. If the
SND is slowing the traffic and your platform contains enough cores that you can afford to
reduce the number of kernel instances, you may want to allocate an additional core to the SND.
This is likely to occur, especially if much of the traffic is accelerated by SecureXL, in a
ClusterXL Load Sharing deployment or if IPS features are disabled. In any of these cases, the
task load of the SND may be disproportionate to that of the kernel instances.
NOTE
Check Point recommends that your platform have at least 8 CPU cores to
allocate an additional core to the SND.
Allocating a Core for Heavy Logging

If the Security Gateway is performing heavy logging, it may be advisable to allocate a
processing core to the fwd daemon, which performs the logging. Like adding a core for the
SND, this too will reduce the number of cores available for kernel instances.
Dynamic Dispatcher
Dynamic Dispatcher is a CoreXL feature which helps to improve load distribution and
mitigates connectivity issues during traffic peaks. Without Dynamic Dispatcher, new
connections to a CoreXL Firewall instance are fixed or statically assigned, based on packet IP
addresses and IP protocol type. This static assignment may result in situations where one or
more instances would handle more connections or perform more processing on the packets
forwarded to them than the others, which may cause the load to become unbalanced across the
CPU cores. In addition, during peak times and policy installation, an overloaded core may
cause traffic to be delayed or dropped.
When Dynamic Dispatcher is enabled, connections to CoreXL instances are dynamically

assigned, based on utilization of the CPU cores. Dynamic Dispatcher will distribute the load
equally between the CPU cores. Connections opened at a higher rate that would have been
assigned to the same instance by a static decision are now distributed to several instances.
The Dynamic Dispatcher feature is enabled by default in R80.10. When enabled, the dynamic
assignment decision is made for the first packets of connections by assigning a rank to each of
the instances and selecting the instance with the lowest rank. The ranking of each instance is
calculated according to the CPU utilization of the instance. If the CPU utilization of an
instance is high, the ranking for that instance will be high as well. Higher ranked instances are
less likely to be selected by the SND.
_____________________
_____________________ 417
When to Enable Dynamic Dispatcher

Dynamic Dispatcher is most beneficial in environments with a large number of CPU cores and
when the CPU load is not properly balanced. Enable Dynamic Dispatcher if the following
thresholds or situations occur:
• A CoreXL instance consumes its CPU core at ≥ 85%, even for one second.
• Other CoreXL instances consume their CPU cores at 75% and below. The difference in
CPU consumption between overloaded and normally loaded instances is 10% or more.
• Traffic is dropped or delayed due to an overloaded core during traffic peaks or during
policy installation.
When Dynamic Dispatcher is enabled, connections are always assigned dynamically, even in
cases where there is no significant differences in CPU load, with the exception of VoIP and
VPN encrypted packets. These two types of traffic will always be handled by the same
Firewall instance. The distribution of connections across all CoreXL Firewall instances can be
checked using the fw ctl multik stat command. Checking the connections will allow
you to monitor the current connections and ultimately decide whether or not to enable the
Dynamic Dispatcher feature. To fully enable Dynamic Dispatcher on a Security Gateway, run
the following command in Expert mode and then reboot:
fw ctl multik dynamic_dispatching on
Firewall Priority Queues

Firewall Priority Queues prioritize traffic when the CPU cores on the Firewall are 100%
utilized and packets need to be dropped. This feature is disabled by default in R80.10. When
enabled, the priority queues are only active when the CPU is overloaded. When the Firewall is
fully utilized, packet loss can occur regardless of the connection’s type (for example, SSH and
DHCP connections).
_____________________
_____________________ 418
Priority Queues prioritize the packets based on the type of connection, and each connection of
the same priority will get an equal share of the CPU resources. There are 8 priority queues by
default, and up to 8 additional queues can be manually configured. When a new packet arrives,
the connection is classified in order to know which queue it is assigned to. For example,
packets of a SSH connection will go to the Control queue.
Queue Queue Name Type of Connections Can

Priority Connections
Migrate?
(0 - highest)
0 Routing DHCP, VRRP, OSPF, BGP, No
IGMP, PIM
1 Control GUI/SSH/Ports 18xxx/ Yes
Management services
2 Cluster Sync Local/Full sync No
3 High Priority User Defined Yes
4 Light Data Queue Light connections Yes
5 Default Data Queue Medium weight connection or Yes
new connection
6 Log Notification Log and Drop notifications No
7 Heavy Data Queue Heavy connections Yes
Table 9: Default Priority Queues
Some connection types can be migrated between priority queues to be assigned a lower or
higher priority with respect to other connections. For example, a new connection begins its life
in the Default Data queue (Queue #5). If this connection gets lighter, it will migrate to a higher
priority queue, such as the Light Data queue (Queue #4). If the connection becomes heavier, it
can migrate to a lower priority queue, such as the Heavy Data queue (Queue #7). The Firewall
will decide whether or not the connection should be migrated, based on the load time of an
average connection of that type. It knows to how many possible queues the connection was
assigned to and the CPU load caused by this connection.
To enable Dynamic Dispatcher on a Security Gateway without the Firewall Priority Queues,
run the following command in Expert mode and reboot:
fw ctl multik prioq 2
_____________________
_____________________ 419
Pa c ket F l ow w i t h C o r e X L a n d S e c u r e X L E n a b l e d
The following image depicts packet flow through the Security Gateway with CoreXL and
SecureXL is enabled:
Figure 348 — Packet Flow through Security Gateway
Acceleration Path
The packet is completely handled by the SecureXL device. It is processed and sent back to the
network.
Medium Path
The packet is handled by the SecureXL device, except for IPS, Application Control, Antivirus,
and Anti-Bot processing. The CoreXL layer passes the packet to one of the Firewall instances
to perform processing. This path is only available when CoreXL is enabled.
Firewall Path
The SecureXL device is unable to process the packet. It is passed to the CoreXL layer and then
to one of the instances for full processing on the slow path.
_____________________
_____________________ 420
Multiple Traffic Queues

As mentioned before, the SND is a processing core which accelerates traffic from network
interfaces using SecureXL and distributes non-accelerated packets among instances using
CoreXL. The number of CPUs allocated to the SND is limited by the number of network
interfaces handling the traffic. By default, each NIC has one traffic queue that is handled by
one CPU. Therefore, users cannot use more CPU cores for acceleration than the number of
interfaces handling traffic. Multi-Queue is an acceleration feature that will allow you to
configure more than one traffic queue for each NIC, to use more CPU cores for acceleration.
U s i n g M ul t i - Q u e u e
When most network traffic is being accelerated, the CPU load for SND can be very high, while
the CPU load for CoreXL Firewall instances are very low. This results in an inefficient
utilization of CPU capacity. Using Multi-Queue to configure more than one traffic queue for
each supported network interface helps balance the load efficiently between SND CPUs and
CoreXL instance CPUs.
Check Point does not recommend assigning both a SND and a CoreXL instance to the same
CPU core. Multi-Queue does not enhance Firewall performance in situations such as when all
Firewall instances are highly loaded and most of the traffic is being processed in CoreXL’s
slow or medium paths, or in cases where all CPU cores that are used by SecureXL are
congested. In addition, Multi-Queue does not help when IPS, or other deep inspection
Software Blades are heavily used.
Configuring Multi-Queue
Check Point recommends configuring Multi-Queue when the following conditions are
presented:
• The CPU load for SND is high (idle is < 20%).

• The CPU load for CoreXL instances is low (idle is > 50%).
• There are no CPU cores left to be assigned to the SND by changing interface affinity.
NOTE
The Interrupt ReQuest (IRQ) affinity of the queues is set automatically
when the operating system boots. Manually changing the IRQ affinity of
the queues can adversely affect performance.
_____________________
_____________________ 421
Use the following guidelines to help determine if your network can benefit from configuring
Multi-Queues:
• Make sure that both SecureXL and CoreXL are enabled.

• Make sure that the network interfaces support Multi-Queue.
• Examine the CPU affinity to see how the CPU roles are allocated for interfaces (SND)
and for CoreXL instances. To see the CPU roles allocation, run the following
command:
fw ctl affinity -l
Figure 349 — fw ctl affinity -1
• Examine the CPU utilization for usage and idle percentages. On the Security Gateway
run top and then press 1 to toggle to the SMP view.
Figure 350 — CPU Utilization Example
• Determine if more CPU cores can be allocated to the SND. If there are more network
interfaces handling traffic than CPUs assigned to the SND, more CPUs can be allocated
for SND.
_____________________
_____________________ 422
Use the following command to configure Multi-Queue on supported interfaces:
cpmq set
The command will display all supported interfaces that are active and allow changes to be
made to the Multi-Queue configuration for each interface. It is important to reboot the gateway
after changing the Multi-Queue configuration. A maximum of five interfaces can be
configured.
The following command shows the Multi-Queue status of supported interfaces:
cpmq get
Lab 4.2
Working with CoreXL
_____________________
_____________________ 423
4.2
L
Working with CoreXL A
B
Check Point CoreXL accelerates traffic through the Firewall by assigning each of the system’s cores to
specific kernels. In this lab, you will learn how to enable and configure CoreXL.
Ta sks :
• Enable CoreXL.
• Configure CoreXL.
• Demonstrate how multiple system cores can be used by CoreXL to accelerate traffic.
• Identify how to review the status of CoreXL on a Security Gateway.
_____________________
_____________________ 424
Enabling CoreXL
Configure CoreXL so that the system can accelerate traffic though the firewall by assigning specific
kernels to each of the system’s cores.
1. From A-GW-01, type the following and press Enter:
cphaprob stat
NOTE
One of the cluster members should show a status of “Active” and the other should
show “Standby.”
_____________________
_____________________ 425
2. Check the status of CoreXL. Type the following and press Enter:
fw ctl multik stat
Figure 352 — fw ctl multik stat
3. From Expert Mode, shutdown the A-GW-01 Virtual Machine:
shutdown -P now
Figure 353 — shutdown -P now
_____________________
_____________________ 426
4. Modify the A-GW-01 virtual machine so that it is configured with at least four cores.
Figure 354 — Virtual Machine Settings - Processors
NOTE
The labs environment shown in this document is based on VWware Workstation.
Your classroom environment may be different. If it is, ask your instructor for
assistance.
_____________________
_____________________ 427
5. Reboot the modified cluster member.

top
7. Press 1 to see the CPU distribution.
Figure 355 — top
8. Identify the number of cores listed at the top of the screen.

9. Press q to exit the file.
_____________________
_____________________ 428
cpview
Figure 356 — cpview
11. Compare the number of cores listed on the CPView Overview page to the number displayed in top.
12. Click q, to exit CPView.
_____________________
_____________________ 429
13. On A-GW-01, type the following and press Enter:
cpconfig
NOTE
If the Check Point CoreXL option does not appear in the list of Configuration
Options, your virtual machine is not configured with multiple cores.
14. Enable Check Point CoreXL, if it is not already enabled.
_____________________
_____________________ 430
fw ctl affinity -l
Figure 358 — fw ctl affinity -l
NOTE
Though there are four cores configured for this machine, only three are kernel
instances. This chart explains the core to kernel instance ratio:
Number of Cores Number of Kernel Instances

1 1
2 2
4 3
6-20 Number of cores -2
More than 20 Number of cores -4 but no more than 40
_____________________
_____________________ 431
fw ctl affinity -l -a -v
Figure 359 — fw ctl affinity -l -a -v
_____________________
_____________________ 432
Reviewing CoreXL Settings

Review the CoreXL settings in your environment.
top
2. Type q to quit.
3. In Expert mode, type the following and press Enter:
ps -ef | grep fw_worker
Figure 360 — ps -ef | grep fw_worker
_____________________
_____________________ 433
4. At the prompt, type the following:
cat /proc/interrupts
Figure 361 — cat /proc/interrupts
END OF LAB 4.2
_____________________
_____________________ 434
Review Questions
1. Describe the three paths of traffic flow for SecureXL.
2. How does CoreXL improve network performance?
3. When should you consider using Multi-Queue?
_____________________
_____________________ 435
C
5
H
P
SmartEvent T
E
R
Check Point’s SmartEvent Software Blade turns log entries into meaningful security
information. It correlates log events, aggregates data, and identifies potential attack
patterns from various devices. It prioritizes security events among a multitude of logging
activities in the network, making it easy for Cyber Security Administrators to remediate
and prevent critical events. With its customizable graphical reports and intuitive GUI,
administrators can readily monitor patterns and events as they unfold and provide
reporting to key stakeholders in the organization.
Learning Objectives
• Identify SmartEvent components used to store network activity logs and identify events.
• Discuss the SmartEvent process that determines which network activities may lead to critical
security issues.
• Understand how SmartEvent can assist in detecting, remediating, and preventing security threats
targeting organizations.
_____________________
_____________________ 436
The SmartEvent Solution

Check Point SmartEvent Software Blade is a unified security event management and analysis
solution that delivers graphical threat management information. It allows Security
Administrators to view real-time network activities in customized views or reports.
Customized views allow you to monitor activities relevant to protecting your organization.
Personalized reports enable you to report on security activities to key stakeholders in your
organization.
SmartEvent provides both a high level view and detailed forensic analysis of incidents to aid in
monitoring, fixing, and remediating security incidents. It also helps you efficiently run data
analysis and identify critical security events from the vast number of logs in the network. With
SmartEvent, you can collect, process, and search from billions of log entries in seconds.
Logs and Events

A log is a record of an action performed by a Software Blade. Log entries show the traffic
patterns that are relevant to the overall security of the organization. An event is a record of a
security or network incident that is based on one or more logs and on a customizable set of
rules that are defined in the Event policy.
The Event policy is a set of rules that define the behavior of SmartEvent. A log entry (or
multiple log entries) becomes an event when it matches any rules defined in the Event policy.
An example of a single log entry becoming an event is a High Severity Anti-Bot event,
because of the rules defined in the Event policy. Multiple log entries can also become an event,
such as in the case of a Certificate Sharing event, wherein two logins were found with the same
certificate but different users.
SmartEvent automatically defines logs that are not Firewall, VPN, or HTTPS Inspection logs,
as events. These events are created by the Correlation Unit when there is a suspicious pattern
of two or more logs. Correlated events are defined in the Policy tab of the SmartEvent GUI.
Since most logs are Firewall, VPN, and HTTPS logs, SmartEvent will not automatically define
them as events. This is to avoid performance issues with the SmartEvent Server. However,
enabling consolidated events for Firewall saves disk space and makes it possible to keep a
longer event history. To create events for Firewall, navigate to the SmartEvent Policy tab and
enable Consolidated Sessions > Firewall Session.
_____________________
_____________________ 437
S m a r t E ven t C o m p o n e n t s
SmartEvent utilizes several key components to aggregate logs, identify critical security events,
and provide efficient event query. The three main components are the Log Server, the
Correlation Unit, and the SmartEvent Server.
Log Server
The Log Server is responsible for storing logs collected from Check Point Security Gateways
and Third-Party devices. The Correlation Unit connects to the Log Server to read the logs
using the LEA (Log Export API) protocol. The Log Server uses port 18184 for this connection
by default.
NOTE
When configuring the Log Server to use a different LEA port, you must
manually configure the new port on the SmartEvent Server and on the
Correlation Unit.
Correlation Unit
The Correlation Unit evaluates logs from the Log Server to identify events. Each log consists
of data from Check Point products and third-party devices. It looks for threat patterns in this
data that match the installed Event policy. When analyzing a log, the Correlation Unit performs
one of the following actions:
• Marks logs that individually are not events, but may be part of a larger pattern to be
identified later
• Generates an event based on the Event policy
• Takes a new log entry that is part of a group of items that together make up an event,
and adds it to an ongoing event
• Discards logs that do not meet event criteria
Once a threat pattern is detected, the Correlation Unit forwards the event to the SmartEvent
Server.
SmartEvent Correlation Units can analyze logs for more than one Log Server. Check Point
recommends installing a Correlation Unit on each Log Server if your organization produces
high volume log activity. With a small network, it is best practice to store a Correlation Unit on
the SmartEvent Server.
_____________________
_____________________ 438
SmartEvent Server
The SmartEvent server houses the Events database. It receives all logs identified as events by
the Correlation Unit. The SmartEvent server performs another analysis to determine the
severity of the event and what action to take. The event is then stored in the Events Database.
This database runs on Apache Solr, an open source search platform written in Java. The main
advantage of Solr is that it manages the logs with their indexes, which in turn allows for a more
efficient way to generate search results.
S m a r t E ven t C l i e n t s
SmartEvent clients manage the SmartEvent server and provide an overview of security
information for an organization’s environment. They consolidate billions of logs and display
them as prioritized security events. Administrators can use the information displayed to
monitor network activity, identify and investigate critical events, and immediately respond to
security incidents to prevent further attacks.
SmartEvent clients are:
• SmartConsole — installed as an external application

• SmartEvent GUI — requires client installation
• SmartView Web application — does not require client installation. It has the same real-
time event monitoring and analysis views as SmartConsole. To log in to SmartEvent
using SmartView Web application, browse to https://<Security Management Server IP
Address>/smartview/ or https://<Security Management Server host name>/smartview/
NOTE
The SmartView Web application URL is case sensitive. The “/” at the end
is required. SmartEvent must be enabled to view Smartview.
_____________________
_____________________ 439
S m a r t E ven t Wo rk fl ow
The workflow below provides a high-level view on how the different SmartEvent components
interact:
Figure 362 — SmartEvent Workflow
1. Check Point products and other supported third-party devices forward logs to the Log
Server for storage. The Correlation Unit reads all logs from the Log Server and makes the
correlation analysis based on the SmartEvent policy. The Events policy resides on the Cor-
relation Unit.
2. Once the Correlation Unit identifies a threat pattern, it identifies the associated log entries
as an event and sends it to the SmartEvent Server. The SmartEvent server assigns a sever-
ity level to the event, invokes any defined automatic reactions, and adds the event to the
Events Database that resides on the server. The severity levels and automatic reactions are
defined in the Events Policy. An automatic reaction is the defined immediate course of
action to a detected event. For example, an automatic email notice is sent to System
Administrators once an event has occurred. This will be discussed further in the Remediat-
ing Security Event section of this chapter.
3. The SmartEvent client displays the received events. It presents all of the information
needed for real-time monitoring of security events, event investigations, and remediation.
Administrators can also utilize the SmartEvent client to generate reports, fine-tune and
install the Events Policy.
_____________________
_____________________ 440
S m a r t E ven t D e p l oym e n t
SmartEvent components can be installed on a single machine (a standalone deployment), or
spread out over multiple machines and sites (a distributed deployment). Implementing a
distributed deployment is highly recommended if your organization anticipates a high volume
of logging activity.
Enable SmartEvent on the Security Management Server or deploy it on a dedicated server. You
can also install more than one SmartEvent Correlation Unit. Each SmartEvent Correlation Unit
can analyze logs from multiple Log Servers or Domain Log servers. Dedicated SmartEvent
appliances from Check Point are also available as an option when deploying SmartEvent in
your organization. A valid license or contract is required to deploy SmartEvent.
Before installation, make sure to perform the following actions:
• Use a dedicated server for SmartEvent that is connected to a management server.

• Do a clean installation.
• Uninstall the old SmartEvent client installed on computers, before installing the new
client.
• Connect to a management server (Security Management Server or Multi-Domain
Server), version R77.xx or higher.
NOTE
Check Point recommends configuring Disk Space Management parameters
to delete old log entries when available disk space is 45% or less. This
configuration only applies to the raw log files and has no effect on the
events database since it uses an internal disk space management policy.
_____________________
_____________________ 441
D e fi n i n g t h e I n te r n a l N et wo r k
To help SmartEvent determine whether events originated internally or externally, the internal
network must be defined in the initial settings. There are four options to calculate the traffic
direction:
• Incoming — All the sources are outside the network and all destinations are inside.
• Outgoing — All sources are inside the network and all destinations are outside.
• Internal — Sources and destinations are all inside the network.
• Other — A mixture of and internal and external values makes the result indeterminate.
NOTE
It is recommended to add all internal network objects, not host objects.
Adding Network and Host Objects

Certain objects from the Management server are added during the initial sync with the
SmartEvent server and updated at a set interval. However, it may be necessary or useful to add
other network or host objects to the internal network, such as:
• If there are devices or networks not represented on the management server that are
important for defining the internal network
• When adding sources or destinations to exclusions or exceptions in event definitions
• When selecting sources or destinations in a filter
_____________________
_____________________ 442
Identifying an Event
One of SmartEvent’s key features is its ability to identify a potential security incident or event
from the multitude of logs that can be generated in an organization. As previously mentioned,
events are detected by the Correlation Unit. SmartEvent is constantly retrieving logs from Log
servers and searching for patterns. The Correlation Unit scans logs for criteria that match an
event definition. SmartEvent uses the following procedures to identify events:
• Matching a log against global exclusions

• Matching a log against each event definition
• Creating an event candidate
• Updating an event
Matching a Log Against Global Exclusions

When the Correlation Unit reads a log, it first checks whether the log matches any defined
Global Exclusions. When Global Exclusions are defined, they direct SmartEvent to ignore logs
that are not expected to contribute to an event. If a log matches a Global Exclusion, it is
discarded by the system. If it does not match, the Correlation Unit begins matching the log
against each event definition.
Matching a Log Against Each Event Definition

Each event definition contains a filter which is comprised of multiple criteria that must be
found in any matching log. In turn, the criteria are divided by product. This means an event
definition may include a number of different products, but each product has its own criteria
(set of values).
Figure 363 — Event Definition A
_____________________
_____________________ 443
For example, for a log from URL Filtering to match Event Definition A, it must match the
Action, Event Type, Port, and Protocol values listed in the URL Filtering category. A log from
a Security Gateway must match the values listed in its respective column. SmartEvent divides
this process into two steps:
1. The Correlation Unit first checks whether or not the product value in the log matches one
of the acceptable product values of an Event Definition. For example, in the figure below,
if Log 1 did not contain an acceptable product value, the Correlation Unit would then
compare the log against the next Event Definition, and so on. If the log does not match any
Event Definition, it is discarded.
2. Next, the Correlation Unit checks whether the log matches the product-specific criteria in
an event definition. For instance, URL Filtering generates logs that involve the Firewall,
spyware, malicious code protection, and others, which is populated in the Event Type
field. If an event matches URL Filtering logs involving the Firewall, then the URL Filter-
ing log involving spyware will fail against the Event Definition. Other criteria may be spe-
cific to the Product as well, such as action, port, and protocol.
Figure 364 — Event Definition Matching Log
_____________________
_____________________ 444
Returning to the example, the Correlation Unit now examines whether the log contains the
necessary criteria for a URL Filtering log to match. If the criteria did not match, the
Correlation Unit would continue comparing the log criteria to other Event Definitions.
Figure 365 — Event Definition Matching Other Product Criteria
Creating an Event Candidate

Once a log matches the criteria, it is added to an Event Candidate. Event Candidates allow
SmartEvent to track logs until an event threshold is crossed, at which point an event is
generated. An event threshold allows System Administrators to set the limits for logs to
become an event. The limits typically are the number of connections, logs, or failures, and the
period of time in which they occurred. An example of an event threshold would be: Detect the
event when more than “x” (number value) connections/logs/failures were detected over a
period of “y” (time value) seconds.
_____________________
_____________________ 445
Note:
• The Event Candidate can track logs from multiple Check Point and non-Check Point
products.
• Logs must originate from the same source IP address.
• The Event Candidate tracks logs before all of the criteria have been matched.
Figure 366 — Sample Event Candidate
Each event definition may have multiple Event Candidates existing simultaneously to keep
track of logs grouped by similar properties, such as by host, service, destination, or any
combination of these or others. In our example, the logs that form Event Candidate 10.1.1.5 all
have a common source value and were dropped, blocked, or rejected by a Firewall. They are
grouped together because the event definition is designed to detect activity originating from
source address 10.1.1.5.
_____________________
_____________________ 446
Whenever a log matches the event definition but has properties different than those of the
existing event candidates, a new Event Candidate is created and added to an Event Candidate
Pool. SmartEvent creates a new Event Candidate for a log with a different source.
Figure 367 — Sample Event Candidate Pool
The Event Candidate pool is a dynamic environment, with new logs being added and older
logs being discarded when they have exceeded an event definition threshold.
To illustrate further, consider the event defined to detect a high rate of blocked connections.
SmartEvent tracks the number of blocked connections for each Firewall and the logs of the
blocked traffic at each Firewall form an Event Candidate. When the threshold of blocked
connection logs from any Firewall is surpassed, that Event Candidate becomes an event.
_____________________
_____________________ 447
While this event definition creates one Event Candidate for each Firewall monitored, other
event definitions may create many more.
Figure 368 — Sample Event Candidate Pool with Multiple Candidates
Updating an Event
Discovering an event does not mean SmartEvent stops tracking logs related to the event. When
a candidate becomes an event, the Correlation Unit forwards the event to the Event Database.
The Correlation Unit will keep adding matching logs to the event as long as they continue to
arrive, even if an event threshold has been reached. Keeping the event open condenses what
might otherwise appear as many instances of the same event to one, and provides accurate, up-
to-date information as to the start and end time of the event.
_____________________
_____________________ 448
Monitoring the Network

Administrators can use SmartConsole and SmartView Monitor to monitor network activity and
identify, analyze, and manage security events.
Using SmartConsole Logs & Monitor

SmartConsole includes a catalog of views and reports in the Logs & Monitor section of the
GUI. Views and reports are customizable, allowing you to display and report the events and
data that are most important to your network. For example, it may be important to monitor
network traffic based on geography.
With a few clicks, you can easily move from a high-level view to a detailed forensic analysis of
network activity. The free-text search option lets you quickly run data analysis and identify
critical security events.
Figure 369 — SmartConsole > Logs & Monitor
_____________________
_____________________ 449
Using SmartView Monitor

Use SmartView Monitor to respond quickly to changes in gateways, tunnels, remote users and
traffic flow patterns and security activities. For example, remote employees of an organization
report trouble connecting to the network. Using the SmartView Monitor Counter view, the
administrator can assess that there are more failures to connect than successes. A report can be
created to determine what is preventing the employees from connecting to the network.
SmartView Monitor provides real-time and historical graphical views of:
• Gateway status
• Remote users
• System counters
• VPN tunnels
• Cooperative enforcement (for Endpoint Security Servers)
• Traffic
Figure 370 — Sample System Counter View
_____________________
_____________________ 450
E ve n t Q u e r i e s
A view is an interactive dashboard made up of widgets. A widget can display information in
different formats such as a chart, or a table. Each widget is the output of a query. To review
more about an event, double-click the widget to drill down to a more specific view or the raw
log files.
Figure 371 — Sample View
Queries are used to define the events to see. These queries filter and organize the event data for
display. SmartConsole provides a predefined set of queries which are organized by
combinations of event properties. For example, a set of Threat Prevention queries will include
Threat Prevention events as well as IPS events.
Event queries can be customized to display specific related events and treads as defined by the
organization. Customized event queries can be created from scratch or based on an existing
query.
Events are easily monitored using custom and predefined queries. To help identify suspicious
patterns, use the following features to search and filter events:
• Filters
• Free-text search using Boolean operators, wildcards, fields, and ranges
• Suggested and recent searches
• Time Period
_____________________
_____________________ 451
Investigating Security Events

To further investigate an event, double-click the event to open the Log Details window. The
Log Details window will provide important information regarding the event.
Figure 372 — Log Details Window
Packet Capture
When activated, packet capture files are sent from the Security Gateway to the log server,
along with the log. Packet capture contents provide more insight into the traffic which
generated the log. If any logs have related packet captures, open a packet viewer to see the
contents of the captured packet.
Packet capture is activated by default. To see a packet capture, navigate to the Logs & Monitor
view and open the log. Click the link in the packet capture field and the Packet Capture Viewer
Output window will open. The packet capture may be saved to a file for further investigation.
_____________________
_____________________ 452
Custom Commands
SmartEvent provides a convenient way to run common command line executables that can
assist in investigating events. Right-clicking the IP address, source or destination, in an event
provides a list of default and customized commands. They appear only on cells that refer to IP
addresses, because the IP address of the active cell is used as the destination of the command
when run. The default commands are ping, whois, nslookup, and Telnet.
Figure 373 — Ping Output
Importing Offline Log Files

System Administrators can import and examine logs from a previously generated log file. This
makes it possible to review security threats and pattern anomalies that occurred before
SmartEvent was installed. It enables the investigation of threats, such as unauthorized scans
targeting vulnerable hosts, unauthorized legions, denial of service attacks, network anomalies,
and other host-based activity.
The administrator can review logs from a specific time period and focus on deploying
resources on threats that have been active for a period of time but may have been missed. For
example, new events may have been dynamically updated and can now be processed over the
previous period.
_____________________
_____________________ 453
Remediating Security Events

Once a security event is identified, investigated, and found to be a threat, remediate the issue
by:
• Configuring Event policy

• Configuring IPS policy
C o n fi g u r i n g E ve n t Pol i c y
Use the Policy tab of the SmartEvent GUI client to configure and customize the events that
define the Event policy. All events detectable by SmartEvent are organized by category under
the Event Policy branch.
Each event is enabled or disabled using the accompanying checkbox. Clearing the checkbox
next to an event removes this event type from the Event policy the next time the Event policy
is installed.
Figure 374 — SmartEvent > Event Policy
Depending on the thresholds defined in each Event, the number of events detected can be quite
high. Yet, only a portion of those events may be meaningful.
_____________________
_____________________ 454
Selecting an event displays its configurable properties in the Detail pane and a description of
the event in the Description pane. To remediate a security event, it may be necessary to adjust
or configure:
• Threshold
• Severity
• Automatic reactions
• Exceptions
• Working hours
Not all of these elements appear for every event. After installing and running SmartEvent for a
short time, you will discover which of these elements needs to be fine-tuned per event.
Threshold
The Threshold setting sets the limits that, when exceeded, indicate an event has occurred. The
limits typically consist of the number of connections, logs, or failures, and the period of time in
which they occurred.
Severity
An event severity determines in which queries, among those that filter for severity, this type of
event will appear. The levels of severity are:
• Informational
• Low
• Medium
• High
• Critical
_____________________
_____________________ 455
Automatic Reactions
To jump start remediation, an event upon detection can trigger an automatic reaction. Multiple
automatic reactions may be configured, depending on the needs of the system. For example, a
single mail automatic reaction can be defined to inform the administrator of any event, or
multiple mail automatic reactions can be configured to inform a different responsible party for
each type of event. Automatic reactions may be created under General Settings.
There are five types of automatic reactions:
• Mail — Alert a System Administrator by email that the event has occurred.
• Block Source — Instruct the Security Gateway to block the source IP address(es) from
which this event was detected for a configurable period of time.
• Block Event Activity — Instruct the Security Gateway to block a distributed attack
that originates from multiple sources, or attacks multiple destinations for a configurable
period of time.
• External Script — Run a provided script.
• SNMP Trap — Generate an SNMP Trap.
Exceptions
Exceptions allow an event to be independently configured for the sources or destinations that
appear. For example, if the event Port Scan from Internal Network is set to detect an event
when 30 connections have occurred within 60 seconds, define that two port scans detected
from host A within 10 seconds of each other is also an event.
Working Hours
Working hours are used to detect unauthorized attempts to access protected systems and other
forbidden operations after-hours. To set the Regular Working Hours for an event, select a Time
object from the drop-down menu. Time objects are configured under General Settings.
_____________________
_____________________ 456
C o n fi g u r i n g I P S Pol i c y
IPS protections and profiles should be reviewed to understand why an event was generated.
Administrators may also review the events to investigate how traffic is handled by IPS. Any
event generated by the IPS Software Blade is easily investigated and remediated through the
Event Details window. From the Event Details window, you can:
• Go to the Check Point Advisory article which provides background information about
the IPS protection.
• Review a detailed IPS protection description.
• Fine-tune the IPS protection.
• Add an exception to the IPS protection.
_____________________
_____________________ 457
Reporting Security Events

Reports make it easy to quickly generate, review, and share security data using graphs and data
tables. They provide more detailed information than a view. Predefined and customized reports
can be generated to provide security information on a schedule (daily, weekly, or monthly), or
as needed. For example, an executive may request a monthly security brief on the most recent
security trends to evaluate company policy and procedure, such as allowing employees to
access particular sites and applications during work hours.
Figure 375 — Sample Report
_____________________
_____________________ 458
U s i n g P r e d e fi n e d Rep o r ts
Use predefined graphical report templates for the most frequently seen security issues. To open
the catalog of predefined and customized reports, click the [+] tab. Double-click a report to
open it. SmartEvent automatically downloads new predefined reports, and updates existing
reports.
Figure 376 — List of Reports
Importing and Exporting Reports

The Export to PDF and Export to Excel options allow you to save the current report as a PDF
or Excel file, based on the defined filters and time period. Report layout and widget definition
templates can also be exported. Similarly, the Import Template option allows you to import
these template files from another server, or from another administrator.
Adding a Logo to Reports

By default, the Check Point logo shows on the cover pages of the report. System
Administrators can configure reports to show their company logo instead. Save the image file
of the logo as a PNG file with the name cover-company-logo.png then copy the image to the
$RTDIR/smartview/conf directory on the SmartEvent server.
_____________________
_____________________ 459
D e fi n i n g C u s to m Rep o r t s
Because each company is different, SmartEvent helps System Administrators to create custom-
made reports that fit their respective organization. To customize a report, select a predefined or
custom report, then click Edit to define the new report.
Defining the Report Outline and Filters

The workspace shows Views on the left when you edit a report. A view is an interactive
dashboard made up of widgets. It is also a section of the report shown in one page or multiple
pages, if it includes a table. The Views pane has management controls that help you add,
remove, change the sequence of views, and even add filters for the data included in the report.
Changes to views is only applied to the custom report that you are working on.
Defining Views
When you click a particular View thumbnail, it shows the widgets included in that view. A
widget is a representation of the collected data. Each widget is contained in a panel with
management options that allow you to add, remove, move, or resize a widget. Note that
moving or resizing the widget out of the page borders is not possible. For table layouts that
expand to multiple pages, select Show all table rows from the Split table across multiple pages
window on the View Settings option.
NOTE
The desired graphical view of your organization’s security posture can be
quickly customized by adding a widget to a view. Before adding a widget,
make sure that the view has enough space; otherwise an error message will
appear.
Filtering Reports by User Groups

System Administrators may need to generate several reports for different key stakeholders. A
report meant for a C-level executive may contain information not relevant to a department
head. Reports, views and widgets can be filtered for one or more Active Directory user groups.
Prior to enabling this feature, an Access Role object that includes the AD groups to use in the
query for the report must be defined. To filter reports for specific user groups, look at the
Identity Awareness login logs, and copy the names of the relevant groups. Add a filter for the
User Group field and enter the name of the group to be included in the filter. For multiple
groups, use a comma-separated list.
_____________________
_____________________ 460
Preventative Measures
After remediating security events, preventative measures can be put in place to ensure the
event is addressed as soon as possible and prevented from repeat occurrence.
C r e a t i n g a N ew E ve n t D e fin i t i o n
Once a new threat is discovered and remediated, take preventative action by creating a new
event definition. The next time this threat pattern is detected, it will create an event in the
Events database, allowing it to be addressed and remediated more quickly. The Event
Definition Wizard makes it easy to configure a new event definition from scratch or based on
an existing event.
Figure 377 — Event Definition Wizard
When creating a new definition, the Event Definition Wizard allows you to choose if an event
will be generated when an event definition is matched by a single log or multiple logs. It also
gives you options to choose which of the product(s) can trigger an event. All user defined
event definitions are automatically saved in the User Defined Events folder in the Selector
Tree.
_____________________
_____________________ 461
Rep o r t i n g a n E ve n t to C h e c k Po i n t
Reporting event data to Check Point can help Check Point improve the IPS technology to
detect new threats. Only the event information will be sent to Check Point over a secure SSL
connection. The data is kept confidential and Check Point only uses the information to
improve IPS.
Figure 378 — Report Event to Check Point
E l i m i n a t i n g Fa l s e Po s i t i ve s
To eliminate false positives, it is important to understand how a false positive might be
generated. Certain types of services are characterized by a high amount of traffic that could be
misidentified as events. The following are examples of services and protocols that could
potentially generate events.
• Software that performs a routine scan of the network to make sure that everything is
running properly.
• A high connection rate on a web server. SmartEvent should be set to allow a higher
connection rate per minute on a busy web server, or to exclude this source from a scan
event.
Refer to the Check Point Logging and Monitoring Administration Guide for a list of server
types where high activity is common. Modify the Event policy by adjusting event thresholds
and adding Exclusions for servers and services, to further reduce the amount of false positives
detected.
To eliminate false positives, change the thresholds and other criteria of an event. For example,
increase the number of connections, logs, or failures and/or the period of time for them to
occur.
_____________________
_____________________ 462
SmartEvent Example
While monitoring the network, you notice the network is flooded with connections. This merits
an investigation. Using the filters, queries, and search bar features, you browse the event
database and determine that the gateway is stable. However, it is the interface that has received
lots of connections.
To start the investigation process, navigate to the Policy tab and activate all port scan events in
the Event policy to generate logs. After installing Event policy and additional traffic flowing
into the interface, many port scan events are created. Upon reviewing the details of multiple
events, it is evident that there is only one source and one destination. This is unusual as
legitimate port scans will have multiple source or destination IP addresses. One source and one
destination IP address indicates that this may be a targeted attack. After investigating the
source IP addresses and narrowing down the type of device they are originating from, the
conclusion is that the traffic is not legitimate.
To begin remediation, in SmartConsole, create a new rule that blocks traffic from the
illegitimate sources. If the traffic was legitimate, navigate to the Policy tab to configure the
settings for the Port scan from external network event. Add the IP address as an exception to
prevent port scans from this IP address from generating an event. Another option is to edit
threshold settings to increase the number of connections, or expand the time period in which
the connections occur.
The next step is prevention. Navigate to the Port scan from external network event. Create an
automatic reaction that will email the entire IT team when at least 20 connections are detected
within sixty seconds (one minute). By doing this, the next time there is a flood of traffic on an
interface, the entire IT team is notified and can quickly address and remediate the event.
With SmartEvent, it was easy to quickly search and filter through events to discover the
problem, enable the appropriate event policy, review specific threat information, and institute
preventative measures. By creating automated alerts and rules, you will ensure that the
network is able to perform without being bogged down by unnecessary traffic.
_____________________
_____________________ 463
High Availability Environment

The SmartEvent database maintains a synchronized copy of management objects locally on the
SmartEvent server. This process, also known as dbsync, allows SmartEvent to work
independently from different management versions and different management servers in a
High Availability environment.
Management High Availability exists for Security Management Servers and in a Multi-
Domain Security Management environment. The dbsync process supports High Availability
for the Multi-Domain servers and the Domain servers.
The dbsync process initially connects to the management server with which SIC is established.
It retrieves all the objects and, after the initial synchronization, it gets updates whenever an
object is saved. At this point, dbsync registers all the High Availability management machines
and periodically tests the connectivity with the current management server. If connectivity is
lost, it attempts to connect to the other High Availability management servers until it finds an
active one and connects to it.
If two management servers are active concurrently, dbsync will remain connected to one and it
will not receive any changes made on the other management server until a synchronization
operation is performed.
Log Server High Availability

In SmartConsole, it is possible to configure a Security Gateway such that when it fails to send
its logs to one Log server, it will send its logs to a secondary Log server. To support this
configuration, it is possible to add both Log servers to a single Correlation Unit. In this way,
the Correlation Unit will get an uninterrupted stream of logs from both servers and will
continue to correlate all Firewall logs.
SmartEvent Correlation Unit High Availability

Multiple Correlation Units can read logs from the same Log servers, providing redundancy if
one of them fails. The events detected by the Correlation Units will be duplicated in the
SmartEvent database. These events can be ascertained by filtering with the Detected By field
in the Event Query definition. The Detected By field specifies which Correlation Unit detected
the event. The SmartEvent server becomes unavailable, the Correlation Units retain the events
until they can reconnect with the SmartEvent server and forward the events.
_____________________
_____________________ 464
Security CheckUp
With Check Point Security Checkup tools, administrators can generate a comprehensive
security analysis report that summarizes security events, their risks, and remediation. These
reports are mainly used for Proof of Concept (PoC) purposes. The Security CheckUp
Advanced and Anonymizer Reports are threat analysis reports that generate charts and
organize security data to display key findings on malware, attacks, data loss, and high risk web
access. SmartEvent must be activated before running the Security CheckUp reports and the
tool is installed as a supplement. The difference between SmartEvent reports and the Security
CheckUp reports is that the Anonymizer report does not use IP addresses or usernames.
Each report can be localized into any language and customized to display information from a
specific time period or filter preferences. Like other reports, Security CheckUp reports can be
generated on a schedule or as-needed basis and saved as a PDF or Excel file for the purpose of
information sharing and security event investigation.
Figure 379 — Security CheckUp Report
L a b 5 .1
Evaluating Threats with SmartEvent
_____________________
_____________________ 465
5.1
L
Evaluating Threats with A
SmartEvent B
Set up SmartEvent to generate alerts and reports. These applications are valuable for use in executive level
meetings, as well as for record keeping and compliance auditing.
Ta sks :
• Configure the SmartEvent Suite.
• Generate Reports based on available data.
• Configure a SmartEvent Server to monitor relevant patterns and events.
• Demonstrate how to configure event Alerts in SmartEvent.
• Demonstrate how to run specific SmartEvent reports.
_____________________
_____________________ 466
Configure the Network Object in SmartConsole

Active the SmartEvent for the A-SMS and A-GW-Cluster objects.
1. In the SmartConsole on A-GUI, open the following object:
A-SMS
2. Use the following information to configure the object:
Name: A-SMS
Management Blade SmartEvent Server
Selections:
Smart Correlation Unit
3. If the system displays an information message, click OK to dismiss it.
_____________________
_____________________ 467
4. Verify that the object is configured as follows:
Figure 380 — A-SMS Configured
5. Click OK.
_____________________
_____________________ 468
6. Edit the Alpha gateway cluster object, and select the Monitoring option in the Network Security tab:
Figure 381 — Gateway Cluster Properties Configured
_____________________
_____________________ 469
7. Select the Monitoring Software Blade branch, and select the following options:
Traffic Connections
Traffic Throughput (Bytes per second)
Figure 382 — Monitoring Software Blade Page
8. Select the Logs branch.
_____________________
_____________________ 470
9. Under the section Send logs and alerts to these log servers, Verify that A-SMS is listed:
Figure 383 — Log Servers branch
10. Click OK.

_____________________
_____________________ 471
12. In SmartConsole, select the Logs and Monitor tab:
Figure 384 — Select Server
_____________________
_____________________ 472
13. Click the + tab, and the system displays a new default tab:
Figure 385 — New Tab
_____________________
_____________________ 473
14. In the left pane, click the following link and the system displays SmartEvent:
SmartEvent Settings & Policy
Figure 386 — SmartEvent
NOTE
It may take a little longer for SmartEvent to start up and display information the first
time it is launched.
15. In the navigation pane, select General Settings > Objects > Network Objects.
_____________________
_____________________ 474
16. Verify that the Alpha-Nets object appears in the General Settings > Objects > Network Objects page:
Figure 387 — Network Objects
_____________________
_____________________ 475
Monitoring Events with SmartEvent

In this section, you’ll define a new event that will be triggered later in the lab.
1. Expand the Unauthorized Entry branch, and select the Check Point administrator credential guessing:
Figure 388 — Policy Tab > Unauthorized Entry > Check Point Administrator
2. Change the Failure Detection setting from the default of 3 failures every 600 seconds to 2 failures
every 300 seconds.
_____________________
_____________________ 476
3. From the Actions menu, select Install Event Policy, and the system displays the following message:
Figure 389 — SmartEvent Dialog
4. Click Yes. After the policy is installed, minimize SmartEvent.

6. Then, log out of SmartConsole.
7. Attempt to log in to SmartConsole, using the wrong password at least five times.
8. Launch SmartConsole using the correct login.
_____________________
_____________________ 477
9. Select the Logs & Monitor view, and create a new tab:
Figure 390 — Logs & Monitor - New Tab
_____________________
_____________________ 478
10. Click the Open Audit Log View button, and the system displays the following:
Figure 391 — Audit Log View
_____________________
_____________________ 479
11. View the record for the blocked login attempts:
12. Close the record details.
_____________________
_____________________ 480
13. Open a new tab in Logs and Monitor.

14. Select Reports.
15. In the reports list, click the star icon for the following items:
Correlated Events
Network Activity
Network Security
Figure 393 — Reports
_____________________
_____________________ 481
16. Open a new tab, and confirm the availability of new reports:
Figure 394 — New Tab Configured
_____________________
_____________________ 482
17. Click the Correlated Events report icon:
Figure 395 — Correlated Events
_____________________
_____________________ 483
18. View the incident report on page two of the report showing the following Event:
Check Point Administrator Credential Guessing
Figure 396 — Check Point Administrator Credential Guessing - Event Reported
END OF LAB 5.1
_____________________
_____________________ 484
Review Questions
1. What are the main components of the SmartEvent Architecture?
2. Explain how SmartEvent identifies an event.
3. How would a System Administrator reduce the number of false positives?
_____________________
_____________________ 485
C
6
H
P
Remote and Mobile Access T

E
R
In today’s business environment, employees need to connect to company applications and

data from off-site locations. Remotely connecting to corporate resources has security
issues that System Administrators need to address. This chapter discusses Check Point
Remote and Mobile Access solutions that protect an organization’s confidential
communications and data in the age of workforce mobility.
Learning Objectives
• Recognize Check Point Remote Access solutions and how they differ.
• Discuss Check Point Capsule components and how they work to protect mobile devices and
business documents.
• Discuss the Mobile Access Software Blade and how it secures communication and data exchange
during remote connections.
• Understand Mobile Access deployment options.
_____________________
_____________________ 486
Choosing Remote Access Solutions

All Check Point Remote Access solutions provide secure connectivity to corporate resources.
Strong user authentication methods and granular access control reinforce network security.
Check Point Remote Access solutions use IPSec and Secure Socket Layer (SSL) encryption
protocols to create secure connections. All Check Point clients can work through NAT devices,
hotspots, and proxies in situations with complex topologies, such as airports or hotels.
There are a few factors to consider when choosing remote access solutions for your
organization:
• Client-Based or Clientless: Does the solution require a Check Point client to be

installed on the endpoint computer or is it clientless, for which only a web browser is
required? Multiple solutions may be required within your organization to meet different
needs.
• Secure Connectivity or Endpoint Security: Does the solution just require secure
connectivity, whereas traffic is encrypted between the client and the VPN gateway, or
endpoint security that provides protection even when there is no connectivity to the
network?
• SSL VPN versus IPSec VPN: Does your organization need a full VPN tunnel to
protect the access from any installed application to the business or does it need a
simpler business portal for secure access?
I n s t a l l a t i o n Typ e s
There are three types of installations for remote access solutions:
• Client-based — In this solution, the client application is installed on endpoint

computers and devices. Clients are usually installed on a managed device, such as a
company-owned computer or device. The client supplies access to most types of
corporate resources according to the access privileges of the user.
• Clientless — In this solution, users connect through a web browser and use HTTPS
connections instead of connecting through a managed device. Clientless solutions
usually supply access to web-based corporate resources.
• On Demand Client — This remote access solution blends the first two options. A user
connects with a web browser and installs a client when necessary. The client supplies
access privileges to most types of corporate resources according to the access privileges
of the user.
_____________________
_____________________ 487
Secure Connectivity and Endpoint Security

Secure connectivity can be combined with additional features to protect the network or
endpoint computers. With secure connectivity, traffic is encrypted between the client and VPN
gateway and strong user authentication is supported. After users authenticate, they can access
the corporate resources that are permitted to them in the access policy. All Check Point remote
access solutions supply secure connectivity and require licenses.
Security verification for endpoint computers makes sure that devices connecting to the
gateway meet security requirements. Endpoint machines that are not compliant with the
Security Policy have limited or no connectivity to corporate resources. Some Check Point
solutions supply this.
In terms of Endpoint Security, endpoint computers are protected at all times, even when there
is no connectivity to the corporate network. An integrated desktop Firewall protects endpoint
computers at all times with a centrally-managed Security Policy. This is important because
remote clients are not in the protected network and traffic to clients is only inspected if a
desktop Firewall is present. Some Check Point solutions supply this. These solutions require
licenses based on the number of clients installed.
NOTE
Check Point solutions can include more Endpoint Security capabilities,
such as Anti-Malware and disk encryption.
_____________________
_____________________ 488
S S L V P N ve r s u s I P S e c ( L aye r 3 ) V P N
Check Point solutions provide enterprise-grade access via both Layer 3 (IPSec) and SSL VPN.
There is a fundamental difference in how an SSL VPN Portal and a Layer 3 VPN tunnel
connect to the corporate network. In a Layer 3 VPN solution, a resident VPN client is needed,
which creates the Layer 3 virtual interface that any application can use. SSL VPN solutions
only require a browser on the client side and allow mobile devices with a dedicated application
to access corporate resources without establishing a VPN tunnel.
Figure 397 — Layer 3 VPN versus SSL VPN
In an SSL VPN solution, users can connect securely to business web-based applications
through a web portal. This solution does not require users to install a VPN client. SSL VPN is
the recommended solution for unmanaged and personal devices used for business purposes.
Layer 3 VPN solutions require remote workers to install a VPN client before gaining access to
corporate resources. Once a user installs the client, the Layer 3 VPN tunnel provides a secured
connection to both web-based and native business applications. This is recommended for
corporations with employees using managed or unmanaged devices.
Both solutions can be configured to enforce two-factor authentication.
_____________________
_____________________ 489
Clients
All Check Point Remote Access options provide secure remote access to corporate resources.
Each has different features and meets different organizational requirements.
M o b i l e Ac c e s s Po r ta l
The Mobile Access Portal, a clientless SSL VPN solution, is recommended for users who want
to access corporate resources from any unmanaged computer or device. This solution does not
require users to install a VPN agent or client. The Mobile Access Portal provides secure
connectivity and security verification. It requires a Mobile Access Software Blade license on
the Security Gateway. Remote users log in to the portal using an authentication scheme
configured for that Security Gateway. The Mobile Access policy applies to the Mobile Access
Portal. The portal can also be used with managed devices.
The Mobile Access Portal supplies access to web-based corporate resources. The on-demand
client, SSL Network Extender, can be used to access all types of corporate resources.
NOTE
Each Security Gateway enabled with Mobile Access leads to its own
Mobile Access User Portal. Set up the URL in the Mobile Access First
Time Wizard. For portal customization, System Administrators can go to
Portal Customization under Mobile Access in the SmartConsole.
S S L N e t wo rk E x te n d e r
SSL Network Extender (SNX) is a thin SSL VPN on-demand client that is automatically
installed on the remote user's machine through a web browser. This VPN client is installed as a
browser plug-in. Once installed, it enables a secured connection using the SSL VPN tunnel to
link users to the corporate resources. SSL Network Extender requires Mobile Access and
IPSec VPN Software Blade licenses on the Security Gateway.
SSL Network Extender has two modes:
• Network — Users can access all native IP-based and web-based applications in the
internal network. For users to gain access to these applications, System Administrators
must first define these as native applications in Mobile Access. The user can access the
resources by launching the client either from the desktop or the Mobile Access portal.
To work in Network mode, users must have installation privileges.
• Application — Users can access most native IP-based and web-based application types
in the internal network, including most TCP applications. Users can only launch the
client in the Mobile Access portal. Once installed, users can access internal resources
defined as native applications in Mobile Access. Working in Application mode does not
require installation privileges.
_____________________
_____________________ 490
C h e c k Poi n t M o b i l e
Check Point Mobile offers an remote access option for several different platforms.
• Check Point Mobile for Windows — An IPSec VPN client solution for medium to large
enterprises that do not require an Endpoint Security Policy. It provides both secure
connectivity and security verification. This option requires both IPSec VPN and Mobile
Access Software Blade licenses.
• Check Point Mobile for iPhone and iPad — An SSL VPN client which supplies secure
connectivity and access to web-based corporate resources and Exchange ActiveSync.
This option is best used for mobile workers who have iOS mobile devices. A Mobile
Access Software Blade license is required for this option.
• Check Point Mobile for Android — An SSL VPN client for Android device users. It
supplies secure connectivity and access to web-based corporate resources and
Exchange ActiveSync. A Mobile Access Software Blade license is required for this
option.
C h e c k Poi n t C a p s u l e Wor k s p a c e
Capsule Workspace is an SSL VPN client for mobile devices that provides remote users
seamless access to a separate, secure business environment. A Check Point Capsule license is
required on the Security Gateway. This solution is further discussed in the Check Point
Capsule Solution section.
S e c u Rem ote
SecuRemote is a limited-function IPsec VPN client that only provides secure connectivity.
SecuRemote is a free client and only requires an IPSec VPN Software Blade license on the
Security Gateway.
Ad d i t i o n a l Rem ote Ac c e s s O p t i o n s
Check Point offers additional Remote Access options, including options specifically for
Endpoint Security. For more detail information regarding Remote Access solutions and
options, refer to sk67820.
_____________________
_____________________ 491
Check Point Capsule

Check Point Capsule addresses mobile access needs by securely protecting devices from
threats and protecting business documents wherever they go, all while providing a secure
business environment for mobile devices. Mobile Threat Prevention is further discussed in the
Threat Prevention chapter.
Check Point Capsule secures remote communication and data exchange using three
components: Capsule Workspace, Capsule Docs and Capsule Cloud.
C a p s u l e Wo rk s p a c e
Using Capsule Workspace, mobile users are provided a secure login with easy access to
business applications, exchange applications, and documents. This solution allows employees
working remotely to securely connect to the network and easily use and store business data and
documents within the application’s security container. Users have access to corporate email,
files, directories, corporate contacts, and calendars. Capsule Workspace allows company
employees to use their personal devices for work-related tasks yet place only business data
under control of the corporate IT team. With Capsule Docs integration and an application-level
passcode, business data is protected everywhere. Capsule Workspace also features offline data
encryption, policy and remote wipe, and sharing control. With Capsule Workspace,
organizations can enhance the productivity of employees while securing the use of personal
devices and protecting business data.
Key benefits include:
• One application is used to access business information, providing segregation between

personal and professional on the device.
• Provides a great end-user experience with push notifications, document editor,
HTML5, and more.
• Provides an end-to-end solution with no compromise on security, from Microsoft
Exchange to the mobile device.
_____________________
_____________________ 492
Capsule Workspace also has a remote data wiping feature, to delete the stored offline data after
each session. This may be useful when a user certification has been revoked, when a device is
lost, or an employee leaves the company.
Figure 398 — Capsule Workspace
_____________________
_____________________ 493
Capsule Connect
Capsule Connect complements Capsule Workspace to provide access to native applications.
Key features include:
• Full Layer 3 VPN client

• Works in the background
• On Demand (iOS) / Always On (Android)
• Supports all VPN authentication methods
• Infrastructure for Capsule Cloud
Typical user scenarios include:
• Corporate applications using native applications

• Non HTML5 Remote Desktop Solutions
• Corporate mail using Native Clients
_____________________
_____________________ 494
How Capsule Connect and Capsule Workspace Differ

Capsule Connect and Capsule Workspace both offer secured connection for remote users who
are using their mobile devices. However, there are differences between the two.
Connect Workspace
VPN type IPSec VPN (Layer 3) SSL VPN
Applications Any application • Secure browser, including remote terminal
viewing
• ActiveSync provisioning
• Exchange applications and push notifications
• Document viewing and editing
• Roadmap: Chat, SharePoint
• Roadmap: Third-party applications
Operating iOS, Android, WP8 iOS, Android
system
Business data None • Application-level passcode
isolation • In-app encryption
• Remote wipe
• Offline data policy
• Document sharing control (allow/block/
encrypt on-the-fly)
Credential • One-Time Password • OTP login support
protection (OTP) login support • SSO for Workspace apps
• No SSO support
Compliance/ MDM cooperative • Jailbreak/root detection
host checking enforcement • MDM cooperative enforcement
Table 10: Comparison of Capsule Connect and Capsule Workspace
_____________________
_____________________ 495
Capsule Docs
The rise of user collaboration and file sharing platforms may lead to security issues, such as
information theft and data leakage. Capsule Docs avoids these issues by securing the actual
document with the following capabilities:
• Classify — Define a set of permissions, which may include markings such as headers,
footers, and watermarks.
• Share — Decide with whom to share the document.
• Encrypt — Apply encryption (AES256 + RSA2048) to the document so that it is
protected and accessed only by the authorized users and groups.
Figure 399 — Capsule Docs Document Classification
Once files are protected, users can store the document anywhere and share them on different
platforms. Capsule Docs secures the document contents regardless of where it is kept or with
whom it is shared. In the event an attacker obtains the document, the content of the document
is encrypted and not accessible to unauthorized users.
Capsule Docs does not require users to have an additional password because it uses Active
Directory credentials for authentication.
Users and System Administrators can share a document with an external user by adding the
recipient’s email address to the list of authorized users. On the first attempt to access the
document, the external user will be asked to install either a viewer or editor client and register
in the system. This registration is fast and required only once.
Capsule Docs also logs any action performed by end users, such as when they add a new user
to the authorized list or when they remove the document’s protection. This can be helpful for
you when auditing and monitoring proprietary documents.
_____________________
_____________________ 496
Content Encryption
Document content is encrypted with a symmetric key. AES 256 is used for an On-Premise
deployment, and AES 128 is used for a Cloud deployment. The Content Encryption Key is
generated by the client and encrypted with asymmetric keys generated by the management
server. The Content Encryption Key can be accessed with one of the following:
• The Master Key (RSA 2048)

• The Classification Key (RSA 2048) and the User / Group Key (RSA 2048)
Cloud Deployment
Capsule Docs in the Cloud is the best option for organizations that prefer not to deploy an
additional server. In this setup, the Cloud stores community encryption keys, users, policy
settings, and audit logs. LDAP is used to manage users in a Cloud deployment. User
registration is done through the Capsule Web Portal and authentication is done against LDAP.
Figure 400 — Cloud Deployment
_____________________
_____________________ 497
Capsule Cloud
Capsule Cloud utilizes Check Point Software Blade solutions as a cloud-based service.
Capsule Cloud enforces the organization’s in-network Security Policy to both on- and off-
premise devices. It helps the enterprise to protect employees using laptops and mobile device
when they are outside the secured office environment. This is the best option for organizations
with multiple satellite offices and remote branches. For smaller companies and individual
users, the Capsule Connect client can be installed on their devices to connect to Capsule Cloud
for security.
To protect communication between locations, any network traffic coming from and going to
remote devices are directed to the Capsule Cloud through a secure tunnel. Capsule Cloud then
inspects the traffic based on the Security Policies implemented by the corporate office. Capsule
Cloud employs Check Point Security solutions, such as Anti-Bot, Antivirus, Application
Control, IPS, and URL Filter.
Connecting a gateway to Capsule Cloud is more efficient compared to installing the policies
locally, as this set up requires lower machine resources. Security Gateways with limited
capabilities can also access and employ more software blades in Check Point Capsule Cloud.
Cloud Portal
Administrators can manage and apply policies for both on-premise or off-premise devices
using SmartConsole or the Capsule Cloud web user interface. Cloud Portal is the Capsule
Cloud WebUI. Use Cloud Portal to:
• Set up policies for URL Filtering, Threat Prevention, and HTTPS Inspection
• View user traffic and audit logs
• Manage users and offices
• Download Capsule Cloud applications and utilities
• Change client and device settings
• Access Capsule Cloud utilities
• Determine location of roaming clients (via the Location Awareness feature)
Network administrators with access to the Cloud Portal can have either Administrator or Help
Desk access privileges. Administrators with Administrator privileges can view all tabs and
perform all operations in the Cloud Portal, while those with Help Desk rights are only allowed
to manage users and devices. Offices are corporate gateways that connect to Capsule Cloud
through a VPN. The gateway forwards traffic to Capsule Cloud where traffic is inspected
based on the Security Policies enforced.
_____________________
_____________________ 498
To connect a device to Capsule Cloud, you must create a VPN Site-to-Site community between
the two. The New Office Wizard will help you to set up this community in the Cloud Portal
and the local gateway management.
The Location Awareness feature gives administrators the option to limit access to Capsule
Cloud to external users. In this option, users with IP addresses or domains and ports within the
internal network will not be allowed to connect to Capsule Cloud.
Figure 401 — Capsule Cloud - Location Awareness
_____________________
_____________________ 499
Mobile Access Software Blade

Today’s business environment may require employees, contractors, and other knowledge
workers to access corporate resources from remote locations. Without the proper security
measures, you risk credential loss, unauthorized access, data loss and leakage, malware break-
in and propagation, and more.
The Check Point Mobile Access Software Blade is a comprehensive remote access solution
that allows mobile and remote workers to easily and securely connect to the corporate network
from any location, with any supported device, while protecting the network, remote users and
mobile devices, from threats.
This Software Blade integrates into an existing Check Point gateway, enabling a more secure
and operationally efficient remote access for your users. The data transmitted by remote access
is decrypted, filtered, and inspected in real-time by Check Point’s gateway security services. It
applies Secure Socket Layer (SSL) and IPSec (also known as Layer 3) VPN protocols to
remote connections to ensure that the communication and data are encrypted.
The Mobile Access Software Blade also provides user authentication and the ability to check
the security posture of the remote device. This further strengthens the security for remote
access. The Mobile Access solution also guarantees authenticity by using standard
authentication methods such as Certificates, RADIUS, SecurID, and Dynamic ID to transfer
information and data.
M o b i l e Ac c e s s W i z a r d
When enabling the Mobile Access Software Blade on a gateway, the Mobile Access Wizard
will guide you through the different configuration settings. It also quickly allows authorized
remote users to access internal web or mail applications through a web browser, mobile device,
or remote access client. The Mobile Access Wizard helps to configure such settings as the
mobile access methods, the primary URL for the Mobile Access Portal, and the applications
that will be available to web or mobile device users.
NOTE
Once Mobile Access is enabled, it uses HTTPS 443. This is the same SSL
port as the Gaia Web portal. To prevent conflict, change the Gaia Web
portal port to a different port, for example TCP port 4434, and add an
access rule to the Firewall policy to allow the new port.
_____________________
_____________________ 500
Mobile Access Methods

The Mobile Access Methods section of the wizard allows you to select from where users can
access the Mobile Access applications:
• Web — Through a browser on any computer. SSL Network Extender can be

downloaded by users when necessary to access native applications.
• Mobile Devices — Through an iOS or Android Mobile device. Devices must have a
Check Point application installed.
◦ Capsule Workspace — Through a secure container on the mobile device to give users
access to internal websites, file shares, and Exchange servers.
◦ Capsule Connect/VPN — Through a full Layer 3 tunnel application that gives users
network access to all mobile applications.
• Desktops/Laptops — Check Point clients for PCs and Macs that use a Layer 3 tunnel
to provide access to internal network resources.
Web Portal
The primary URL for the Mobile Access Portal will need to be specified. The default is https:/
/<IP address of the gateway>/sslvpn. It is possible to use the same IP address for all portals on
the gateway with a variation in the path. A PFX (.p12) file can be imported to obtain a trusted
certificate. A PFX file is the combined format that holds the private key and certificate. All
portals on the same IP address will use the same certificate.
_____________________
_____________________ 501
Applications
Mobile Access provides the remote user with access to various corporate applications. The
wizard allows you to select the applications that will be available to web or mobile device
users:
• Web Applications — Select the web applications that users can access. The
applications will show on the Mobile Access portal. Web application options include:
◦ Demo Web Application (World Clock) — While testing Mobile Access, select this
option to have a web application show as it will when in production.
◦ Custom Web Application — Specify a custom URL as the landing page for users
when they connect with Mobile Access. For example, the URL can be the home page
of your company’s intranet site.
◦ Mail/Calendar/Contacts — Specify the details of your Exchange Server and existing
mail/calendar/contacts applications that your mobile users can access. Options
include Capsule Workspace Mail, ActiveSync applications and Outlook Web
applications.
• File Shares — Create and configure file sharing applications using Windows Common
Internet File System (CIFS) protocol.
• Citrix Services — Select to include native applications supported by Citrix Services.
Mobile Access supports Citrix client connectivity to internal XenApp servers.
• Native Apps — Native applications are IP-based applications that are hosted on servers
within the organization. Select to specify the path to an existing executable, such as MS
Remote Desktop, Telnet, and FTP.
Active Directory Integration

If choosing to use Active Directory (AD) when you enable the Mobile Access Software Blade,
select the AD domain, enter your credentials, and test connectivity. Otherwise, select I don't
want to use active directory now.
_____________________
_____________________ 502
M o b i l e Ac c e s s Wo rk fl ow
Mobile Access allows users to securely connect to company applications and data. Below is an
example of a high-level workflow to configure access to internal applications.
1. Enable the Mobile Access Software Blade on the Security Gateway using SmartConsole.
2. Follow the steps in the Mobile Access Wizard to configure settings.
3. Add Firewall rules to allow mobile device connections.
4. Create and distribute certificates for mobile user authentication using the Certificate Cre-
ation and Distribution Wizard. You can skip this step if you are not using certificates as an
authentication method.
5. End user downloads an endpoint solution, such as the Capsule Workspace application.
6. User opens the application (in this example, Capsule Workspace) and enters the Mobile
Access site name and the required user authentication.
Figure 402 — Sample Mobile Access Workflow
_____________________
_____________________ 503
User Authentication
The following authentication methods are used for Mobile Access:
• Certificate (Internal or External Certificate Authority)

• RADIUS server
• SecurID
• Username and password (internal, LDAP)
• Dynamic ID One-Time Password (OTP)
Figure 403 — Authentication Factor Window
NOTE
A certificate can only be used as a first time authentication method.
Dynamic ID cannot be used as a first authentication method.
_____________________
_____________________ 504
Authentication can be configured for pre-R80 Security Gateways in one of two places:
• In the Gateway Properties window of a gateway in Mobile Access > Authentication:

Select the method that all users must use to authenticate to Mobile Access. The default
authentication method is Username and Password. Settings for Two-Factor
Authentication with a DynamicID OTP can be configured here as well.
• In the Gateway Properties window of a gateway in Legacy Authentication: The default
authentication method is Certificates from the ICA.
With R80.10 and higher Security Gateways, administrators can configure multiple login
options. The log in options can be different for each gateway and each Software Blade with a
supported client. For more information regarding which Mobile Access clients support
multiple log in options, refer to sk111583.
_____________________
_____________________ 505
G a teway S ec u ri t y Fea t u r e s
Once activated on the Security Gateway, the Mobile Access Software Blade offers a secured
connection by providing security measures on both the server and client side.
Server Side
Mobile Access uses IPS Web Intelligence to protect the network from web-related threats and
attacks, including malicious codes hiding in web-based applications and suspicious SQL
injection. It also scans files, such as documents and executables, using the Antivirus Software
Blade.
With Mobile Access enabled, administrators select the web-based and native applications that
can be accessed by remote users and define the actions that users can perform within the
applications. Mobile Access encrypts all traffic using HTTPS for web-based applications and
3DES or RC4 algorithm for native applications. For end users to access the native applications,
they need to install the SSL Network Extender.
Client Side
On the client side of the connection, Mobile Access can scan endpoint devices to verify their
security compliance and make sure that their protections are up-to-date. Mobile Access can be
configured to refuse a connection if the device is found to be non-compliant.
Mobile Access will only allow connections to devices that were able to authenticate, using one
of the supported authentication methods, including Dynamic ID, which is Check Point’s two-
factor authentication method for machines. In addition, security can be enhanced by preventing
browsers from caching certain content, such as a PDF, that attackers may steal.
Organizations can also require remote users to utilize Capsule Workspace, Check Point’s
proprietary virtual desktop. This virtual workspace provides a secured environment, in which
files are encrypted and gives users the option to wipe all the data after each session.
_____________________
_____________________ 506
Mobile Access Deployment

Mobile Access can be deployed in several ways, depending on which is appropriate for the
organization’s needs:
• Simple Deployment
• Cluster Deployment
Simple Deployment
This deployment is the easiest to configure. In this deployment, a single Security Gateway
enabled with the Mobile Access Software Blade inspects all network traffic, including those
coming from endpoint devices. Your existing gateway acts as your Mobile Access gateway.
Figure 404 — Simple Deployment
Cluster Deployment
A Cluster deployment works best for organizations with a large number of concurrent remote
access users. Each cluster can be deployed in either of the deployments mentioned above. In
this deployment, however, it is recommended that each cluster member has three interfaces:
one interface leading to the organization, a second leading to the Internet, and a third for
synchronization. Each interface is on a different subnet.
_____________________
_____________________ 507
Mobile Access Policy

Check Point Mobile Access extends the functionality of a Firewall for remote users. The
Mobile Access Policy defines how remote users can securely access internal company
applications and resources using mobile devices. Mobile Access Policy rules are defined and
unified in the Access Control Policy. This includes all rules related to the Mobile Access
Portal, Capsule Workspace, and on-demand clients.
In the Access Control Rule Base, rules can be configured to apply to all Mobile Access
gateways, or just selected gateways. Rules can also be configured to apply to one or more
clients, such as the Mobile Access Portal or Capsule Workspace.
M o b i l e Ac c e s s R u l e B a s e
Mobile Access rules for R80.10 and above Security Gateways can be configured as a part of
the unified Access Control Policy in SmartConsole or in the legacy shared Mobile Access
policy in SmartDashboard. Rules for pre-R80 gateways can only be configured via
SmartDashboard. Mobile Access rules for both policy options must include users and user
groups, the applications to be accessed, and the gateways that the rule applies to.
Figure 405 — Mobile Access Configuration
_____________________
_____________________ 508
All Mobile Access gateways in an environment must use the same source for the Mobile
Access policy. You cannot configure the environment to have some gateways that use the
unified Access Policy and some that use the legacy policy option.
NOTE
When using the Unified Access Policy, some Mobile Access features and
settings are still configured in SmartDashboard.
To configure an R80.10 gateway to use the unified Access Control Policy:
1. In SmartConsole, navigate to the Gateways & Servers tab, and open a Mobile Access
gateway object.
2. Select Mobile Access.
3. In the Policy Source section, select Unified Access Policy.
4. Install policy.
Mobile Access in the Access Control Policy

To configure mobile access authorization in the Access Control policy, the Mobile Access
Software Blade must be enabled. The Mobile Access blade only understands rules with a
Mobile Access Blade application defined, and with or without an access role defined in the
Source column.
Security Gateways with Mobile Access enabled, are automatically added to the Remote
Access VPN Community. To configure rules for the Mobile Access portal or client, include the
community or a Remote Access community that includes the Mobile Access gateway in the
VPN column. By default, the Remote Access VPN community contains a user group that
contains all users.
To use a Mobile Access application in the Access Control policy, it must be defined as a
Mobile Application in SmartConsole or SmartDashboard. Other application objects, such as
Content Awareness and URL Filtering objects, cannot be used in rules with Mobile Access.
For example, a URL Filtering Facebook application cannot be used for Mobile Access. A new
Facebook web application must be created and authorized as a web application for Mobile
Access. Mobile application objects can be created in the Services & Applications column of a
rule.
To give access to resources through specified remote access clients, create access roles for the
clients and include them in the Source column of a rule. If an access role is defined in the
Source column of a rule, the Identity Awareness Software Blade must be enabled on all
installation targets that the rule applies to. Access roles for remote access will apply to Mobile
Access and IPSec VPN clients. When an access role for a client is in the Source column of a
rule, the rule will apply to traffic that originates from that client.
_____________________
_____________________ 509
Mobile Access Policy Layers and Inline Layers

Mobile Access rules can be included in policy layers and inline layers. Mobile Access must be
enabled for each layer that contains rules with Mobile Access applications. In a policy with
Ordered policy layers, the order of rules in the Rule Base is important because the first rule that
matches the traffic is enforced. Matching is continued in each subsequent layer until the
Mobile Access traffic is matched with a Drop rule or accepted in all layers. In this case, the
matched application for Mobile Access is taken from the last rule matched with a Mobile
Access application.
A Mobile Access inline layer can be configured in any Ordered layer. A bypass rule to accept
Mobile Access traffic must be created in all layers that are placed above the Mobile Access
layer. The bypass rule will match the Mobile Access traffic in the layer and allow the traffic to
move to the next layer until it reaches the Mobile Access Inline layer. Use the access role for
all Mobile Access users in the Source column and Accept in the Action column to create the
bypass rule.
As an inline or sub-policy layer, Mobile Access is matched on the parent rule and then on the
inline layer rule. The matched application for Mobile Access is taken from the last rule
matched with a Mobile Access application. If the matched rule in the inline layer does not
contain a Mobile Access application, the policy will look for a Mobile Access application in
the inline layer’s parent rule.
Best Practices
It is best practice to place Mobile Access rules that authorize applications above rules that
contain a related service. For example, a rule that allows access to a Mobile Access web
application, such as Outlook Web Access (OWA) on HTTPS, should be placed above a rule
that allows or blocks HTTPS. If the HTTPS rule is first, the web application will match that
rule and the policy will not reach the rule that contains the Mobile Access application.
Check Point recommends creating an inline layer for Mobile Access rules. To use the inline
layer effectively, define a parent rule in the main policy layer. The parent rule will match all
Mobile Access traffic and send the traffic to the inline layer. An access role that includes all
Mobile Access users in the Source column is required.
_____________________
_____________________ 510
When creating rules, do not use a Security Gateway as the destination. Use Any or the internal
hosts of relevant applications in the Destination column. This is because Mobile Access
applications are defined in the Services & Applications column. In turn, do not use Any in the
Services & Applications column. To make an application show in the Mobile Access Portal or
Capsule Workspace, it must be a Mobile Access application object that is used explicitly in the
Rule Base.
L a b 6 .1
Managing Mobile Access
_____________________
_____________________ 511
6.1
L
Managing Mobile Access A
B
Define access rights and functions that can be securely operated by remote users within the Check Point
Capsule application.
Ta sks :
• Enable Mobile Access Blade.
• Configure the Check Point Capsule Policy.
• Test Check Point Capsule.
• Demonstrate how to enable Mobile Access for remote users.
• Configure LDAP integration for remote user authentication of Mobile applications.
_____________________
_____________________ 512
Enable Mobile Access Blade

Enable the Mobile Access blade and configure the Security Gateway cluster to allow encrypted remote
Check Point Capsule traffic.
1. Edit the Alpha cluster object (A-GW-Cluster):
Figure 406 — Gateway Cluster Properties - General Properties
_____________________
_____________________ 513
2. In the Network Security tab, select the Mobile Access option. The system displays the Mobile Access
Configuration wizard:
Figure 407 — Mobile Access Configuration
3. Verify that the following categories and sub-categories are all checked:
◦ Web
◦ Mobile Devices
◦ Desktops/Laptops
4. Click Next.
_____________________
_____________________ 514
5. In the Portal URL section, set the Main URL to:
https://203.0.113.1/sslvpn
Figure 408 — Web Portal
6. Click Next.
_____________________
_____________________ 515
7. In the Mail/Calendar/Contacts section of the Applications page, clear the following option:
Mobile Mail (including push mail notifications)
Figure 409 — Applications
8. Click Next, and the system displays the Active Directory Integration page.
_____________________
_____________________ 516
9. Use the following information to create a new domain:

Username: Administrator
Password: Chkp!234
Domain Controller: 192.168.11.101
Figure 410 — Active Directory Integration
10. Click Connect, and the system uses the predefined credentials to connect to the alpha.cp AD.
NOTE
The connection to the AD server may take a few minutes.
_____________________
_____________________ 517
11. Click Next, and the system displays the following:
12. Click Add.
_____________________
_____________________ 518
13. Search for and select the Even group:
_____________________
_____________________ 519
14. Click Next, and the system displays the summary page:
Figure 413 — Mobile Access Configuration Summary
15. Click Finish, to exit the wizard and return to the General Properties page of the cluster object.
17. Click No.
_____________________
_____________________ 520
18. In the navigation pane of the cluster object, select Platform Portal.
19. In the Platform Portal page, modify the Main URL to:
https://203.0.113.1:4434
Figure 415 — Platform Portal
20. Click OK.
_____________________
_____________________ 521
Configure the Check Point Capsule Policy

Define the available applications and access rights of remote Capsule users connecting to your network.
1. In SmartConsole, navigate to the Security Policies tab.

2. In the Shared Policies section, select Mobile Access:
Figure 416 — Shared Policies - Mobile Access
3. Click the following link:
Open Mobile Access Policy in SmartDashboard
_____________________
_____________________ 522
4. The system displays the SmartDashboard Mobile Access Overview page:
Figure 417 — Mobile Access Overview
_____________________
_____________________ 523
5. In the Policy page, use the following information to create a Mobile Access rule:
Users: Even
Application: World_Clock
Install On: A-GW-Cluster
Figure 418 — Mobile Access - Policy
_____________________
_____________________ 524
6. In the navigation pane, expand Applications, and select Web Applications:
Figure 419 — Mobile Access - Web Applications
_____________________
_____________________ 525
7. In the Web Applications page, click the New button. The system displays the following:
Figure 420 — Web Application - General Properties
_____________________
_____________________ 526
8. Name the new web application TestApp:
Figure 421 — Web Application
_____________________
_____________________ 527
9. In the navigation pane, select Authorized Locations.

10. In the Servers section of the page, select A-DMZ from the Host or DNS name drop-down list:
Figure 422 — Web Application - Authorized Locations
_____________________
_____________________ 528
11. In the navigation pane, select Link in Portal.

12. In the Link in Portal page, Use the following information to populate the General tab:
Add Link: Selected

Link Text: TestApp
URL: http://192.168.12.101
Figure 423 — Web Applications - Link in Portal
_____________________
_____________________ 529
13. In the navigation pane, select Additional Settings > Periodic Test.
14. In the Periodic Test page, select the option to run the test every 30 minutes:
Figure 424 — Web Application - Periodic Test
_____________________
_____________________ 530
15. Click OK, and the system adds the newly configured application to the Web Applications list:
Figure 425 — Mobile Access - Web Applications
_____________________
_____________________ 531
16. In the navigation pane, select Applications > File Shares:
Figure 426 — Mobile Access - Applications - File Shares
_____________________
_____________________ 532
17. In the Files Shares page, click New.

18. Name the new application FileShare:
Figure 427 — File Share Application - General Properties
_____________________
_____________________ 533
19. In the navigation pane, select Authorized Locations.

20. In the Servers section of the page, select A-DMZ from the Host or DNS name drop-down list:
Figure 428 — File Share Application - Authorized Locations
_____________________
_____________________ 534
21. In the navigation pane, select Link in Portal.

22. Use the following information to configure the link:
Add Link: Selected

Link Text: Alpha File Share
Path: \\192.168.12.101\Share
Figure 429 — File Share Application - Link in Portal
NOTE
Your instructor may provide a different path, based on your classroom configuration.
Verify that the shared drive on A-GUI allows everyone full access.
_____________________
_____________________ 535
23. Click OK, and the system adds the new application to the list of File Shares:
Figure 430 — Mobile Access - File Shares
_____________________
_____________________ 536
24. In the navigation pane, select Policy.

25. Add the following applications to Rule 1:
TestApp
FileShare
Figure 431 — Mobile Access - Policy
26. Update the policy.

27. Close SmartDashboard.
28. In SmartConsole, publish and install the Alpha Security Policy.
_____________________
_____________________ 537
Testing Check Point Mobile Access

Reconfigure B-GUI to function as a remote client using Check Point Mobile Access and connect to the
Alpha domain to test the newly configured applications.
1. From B-Host, launch a web browser.

2. Use https to authenticate with Check Point Mobile at the following address:
203.0.113.1/sslvpn
Figure 432 — Check Point Mobile Authentication
3. Use the following information to log into Check Point Capsule:
Username: user2
Password: Chkp!234
_____________________
_____________________ 538
4. Click Sign In, and the system displays the applications defined in the Check Point Capsule policy,
which are now available to remote users:
Figure 433 — Check Point Mobile
_____________________
_____________________ 539
5. In the Web section of the page, click the World Clock link. The system displays the following:
Figure 434 — World Clock Application
6. Click the Back button on the browser, to return to the Check Point Mobile page.
_____________________
_____________________ 540
7. In the File Shares section of the page, click the Alpha File Share link. The system displays the
following:
Figure 435 — File Access Settings
_____________________
_____________________ 541
Access files using the following username and password
9. Use the information below to enter the login information:
Username: user2
Password: Chkp!234
10. Click OK, and browse the file share.
END OF LAB 6.1
_____________________
_____________________ 542
Review Questions
1. What is the difference between an SSL VPN and an IPSec VPN?
2. How do Capsule Docs and Capsule Workspace work together?
_____________________
_____________________ 543
C
7
H
P
Threat Prevention T
E
R
Protecting an organization from security threats such as zero-day or Advanced Persistent

Threats (APT) is an important aspect of cyber security administration. The ability to
prevent these and other threats help organizations avoid serious and costly damages. This
chapter provides an overview of Check Point Threat Prevention solutions that protect an
organization from malware and threats targeting company-issued devices, including
smartphones and tablets.
Learning Objectives
• Discuss different Check Point Threat Prevention solutions for dangerous attacks such as zero-day
and Advanced Persistent Threats.
• Understand how SandBlast, Threat Emulation, and Threat Extraction helps to prevent security
incidents.
• Identify how Check Point SandBlast Mobile helps protect an organization from threats targeting
company-issued smartphones and tablets.
_____________________
_____________________ 544
The Threat Landscape

Today’s Threat Landscape continues to evolve at a rapid pace. As a result, Threat Prevention
has become more complex than ever before. Many organizations are challenged to keep up
with the dynamically expanding landscape of threats as well as new trends, such as
consumerization, regulatory compliance, and cloud-based services. Organizations and
individuals alike continue to be victimized and beleaguered by sophisticated cyber attacks at
an increasing rate. Businesses not only need to be concerned about network attacks, but also
attacks directed at end user’s computers, such as viruses and bots. In addition, new malware is
created nearly every second.
Zero-day attacks and Advanced Persistent Threats (APTs) are different kinds of threats that
attackers employ to target businesses. Both use evasion techniques that undermine an
organization’s defenses. Thus, it is important for organizations to implement a multi-faceted
security strategy to expose and combat these and other threats.
Z e r o - D ay At t a c k s
Zero-day attacks target unknown software flaws or vulnerabilities to deliver new variants of
existing malware. They are known to elude the most up-to-date Anti-Malware and Antivirus
solutions. Because there is no security patch yet available for these vulnerabilities, zero-day
attacks give attackers an opportunity to perform their malicious activities within the targeted
company’s network.
Ad va n c e d Pe r s i s te n t T h r e a t s
APTs are designed to infiltrate an organization’s systems over a period of time while evading
detection. These attacks use multiple techniques in several stages and typically appear as small
unrelated events, which, if taken individually, may seem harmless. In some cases, APTs may
employ zero-day threats as an infection vector, but they also exploit existing vulnerabilities.
APTs are known to be launched and funded by nation-states and certain organizations. They
have targeted both large and small organizations. The damage of a successful APT can have a
severe impact on affected companies. The impact can include data breaches, system downtime,
damaged brand reputation, and various costly fees.
_____________________
_____________________ 545
Intrusion Prevention System

The Intrusion Prevention System (IPS) is a component of the Threat Prevention solution.
Whereas the Firewall blocks traffic based on source, destination, and port information, IPS
adds another line of defense by analyzing traffic contents to check if it is a risk to the network.
IPS protects users from malware on legitimate websites, controls network usage of selected
applications, and more.
IPS Profile Setting s a n d P rote c t i o ns

The IPS Software Blade delivers complete and proactive intrusion prevention. It features
thousands of signatures, and behavioral and preemptive protections to deliver complete
intrusion prevention for clients, servers, operating system and other vulnerabilities. Its
detection engine combines multiple defense layers to detect and prevent threats.
In R80.10, the IPS Software Blade is managed by the Threat Prevention policy. As part of the
unified Threat Prevention policy, IPS allows more granularity with multiple protection profiles
per gateway. IPS protections are immediately enforced on network traffic when a Threat
Prevention policy is installed on the Security Gateways. Threat Prevention profiles determine
which protections are activated.
IPS profiles can be imported and exported using the ips_export_import command from
the CLI. Using this command, profile configurations can be copied between management
servers of the same version.
Each IPS profile contains a set of activated protections and instructions for what IPS will do
when traffic inspection matches an activated protection. The IPS library of protections is
constantly updated to stay ahead of emerging threats. Security Gateways with IPS enabled will
get the updates when the policy is installed. To view the latest protections, navigate to the
Threat Tools sections and select IPS Protections.
All IPS protections have dynamic tags which will allow Threat Prevention profiles to
automatically activate or deactivate protections tagged by relevant aspects such as protocols,
affected software, and file types.
_____________________
_____________________ 546
Security Gateways from previous software versions that have IPS and other Threat Prevention
Software Blades enabled, will have their Threat Prevention policy split into two different
layers. In turn, the IPS layer will include the ThreatCloud IPS protections and all other core
IPS protections will remain a part of the Access Control policy installation.
NOTE
Settings for protocol violations, such as “aggressive aging” and “non-
compliant HTTP” are accessed from the Inspection Settings section. To
view this section, navigate to Manage & Settings > Blades.
IPS Tu ning a nd Ma inte na nce

IPS is not a static solution and requires regular tuning and maintenance to make it effective
against evolving threats. Below is an overview on how to properly maintain IPS:
• Verify that there are enough CPU resources to enable IPS.

• Update the IPS package, to ensure that the Security Gateway is updated with the latest
protection signatures.
• Set the default IPS action to Prevent, to enable maximum network protection.
• Set the default IPS action for newly downloaded protections to Prevent.
• Clone the Recommended Profile to create a backup copy. Make sure all changes are
done on the cloned profile. Security requirements for different segments in the network
often depend on the specified traffic types and network objects for each segment. For
deployments with a Multi-Domain Server or several gateways, consider creating
separate IPS policies and perform these steps for each segment.
• During the initial process, enable Troubleshooting mode. In this mode, IPS inspects but
does not block a network's unique traffic. Even if all protections are set to Prevent, the
gateway only detects possible threats and generates logs for the traffic.
• Use the Follow Up option to help the analysis and tuning of new protections in the
future.
• Assign the active profile to applicable gateways and set the gateway to bypass IPS
inspection when it is under heavy load. This is to ensure that IPS analysis does not
affect on-network traffic.
• Install policy on the gateways, because policies are not automatically deployed.
• After installing the policy, IPS will begin inspecting the traffic and generating logs.
Collect logs for at least a week or two and then review the logs to decide which
protections to run in Protect or Detect mode, and which ones require further fine-tuning
and analysis.
• Disable Troubleshooting mode for IPS Software Blade to protect the network.
• Change the settings for Updates policy. Configure updates for Newly downloaded
protections and then set to Detect. When new IPS protections are deployed, they are set
to Detect mode.
_____________________
_____________________ 547
• Clear the follow up and newly downloaded flags for all protections that are reviewed
during the tuning process.
• Tune the new IPS protections that are downloaded twice a month and look for changes
in the behavior of the ones already tuned.
• Monitor Security Gateway performance and configure the applicable settings to
provide the best network security and performance.
NOTE
If a specific IPS profile is in Detect Only Mode for troubleshooting, it will
not block malicious traffic.
L a b 7.1
Understanding IPS Protections
_____________________
_____________________ 548
7.1
L
Understanding IPS Protections A
B
The next step is to modify IPS protections so that you can configure your IPS policy to meet the specific
challenges of the network, such as SQL Injections. Remember, IPS is considered a pre-infection blade, and
is deployed to combat threats at the perimeter.
Ta sks :
• Configure a new default Protection profile.
• Configure the IPS Demo Tool.
• Test IPS enforcement.
• Modify Profile settings.
• Modify the cloned Protection profile.
• Demonstrate how Threat Prevention profiles affect IPS inspection on a Check Point Security
Gateway.
• Demonstrate how to modify IPS protections and customize enforcement profiles.
_____________________
_____________________ 549
Configuring the Protection Profile

Before you can determine how specific traffic is handled by the two pre-configured IPS profiles, re-
configure the settings to protect all interfaces on the gateway.
1. Edit the Alpha Policy and change the DMZ rule to be Any service.
Figure 436 — Alpha Policy - DMZ Rule
_____________________
_____________________ 550
2. From the Firewall tab, edit the Alpha Security Gateway Cluster object:
3. Select the IPS option, and the system displays the following message:
Figure 438 — IPS First Time Activation
_____________________
_____________________ 551
According to the Threat Prevention policy
5. Click OK.
6. In the navigation tab, select the IPS branch:
Figure 439 — Check Point Gateway - IPS
_____________________
_____________________ 552
7. In the Bypass Under Load section, select the following option:
Bypass IPS inspection when gateway is under heavy load
Figure 440 — Check Point Gateway - IPS Configured
8. Click OK, and the system displays a message regarding Office Mode pool definition.
9. Click OK to clear the message.
_____________________
_____________________ 553
10. In the navigation pane, select Mobile Access > Office Mode.
11. In the Office Mode page, select the following option:
Do not offer Office Mode
Figure 441 — Mobile Access - Office Mode Configured
12. Click OK.
_____________________
_____________________ 554
13. In the navigation pane of the Security Policies view, right-click Access Control > Policy.
14. Click Edit Policy, and the system displays the following window:
Figure 442 — Policy
_____________________
_____________________ 555
15. Clear the following options:

◦ QOS
◦ Desktop Security
16. Confirm that only the following options are selected:
◦ Access Control
◦ Threat Prevention
Figure 443 — Policy Configured
17. Click OK.
_____________________
_____________________ 556
18. In the navigation pane, select Threat Prevention > Policy:
Figure 444 — Threat Prevention Policy
_____________________
_____________________ 557
19. In the navigation pane, select Profiles:
Figure 445 — IPS - Profiles
20. In the profiles page, select the Basic profile.

21. Next, click the Clone icon. The system clones the Basic profile:
Figure 446 — Clone Object
_____________________
_____________________ 558
22. Name the clone Alpha_Basic.
NOTE
it is best practice to modify clones of the default profiles, rather than edit the
originals, in case you need to revert back to them at some point.
23. Select the Alpha_Basic profile.

24. Click Edit, and the system displays the cloned profile.
25. In the Activation Mode section of the page, select Detect for each mode:
Figure 447 — Profiles
NOTE
By setting the Activation Mode to Detect, rather than Prevent, the Security Gateway
will monitor and log malicious activity but will not block the traffic.
26. Click OK.
_____________________
_____________________ 559
27. In the navigation pane, select the Threat Prevention > Policy branch:
Figure 448 — Profile Properties - IPS Policy
28. Review the policy settings.

29. Notice that the IPS protections are not included in the default Recommended_Profile.
30. Right-click the Action column of Rule 1.
_____________________
_____________________ 560
31. Select Alpha_Basic from the drop-down list.
Figure 449 — Action Menu
_____________________
_____________________ 561
32. Publish and install the Alpha Threat Prevention and Access Control policies:
_____________________
_____________________ 562
Configuring the IPS Demonstration Tool

Configure the IPS Demo Tool to test the Check Point IPS software blade.
1. Power on the Attacker virtual machine:
Figure 451 — IPS Demo Tool
2. In the Virtual Machine Settings, verify that the only network interface configured for the Attacker is
connected to the External network (vmnet8).
_____________________
_____________________ 563
3. To start the IPS demonstration tool on the newly configured Attacker virtual machine, click the IPS
icon from the toolbar at the bottom of the screen. The system displays the following:
Figure 452 — IPS Demo Tool Launched
NOTE
The default network configuration for the tool must be changed to match our
environment. Do this, after configuring eth0.
4. Type 0, and press Enter. The system displays the following:
Figure 453 — Demo Tool Network Settings Configuration
5. Type the following at the prompt:
203.0.113.37
_____________________
_____________________ 564
6. Press Enter, and the system displays the following:
203.0.113.254
203.0.113.171
_____________________
_____________________ 565
203.0.113.254
Figure 457 — IPS Tool - Main Menu
13. Use the table below to verify that the network configuration information displayed by the tool is
correct:
Attacker IP Address: 203.0.113.37

Attacker Default Gateway: 203.0.113.254
Target IP Address: 203.0.113.171
Target Default Gateway: 203.0.113.254
14. While keeping the IPS Demo Tool open, open a terminal window.
_____________________
_____________________ 566
15. Type the following command, and press Enter:
ifconfig -a
Figure 458 — Terminal Window
16. The system should show eth0 as configured with an incorrectly defined IP address or subnet mask.
17. To configure the Attacker virtual machine interface, type the following and press Enter:
ifconfig eth0 203.0.113.37 netmask 255.255.255.0
_____________________
_____________________ 567
18. To configure the default route for the Attacker virtual machine, type the following, and press Enter:
route add default gw 203.0.113.254 eth0
Figure 459 — Terminal
19. To help identify network issues that may arise, initiate a constant ping from the Attacker to A-DMZ:
Figure 460 — Ping
NOTE
If the ping fails, you can quickly re-IP the interface and add the default route back to
the Attacker’s configuration.
_____________________
_____________________ 568
Testing the Default Protections

Test the current protection settings for the Check Point IPS software blade.
1. In the IPS Demo Tool, type 2, and press Enter. The system displays the Attacker menu:
Figure 461 — Attacker Menu
NOTE
Do not run the Run all option 0, as it will change the IP address.
2. Type 1, to select the Network Security category.

3. Press Enter.
4. Type 0, and press Enter. The system asks you to select an execution mode.
5. Type 2, and press Enter. The system asks you to define the number of attacks in this sequence.
6. Type 100, and press Enter. The system runs the attacks in the selected category, and presents the
Attacker menu when the attack sequence is completed.
_____________________
_____________________ 569
7. From the Logs & Monitor tab, verify that the traffic is being detected.
8. Search field, click Blade > IPS to view the IPS related traffic logs:
Figure 462 — IPS Traffic Logs
9. Confirm that you see IPS traffic as Detected.
_____________________
_____________________ 570
Modifying the Protection Profile Settings

Now, configure IPS to protect the network from attacks, rather than simply detect them.
1. In the navigation pane of the Security Policies view, select Threat Prevention > Policy:
Figure 463 — Threat Prevention - Policy
2. Edit the Alpha_Basic profile, and the system displays the Profiles window.
_____________________
_____________________ 571
3. In the Activation Mode section of the page, select Prevent for all Activation Modes:
Figure 464 — Profiles - General Policy
4. Click OK, to approve the change and clear the window.

5. Publish and install the Alpha Threat Prevention Policy.
6. From the Attacker virtual machine, return to the Attacker main menu.
7. Type 1, and press Enter. The system displays the Network Security category:
Figure 465 — Network Security Category
_____________________
_____________________ 572
8. Type 1, and press Enter. The system displays the IP and ICMP category:
Figure 466 — IP and ICMP Category
9. Type 5, and press Enter. The system displays the Packet Sanity feature:
Figure 467 — Execute Packet Sanity Attack
10. Press Enter, and the system executes the selected packet sanity attack on the A-GUI virtual machine:
Figure 468 — Trailing Data Attack
_____________________
_____________________ 573
11. From the A-GUI virtual machine, view the IPS logs in the Logs & Monitor tab:
Figure 469 — Logs & Monitor - IPS Logs
_____________________
_____________________ 574
12. Open an IPS record:
Figure 470 — Log Detail
13. Review the record and consider the following questions:

◦ What is the threat severity level?
◦ What is the performance impact of this inspection and action?
◦ What is the protection name?
14. Close the record.
_____________________
_____________________ 575
15. Next, navigate to the Security Policies view.

16. Select Threat Prevention > Policy.
17. Now, enforce the Recommended_Profile:
Figure 471 — Recommended_Profile Enforced
18. In the navigation pane, select Profiles.
_____________________
_____________________ 576
19. View the Recommended_Profile.

20. Select the following Blade Activation option:
IPS
21. Clear the following Blade Activation option:
Threat Extraction
NOTE
In a production environment, it’s best practice to clone a profile and make any
changes in the clone. This allows you to revert back to the default profile settings, if
necessary.
_____________________
_____________________ 577
23. From the Attacker virtual machine, return to the Attacker menu:
24. Type 2, and press Enter. The system displays the Application Intelligence category.
Figure 473 — Application Intelligence Menu
25. Type 2, and press Enter. The system displays the MS-RPC category.
26. Type 1, and press Enter. The system displays the MS-RPC Over CIFS category.
27. In the MS-RPC Over CIFS sub category, select 1, and press Enter. The system displays the following:
Figure 474 — Non-Compliant CIFS Attack
_____________________
_____________________ 578
28. Press Enter, and the system executes the non-compliant CIFS attack:
Figure 475 — Non-Compliant CIFS Attack Executed
29. Press Ctrl + C to stop the attack.

30. In the Logs & Monitor view of SmartConsole, locate the most recent blocked traffic.
NOTE
If you are not susceptible to a specific attack, for instance, if you did not have CIFS
files on your network, you could allow it because it cannot be successful.
31. Notice that the traffic is not inspected or blocked by IPS.
NOTE
The related protection is inactive in the Recommended profile, so the traffic is
dropped by the Cleanup Rule on the firewall. By leaving some protections inactive in
the profile, especially for low-risk threats, the firewall load is reduced.
_____________________
_____________________ 579
Working with Logs & Monitor 

to Investigate Threats
Use the Logs & Monitor tab in SmartConsole to investigate unusual IPS related threat traffic.
1. In the navigation pane of Logs & Monitor view, review the IPS logs.
2. Double-click a record, to view it’s details:
3. Review the options listed in the Actions section of the page.

◦ Could these actions be used to attempt to identify the source of the attack?
◦ In what situations would you consider using any of these actions?
_____________________
_____________________ 580
Modifying an Existing Protection Profile

Make changes to the protections to prevent and detect specific traffic that you may be concerned about
infiltrating your network.
1. In SmartConsole, select the Security Policies view.

2. Select Threat Prevention > Policy:
Figure 477 — Threat Prevention Policy
_____________________
_____________________ 581
3. In the navigation pane of the IPS tab, select IPS Protections.

4. Click the View button:
Figure 478 — IPS Protections
5. Click Show Profiles, and the system displays the Show Profiles window.
_____________________
_____________________ 582
Specific IPS enabled profiles
7. Select both of the following options:
Alpha_Basic
Strict
Figure 479 — Show Profiles Configured
_____________________
_____________________ 583
8. Click OK, and the system displays the modes of the two selected profiles:
Figure 480 — IPS Protections Modified
9. Review the first few protections on the page, and consider the following:
◦ Are there protections that are not active on any profile?
◦ Can you see differences between the Default and Recommended profiles?
◦ Which profile is more strictly enforced (more active protections)?
◦ How would you expect the different profiles to affect the performance of the gateway?
10. Sort the protections by descending, alphabetical order.
_____________________
_____________________ 584
11. Select the following protection. It is Active in the Default Profile but Inactive on the Recommended
profile:
CVE-2009-1761
Figure 481 — IPS - Protections
_____________________
_____________________ 585
12. Double-click the Selected protection, and the system displays a list of associated IPS profiles:
Figure 482 — Associated IPS Profiles
13. Select the Strict profile.

14. Click the Edit button, and the system displays the following:
Figure 483 — Protection Details
_____________________
_____________________ 586
15. Use the information below to configure the Protection Details window:
Main Action: Override IPS Policy with Prevent

Track: Log
Capture Packets: Selected
Figure 484 — Protection Settings Configured
16. Click OK.

17. Click Close, and the protection now shows Prevent in the Strict:
_____________________
_____________________ 587
Figure 485 — Protection Details - General
18. In the search field of the Protections page, enter the following:
sql injection
_____________________
_____________________ 588
19. Press Enter, and the system displays all projections relating to SQL Injections:
Figure 486 — IPS - Protections - Search Results
20. Select the following protection:
Oracle Database Server Multiple Procedures
21. Double-click the Inactive icon in the Strict column.
_____________________
_____________________ 589
22. Use the information below to configure the protection:
Main Action: Override IPS Policy with Detect

Track: Log
Capture Packets: Cleared
Figure 487 — Protection Settings Configured
23. Click OK, and the system displays the following message:
_____________________
_____________________ 590
25. Click Close, and the system now displays Detect, rather than Inactive for the modified protection:
Figure 489 — IPS - Protections Modified
NOTE
You can also right-click the profile field and select Detect or Prevent, without having
to edit the protection directly.
_____________________
_____________________ 591
END OF LAB 7.1
_____________________
_____________________ 592
Geo-Protection
Geo-Protection enforces or monitors traffic based on the source or destination country.
Country information is determined by comparing the IP address in the packet against the IP-to-
country database. Private IP addresses are always allowed unless explicitly specified as
blocked on the other side of the connection. Check Point control connections, for example
those between Security Gateways and Security Management Server, are always allowed
regardless of the Geo-Protection policy.
You must have a valid IPS contract and a Software Blade license for each Security Gateway
that enforces Geo-Protection.
Figure 490 — Geo Policy
The IP Address to Country Database

The IP-To-Country database is downloaded to the Security Gateway from a Check Point data
center. To make sure that the database is up-to-date, the Security Gateway should be connected
to the Internet. If the Security Gateway requires a proxy to access the Internet, the proxy must
be defined in SmartDashboard.
_____________________
_____________________ 593
Log Aggregation by Country

By default, Geo-Protection logs are aggregated, which means that a single log entry is
generated per aggregation interval, for every country that is part of the Policy for Specific
Countries. Logs related to other countries are aggregated to a single log entry.
It is possible to turn off log aggregation by country. In that case, a log is created for every
connection tracked. Turning off log aggregation by country may significantly increase the
number of generated logs and increase CPU usage on the Security Gateway.
You can create a Geo Protection policy with exceptions to allow legitimate traffic through
while blocking or monitoring traffic from untrusted sources or by country. Users can monitor
activity using SmartEvent.
L a b 7. 2
Deploying IPS Geo Policy
_____________________
_____________________ 594
7.2
L
Deploying IPS Geo Protection A
B
Spoof a source address to test the Geo Protection feature of IPS.
Ta sks :
• Modify Anti-Spoofing settings.
• Configure IPS Geo Protection.
• Test IPS Geo Protection features.
Pe r for ma n c e Ob j ec t ive :
• Demonstrate how geographic location can be used to define a security posture.
_____________________
_____________________ 595
Modifying Anti-Spoofing Settings

Disable anti-spoofing measures on the Security Gateway so that you can spoof addresses to make them
appear to be coming from a country from which you want to block traffic.
1. From SmartConsole, edit A-GW-Cluster:
2. Select the following Network Security options:

◦ Application Control
◦ URL Filtering
_____________________
_____________________ 596
3. In the navigation pane, select Network Management:
Figure 492 — Check Point Gateway - Topology
4. Edit the external interface (eth3).

5. In the Topology section, click Modify.
_____________________
_____________________ 597
6. Use the information below to configure the Anti-Spoofing section of the tab:
Anti-Spoofing Action: Detect

Spoof Tracking: None
Figure 493 — Interface Properties - Topology
NOTE
Do not disable anti-spoofing measures in a production environment. In this lab, anti-
spoofing is disabled here to spoof traffic needed to demonstrate IPS features.
_____________________
_____________________ 598
7. Click OK, to change the new Anti-spoofing setting:
8. Click OK, to close the Security Gateway object.

9. Repeat the previous step for every interface configured on the Alpha Security Gateway Cluster.
_____________________
_____________________ 599
Configuring IPS Geo Protection

Configure Geo Protection measures to block traffic emanating from and traveling to specific countries.
1. From SmartConsole, select the Security Policies view.

2. In the navigation pane, select Geo Policy:
3. In the navigation pane, expand the Geo Policy option.

4. Click Gateways.
_____________________
_____________________ 600
5. Double-click the A-GW-Cluster object, to view the name of the Geo Policy being enforced:
6. Note the name of the enforced policy.

8. In the Geo Policy pane, verify that the Edited Policy is the same as the enforced policy that you just
noted in the steps above.
9. Set the Activation Mode to Active.
_____________________
_____________________ 601
10. Click the Add button, and the system displays the following:
Figure 497 — Geo Protection
11. Use the following information to configure the Geo Protection window:
Country: Iran
Action: Drop
Direction: From and To Country
Track: Log
Figure 498 — Geo Protection Configured
_____________________
_____________________ 602
12. Click OK, and the system adds Iran to the list of policy specific countries:
_____________________
_____________________ 603
13. Add other countries to the list with specific policy settings, such as Allowing traffic to and from Israel
and the United States but blocking traffic from China:

15. Install the Alpha Access Control and Threat Prevention policies.
16. From the Attacker virtual machine, open a terminal session type the following command at the prompt:
nmap -sS -S 195.170.163.4 -e eth0 -P0 203.0.113.171
17. Press Enter, to generate traffic to A-DMZ from a spoofed address.
_____________________
_____________________ 604
18. From the Logs & Monitor tab view the Geo Policy logs:
Figure 501 — SmartConsole - Logs & Monitor
_____________________
_____________________ 605
19. View the details of a Geo-Protection item in the logs:
Figure 502 — Log Detail
20. Reconfigure anti-spoofing on all A-GW-Cluster interfaces.
END OF LAB 7.2
_____________________
_____________________ 606
Antivirus
The Check Point Antivirus Software Blade protects the network from malware attacks, such as
worms, backdoors, viruses, and trojans. Using threat intelligence from ThreatCloud, Antivirus
generally deals with threats coming into the organization’s network. It scans incoming files
like PowerPoint, Word, or Excel files for malicious signatures. It then updates the ThreatCloud
repository for any newly detected malware found in the system.
Aside from monitoring and classifying files, Antivirus also blocks access to websites with
known connections to malware. The Security Gateway uses its caching mechanisms to verify
URLs. If the Security Gateway is unable to verify the URL, the Antivirus blade sends the URL
to ThreatCloud for verification. If found malicious, Antivirus blocks access to the URL before
any damage can take place.
_____________________
_____________________ 607
Anti-Bot
A bot is malware which uses stealth mechanisms to remain hidden from Antivirus solutions.
They can arrive into a computer as an infected email attachment or as the result of a drive-by
download from a malicious website.
Once infection occurs, the bot takes control of the computer by connecting to a Command &
Control (C&C) server and awaits instructions from attackers who can remotely execute
routines. These routines include data theft, spam distribution, and other activities that consume
significant computer resource and bandwidth. Attackers also use the bot-controlled computer
to target and infect other computers, in effect creating a botnet. An anti-bot tries to prevent
damages by blocking communications from the C&C server.
The Anti-Bot Software Blade identifies bot-infected machines using the multi-tier ThreatSpect
engine to analyze network traffic. ThreatSpect is a discovery technology that has up-to-minute
update feeds from ThreatCloud. The engine is installed on the gateway and performs three
important tasks:
• Performs a reputation check to verify the IP addresses and drop zones of known C&C
sites with real-time updates of an address list. Security Gateways are constantly
updated with the latest list. However, the ThreatSpect engine may query ThreatCloud to
get more updates. ThreatSpect engine also caches this information to minimize time to
deploy updates.
• Reviews the network signatures of over 2,000 bot families that were detected
previously. It matches the traffic’s behavior with known bot behavioral patterns and
blocks communication to C&C sites. This ensures no sensitive information is stolen or
leaked.
• Searches for suspicious activity by monitoring outgoing mail traffic and
communication patterns. For example, it analyzes outgoing mail to identify spam sent
from the organization. It also monitors if a computer participates in Denial of Service
(DoS) attacks.
Once a bot-infected machine is identified, the ThreatSpect engine blocks outbound

communication to C&C sites to protect sensitive data. However, you will still need
remediation to remove the bot from the network.
L a b 7. 3
Reviewing Threat Prevention Settings and Protections
_____________________
_____________________ 608
7.3
L
Reviewing Threat Prevention A
Settings and Protections B
Configure your environment to connect to the Internet. Then, review specific threats and protection details.
Once you have done that, test the enabled Anti-Bot and Antivirus settings by attempting to download a test
file.
Ta sks :
• Review Threat Prevention settings and protections.
• Test EICAR file access.
• Identify specific threat protections used by Check Point Threat Prevention.
• Demonstrate the Anti-bot and Antivirus features of R80.10.
_____________________
_____________________ 609
Review Threat Prevention Settings 

and Protections
Verify that you have enabled Anti-Bot and Anti-Virus software blades, then investigate the protections.
1. On A-GUI, edit the A-GW-Cluster object:
_____________________
_____________________ 610
2. In the Network Security tab, select the Anti-Bot option, and the system displays the following:
Figure 504 — Anti-Bot and Anti-Virus
3. Verify that the following option is selected by default:
According to the Anti-Bot and Anti-Virus policy
4. Click OK.
5. Next, select Anti-Virus.
_____________________
_____________________ 611
6. Verify that the General Properties page of the cluster object appears as follows:
Figure 505 — Gateway Cluster Properties - General Properties
_____________________
_____________________ 612
7. In the navigation pane, select Anti-Bot and Anti-Virus:
Figure 506 — Check Point Gateway - Anti-Bot and Anti-Virus Configured
8. In the Check Point ThreatCloud Information section, verify that the following option is selected:
Share anonymous attack information with Check Point ThreatCloud.
9. Click OK.
_____________________
_____________________ 613
10. In the navigation pane, select Threat Prevention > Policy:
Figure 507 — Threat Prevention - Overview
_____________________
_____________________ 614
11. In the navigation pane, click Protections:
Figure 508 — Threat Prevention - Protections
_____________________
_____________________ 615
12. In the list of protection categories, select Malicious Activity.

13. In the Protections pane, select the Activations tab:
Figure 509 — Protections - Activations
14. Note the default actions for Threat Prevention profile enforcement.
_____________________
_____________________ 616
15. Right-click and select Prevent for all profiles:
Figure 510 — Malicious Activity Category Edited
16. Note how the enforcement for all profiles changed to Prevent.
18. Identify which protection profile is being implemented.
_____________________
_____________________ 617
19. Right-click Alpha_Basic and select Edit, to view its details:
20. Click Close.

_____________________
_____________________ 618
22. In the Policy page, click the Install Policy button. The system displays the Install Policy window:
23. Verify that both the Access Control and Threat Prevention policies are selected for install.
24. Click Install, and the system installs the Threat Prevention policy on the Security Gateway cluster
members.
_____________________
_____________________ 619
Testing EICAR Access

Now that you have basic protections in place, test your gateway’s current Threat Prevention settings.
1. On A-Host, launch a web browser, enter “eicar file download” into the search field, and press Enter.
2. Navigate to the EICAR file download page:
Figure 513 — EICAR Download Page
NOTE
The EICAR file is a harmless file used to test anti-virus software.
_____________________
_____________________ 620
3. Use HTTP to attempt to download and save the zip versions of the EICAR file to the desktop of A-
Host. Your attempts should be blocked:
Figure 514 — Page Blocked
_____________________
_____________________ 621
4. Once the download attempts are complete, identify the Threat Prevention traffic in the Logs & Monitor
tab of SmartConsole.
◦ Why didn’t both EICAR downloads show up as the same type of traffic?
◦ Accept or Detect or Drop?
◦ Why was one of the downloads successful, if the EICAR file simulates a virus?
◦ Did the gateway identify the “virus” even when it was zipped?
◦ Why was the traffic allowed, if the Security Gateway identified the file as a virus?
◦ Did the Security Policy function as designed?
END OF LAB 7.3
_____________________
_____________________ 622
Sandboxing
Sandboxing is a pre-eminent solution which is used to catch zero-day attacks and APTs. It
allows a file to be hosted and executed in a secured environment, separate from the network.
The file is then observed for suspicious routines. If the file displays any type of malicious
behavior, it is prevented from being released into the network. If found safe, the file will be
released to the network. There are currently two types of sandboxing: OS-level and CPU-level.
O S - L eve l S a n d b ox i n g
Also known as traditional sandboxing, OS-level sandboxing emulates a standard operating
system in an isolated environment to execute and screen files. This ensures that suspicious files
are safely isolated from the company’s production network.
The sandbox simulates the files as if the actual user opened it and monitors it for malicious
routines. If the file shows any suspicious behavior, the sandbox updates Threat Cloud for threat
intelligence sharing and deleting the file.
Traditional Sandboxing Evasion Methods

Attackers have created several tactics to avoid sandbox detection. Some of these known
techniques include:
• Delaying launch of a payload, wherein malicious code executes minutes, hours, days,
or even years after the file has been opened.
• Searching for virtual machine indicators, such as scanning registry keys, running
processes, or disk size to identify a sandbox environment.
• Checking for human interaction activities that are difficult to replicate in a virtual
environment, including page scrolling and mouse clicks.
• Operating system fingerprinting to identify systems, services, and hardware and
software configurations that may be available for exploitation.
C P U - L eve l S a n d b ox i n g
CPU-level sandboxing addresses the limitations of traditional sandboxing by performing CPU-
level inspection to monitor any indication of an exploit method executed in CPU instruction
codes (sets). This solution takes advantage of the fact that although attackers have plenty of
vulnerabilities and malware to choose from, they can only use a handful of exploit methods.
_____________________
_____________________ 623
The image below shows a typical CPU-Level attack scenario:
Figure 515 — Four Stages of a CPU-Level Attack
1. Finding Vulnerability — One or more vulnerabilities are discovered in the operating sys-
tem code or widely used applications like Internet browsers and PDF readers. Potentially,
there can be thousands of software vulnerabilities in a system. By exploiting any of these
vulnerabilities, attackers will inject their logic into the system and trigger an attack.
2. Using an Exploit Method — Exploits allow the injected logic to manipulate the target
system and run the malicious code. This requires overcoming built-in security controls
implemented by the operating system and the CPU, such as Data Execution Prevention
(DEP) and Address Space Layout Randomization (ASLR). This is the stage where CPU-
level sandboxing examines files for an exploit method and catches it before the shellcode
is executed.
3. Running a Shellcode — A shellcode is a small payload, typically embedded into a file or
web page. After leveraging one or more exploit methods, the attacker then plants the shell-
code into executable memory to trick the system to run it. Retrieving the actual malware,
the shellcode then places it on the infected system.
4. Running the Malware — Executing the malware completes the infection. This is the
stage where traditional sandboxing discovers if a file shows any suspicious routines. How-
ever, it is at this stage where evasion techniques usually manifest, such as when a file
delays execution of its routines in an attempt to hide from the sandbox.
_____________________
_____________________ 624
Check Point SandBlast Zero-Day Protection

SandBlast Zero-Day Protection is Check Point’s solution for zero-day attacks, APT and similar
threats. It is complemented with a suite of attack visibility tools, such as the Logging and
Monitoring view of SmartConsole and SmartEvent. These tools aid in forensics and help to
reveal how detected malware would have behaved, had it been allowed to run.
Check Point offers SandBlast technology solutions for private network and public cloud
settings. To protect end user systems, Check Point expands SandBlast protection with the
SandBlast Agent.
SandBlast Components
SandBlast has several functional components that work together to ensure that attacks are
prevented in real-time. These components include:
• Threat Emulation
• Threat Extraction
• Threat Cloud
• Mail Transfer Agent
SandBlast Threat Emulation

The Threat Emulation engine is the sandbox component of SandBlast. It protects the network
against advanced and zero-day attacks by performing both CPU-level and OS-level inspection
of files. Threat Emulation hosts the file in a sandbox environment and examines it on a CPU-
level for any indication of exploit activity. This inspection stops the file from executing any of
its routines, particularly those that attempt to evade detection.
SandBlast Threat Extraction

The SandBlast Threat Extraction engine examines document files and removes any active
contents from the document, while Threat Emulation runs the file in its secured environment.
Active contents include objects such as JavaScript, macros, and links, which cyber criminals
may use to insert their malicious code.
While Threat Emulation runs and inspects files, Threat Extraction provides users with a
sanitized, reconstructed document using only safe elements. This ensures business continuity
and end-user productivity without compromising security.
Threat Extraction is typically used for incoming emails only; however, it can be used for
outgoing emails as well. It supports widely used document file types, such as PDF and MS
Word documents.
_____________________
_____________________ 625
Threat Extraction and Threat Emulation both work together to secure production networks
while ensuring that business will proceed as usual. However, each component works
differently.
The following table details the differences between Threat Extraction and Threat Emulation:
Threat Extraction Threat Emulation

Preemptively removes possible malicious Proactively detects threats
content
Always delivers a file Delivers file if no threats are detected
Works on MS Office and PDF files Works on MS Office, PDF, executables, and
archive files
Delivers PDF version of original file or Delivers file with original content
original format with active content remove
Takes less than a second to complete Takes minutes to complete (less than 3
minutes)
Assumes that all active content is potentially Detects threats and provides a detailed report
malicious of discovered threats
Disables any active functionality in Delivers full functionality if no threats are
documents regardless of its intent detected
Table 11: Comparison of SandBlast Threat Extraction and Emulation
Threat Cloud
Check Point Threat Cloud is the back-end platform for intelligence sharing for all Check Point
products and services. This platform consolidates big data, external feeds, and shared learning
from various sources, such as:
• Signature and reputation data from different Check Point systems

• External intelligence sources, along with consumer and endpoint data SandBlast agents
• Data and research from Check Point’s Vulnerability Research and Incident Response
teams
Threat Cloud ensures that SandBlast is up-to-date with information to help protect an
organization’s network against the latest threats.
_____________________
_____________________ 626
Mail Transfer Agent

Mail Transfer Agent (MTA) functionality in Check Point Security Gateways ensures that full
emulation occurs without any disruption to the business, particularly in the flow of email.
Enabling MTA prevents the possibility of email server timeout during file emulation and
manages the emulation of SMTP traffic. MTA completes and closes the connection with the
source email server and then sends the file for emulation.
With MTA enabled, the gateway manages SMTP traffic via port 25 and holds external emails
with potentially malicious attachments. After emulation is complete, MTA sends the email to
the server in the internal network. The detailed process is shown below:
Figure 516 — MTA Functionality Work Flow
1. MTA acts as an SMTP server by receiving email from the sender and closing the
connection after the complete email and the attachment is received.
2. MTA holds the email until Threat Extraction reconstructs a clean copy of the attachment.
3. MTA sends the attachment to the Threat Emulation sandbox environment for inspection.
4. MTA stores the original attachment in the Security Gateway and modifies the email by
attaching the clean copy of the attachment, along with a link to the original attachment.
5. MTA then forwards the modified email to the mail server, which then sends it to the
intended recipient.
6. If the attachment is found to be malicious after inspection, Threat Emulation deletes the
file, logs the event, notifies the administrator, and updates Threat Cloud.
NOTE
To enable MTA functionality in the Security Gateway, activate the Threat
Prevention Software Blade package which includes Antivirus, Anti-Bot,
and either Threat Extraction or Threat Emulation.
_____________________
_____________________ 627
SandBlast Appliances
SandBlast appliances can be deployed in two modes:
• Inline or Prevent — As a Mail Transfer Agent (MTA) and as part of the web traffic
flow.
• Detect Only — A SPAN port to receive a copy of traffic.
A SandBlast appliance includes the Anti-Bot, Antivirus, Threat Emulation and Threat
Extraction Software Blades. However, it is recommended to use the appliance exclusively for
OS-level sandboxing and CPU-level detection.
Organizations that prefer not to allow files to be sent outside of the corporate network or those
that have a large centralized network architecture requiring high performance and low latency,
may opt for deploying a SandBlast private cloud option. Solution architectures vary depending
in cases such as:
• Customers with Check Point Security Gateways running R77 and above, and with the
Next Generation Threat Prevention (NGTP) package activated.
• Customers with Check Point gateways below R77 or no NGTP package, or with third
party gateways.
• Customers that are evaluating SandBlast prior to installing it.
_____________________
_____________________ 628
Prevent Mode
When a SandBlast appliance is deployed in Prevent mode, traffic (or an attached file) is sent to
the appliance before it is allowed to enter the internal network. This deployment requires that
the MTA feature in the Security Gateway is enabled.
Prevent mode is also recommended for Proof-of-Concept (POC) scenarios where the customer
is using either a third-party Firewall or an older version of Check Point software. Customers
with no Next Generation Threat Prevention (NGTP) package would also benefit from this type
of deployment.
Figure 517 — SandBlast Appliance in Prevent Mode
_____________________
_____________________ 629
The detailed workflow of the SandBlast appliance in Prevent mode architecture is:
1. The attacker sends an email with an attached file.

2. The Check Point Security Gateway with MTA enabled holds the email.
3. Threat Extraction reconstructs a safe copy of attachment, and forwards it to the mail
server. The recipient receives the email and safe copy without any delay.
4. Threat Emulation forwards the attachment to OS-level sandboxing and CPU-level detec-
tion within the SandBlast Appliance.
5. The SandBlast appliance inspects the file. If the file is found malicious, SandBlast updates
ThreatCloud with the information. The file is marked infected and deleted from the MTA
holding area of the Check Point Security Gateway.
6. If the SandBlast appliance determines the file is harmless, the original file is released to
mail server.
_____________________
_____________________ 630
Detect Only Mode

For users who want to perform an evaluation first, the SandBlast appliance can be configured
to Detect Only mode or SPAN port deployment to monitor zero-day attacks. In this scenario,
duplicate traffic is sent to the SandBlast appliance while real traffic enters the internal network,
passing through the Security Gateway. Using the MTA feature is not required in this
deployment.
Figure 518 — SandBlast Appliance in Detect Only Mode
The SandBlast appliance Detect Only mode architecture works as follows:
1. An attacker sends the email with an attachment.

2. The Check Point Security Gateway or a third-party gateway uses a mirror or TAP port to
duplicate network traffic, sending it to the SandBlast appliance.
3. The gateway performs a traditional security inspection and permits traffic to enter the net-
work.
4. The user receives the original email without any delay.
5. Threat Emulation forwards the attached file to the SandBlast appliance for OS-level sand-
boxing and CPU-level detection. If the file is found malicious, SandBlast updates Threat-
Cloud with the new malware and the system administrator is notified of the infection.
_____________________
_____________________ 631
SandBlast Cloud
SandBlast Cloud performs OS-level sandboxing and CPU-level detection in a Check Point
controlled, public cloud infrastructure. This solution requires no new hardware and is ideal for
users who want to use their existing gateways, have a globally distributed network, or have
high usage of cloud-based or Software-as-a-Service (SaaS) applications. The detailed
workflow of the SandBlast Cloud architecture is as follows:
1. An email is sent with a malicious attachment.

2. Check Point Security Gateway with enabled MTA holds the email.
3. Threat Extraction constructs a clean copy of the attachment in PDF format and forwards it
to the mail server. The recipient receives the email with the PDF copy without delay.
4. Using the MTA service, Threat Emulation forwards the email to SandBlast Cloud for OS-
level sandboxing and CPU-level detection.
5. If the file is identified as zero-day malware, SandBlast Cloud updates ThreatCloud with
the new information. The file is marked as infected and deleted from the MTA holding
area in the Security Gateway.
6. If SandBlast Cloud determines the file to be harmless, it is then released to the mail server.
Figure 519 — SandBlast Cloud Architecture
_____________________
_____________________ 632
Check Point SandBlast Cloud provides zero-day protection for organizations transitioning to
cloud-based applications. The SandBlast Cloud includes the following security elements:
• Antivirus — Proactively leverages Antivirus signatures to protect against malware in

attached files.
• URL Reputation — Detects and blocks malicious URLs within email body.
• Threat Extraction — Delivers safe, reconstructed copies of documents to users while
inspecting the original files for potential threats.
• Threat Emulation — Forwards inbound email file attachments, including files
originating from URLs within emails, to the sandbox for emulation. It detects and
blocks the file if verified to be malicious or a component of a zero-day attack.
SandBlast Cloud can be deployed in Detect mode, Prevent mode or as a Hybrid.
SandBlast Cloud in Detect Mode

In Detect mode, incoming emails go straight to the inbox without interference, while
attachments are sent to SandBlast Cloud for inspection. This is the ideal mode for introducing
visibility into threats while gradually deploying solution.
SandBlast Cloud in Prevent Mode

In Prevent mode, incoming emails are directed to a temporary quarantine folder within Office
365 to isolate incoming emails from the user inbox. This ensures emails containing malicious
attachments, contents, and URLs will not reach end users.
In the case of a false positive, in which a user determines that the email is from a trusted
source, the email and content can be retrieved from the quarantine folder.
_____________________
_____________________ 633
Hybrid Deployment
Organizations with an on-premise Exchange server and Cloud Office 365 can use the
following options for a hybrid deployment:
• Exchange mail – Use the Check Point Security Gateway with a Next Generation
Threat Extraction Software Blade license, and use either SandBlast Cloud or appliance
for Threat Emulation.
• Microsoft Office 365 – Subscribe to Check Point SandBlast Cloud security as a
service.
To consolidate logging and have both solutions send logs to the same on-premise SmartLog or
SmartEvent server, users can configure the Log Transfer Agent (LTA) in the Check Point
SandBlast Cloud dashboard.
Exchange Server as MTA Agent

Using an exchange server agent as an MTA agent is the best option for administrators who
want to simplify the mail-holding design during SandBlast implementation. This allows them
to use their existing Exchange agent to hold all corporate email, while Check Point SandBlast
certifies it as safe.
_____________________
_____________________ 634
SandBlast Agent
SandBlast Agent extends SandBlast protection to end-user systems, such as desktops and
laptops. It is designed to defend endpoint devices and web browsers.
If malware enters an end user’s system, the SandBlast Agent uses its local version of Anti-Bot
to detect and contain these infections. It searches for any Command and Control (C&C)
communication sent over the network. To prevent the malware from spreading within the
network, SandBlast Agent blocks any communication from the affected computer and
quarantines the infected files.
Forensics Analysis
The SandBlast Agent features automated forensic analysis that generates extensive reporting
and diagnostics of security events for faster response against attacks. It shows threat details,
such as arrival method, attack flow, business impact, and infected hosts.
Figure 520 — SandBlast Agent Work Flow
_____________________
_____________________ 635
To create this report, the SandBlast Agent performs the following:
1. The SandBlast Agent collects forensics data continuously on the endpoint in a tamper-
resistant area. This provides full visibility into activity throughout the attack lifecycle, and
requires minimal overhead. The data is stored for a 30-day window by default, but can be
adjusted. Because the agent only records events, it requires less than 1% of CPU resources
and 1 GB of storage.
2. An Incident report can be triggered by a number of events, including input from SandBlast
Agent, Threat Emulation, Threat Extraction, and other enabled Software Blades.
3. Raw forensic data are analyzed using advanced algorithms. The SandBlast Agent auto-
matically requests logs from involved endpoints.
4. Finally, the SandBlast Agent generates a complete view of attacks, including point of
entry, business impact, and full attack flow. The Incident report is sent to SmartEvent.
Aside from providing comprehensive threat reporting, the SandBlast agent recommends
actionable information that can help in the implementation of remediation measures.
Since forensic analysis happens automatically, security response teams do not need to spend
hours building the information from the ground up. The SandBlast Agent enables these teams
to work efficiently and address threats as they unfold.
Figure 521 — SandBlast Agent Forensic Analysis
_____________________
_____________________ 636
SandBlast Deployment
SandBlast offers businesses flexibility in implementation based on individual business needs,
structure and requirements. You can use a dedicated SandBlast appliance, where Threat
Emulation and Threat Extraction are done in a private, secured cloud environment, or
combined with SandBlast Cloud.
Check Point SandBlast Zero-Day Protection can be deployed as:
• Public Cloud Service — SandBlast Cloud

• Private Cloud — SandBlast Appliance
• Hybrid Solution – SandBlast Appliance and Cloud
Public Cloud Service

In the SandBlast Cloud or Public Cloud Service, OS-level sandboxing and CPU-level
detection are done in a public cloud infrastructure (SandBlast Cloud), which is owned and
operated by Check Point with data centers distributed globally. There is no need to install new
hardware onsite. SandBlast can be up and running within minutes.
It is possible to choose to which public cloud location the files should be sent for detection. If
this is not in accordance to your company regulations, the private cloud solution can be used.
However, this means that you will need to have a dedicated appliance on premise and the files
will not leave the company for checking. Changing the cloud location can be done via the
tecli command.
P r i va te C l o u d
In the Private Cloud solution, OS-level sandboxing and CPU-level detection are done in the
Check Point SandBlast appliance and deployed in a private cloud – inside the customer’s
network. The SandBlast appliance option is best for organizations that have a policy against
sending a file outside the corporate network. A SandBlast appliance has Antivirus, Anti-Bot,
Threat Extraction, and Threat Emulation blades; however, it is highly recommended to use it
solely for OS-level sandboxing and CPU-level detection.
_____________________
_____________________ 637
H y b r i d S ol u t i o n ( S a n d B l as t A p p l i a n c e a n d C l o u d )
In a hybrid solution, OS-level sandboxing and CPU-level detection work together in both
private and public cloud infrastructures. Administrators can choose which files to emulate
locally in the SandBlast appliance or in the public SandBlast Cloud.
This setup is ideal for companies with a distributed architecture, in which most of their
employees work in a regional or global headquarters environment, while others work from
various satellite offices. With a hybrid solution, the organization can deploy a SandBlast
appliance at its headquarters, and support satellite offices using the SandBlast Cloud.
In a hybrid solution, the Threat Prevention tasks are distributed as follows:
• Check Point Security Gateways perform traditional Next Generation Threat Prevention
duties (Anti-Bot, Antivirus, and Anti-Spam) and also act as an MTA to hold emails.
• Threat Extraction can happen either at the Security Gateway or SandBlast appliance.
• Threat Emulation with OS-level sandboxing and CPU-level detection happens either
with SandBlast appliance or SandBlast Cloud.
A distributed architecture is an efficient way to utilize the Check Point SandBlast solution.
However, it comes with the challenge of provisioning and managing multiple MTAs. Check
Point User Center can help customers with these complex security architectures.
_____________________
_____________________ 638
SandBlast Mobile
SandBlast Mobile identifies threats in mobile devices by using on-device, network, and cloud-
based algorithms. Once a threat is detected, it triggers an automatic response to keep mobile
devices and data safe.
SandBlast Mobile can analyze behavior across several attack vectors, namely:
• OS-Level Exploits — These are exploits that target mobile operating systems.
SandBlast Mobile examines the device for any signs of weaknesses, such as vulnerable
versions of Open SSL (for Android) or CA certificate, proxy, or VPN configuration (for
Apple).
• Mobile Application Malware — This is malicious codes hidden in mobile
applications.
• Network Attacks — These are attacks on network connections. SandBlast Mobile
detects Man in the Middle (MiTM) attacks on public Wi-Fi hotspots by validating the
integrity of an SSL connection. It also verifies connection security by using a cloud-
based honeypot that detects if a malicious actor uses an MiTM attack to break a
connection.
• SMS Phishing — Also known as Smishing, this attack vector uses Short Message
Service (SMS) systems to send text messages with malicious links to coax mobile
device users into divulging personal information such as passwords, social security
numbers, and credit card details. The SandBlast Mobile solution can detect SMS
phishing scams by scanning incoming SMS messages for malicious URLs.
Aside from securing these vectors, SandBlast Mobile employs its own dynamic cloud-based
sandbox to examine and reveal the vulnerabilities and exploits hiding in mobile applications. It
also whitelists trustworthy applications that show behaviors typically associated with mobile
threats. To whitelist these applications, it correlates risk analysis data with aggregated factors
such as application developer reputation, the number of downloads, and application source.
This allows end users to download the applications they need without intervention from their
company’s security team.
SandBlast Mobile is capable of advanced code analysis by automatically capturing and

reverse-engineering applications to expose code and deconstruct flows for semantic analysis.
This helps identify suspicious patterns and behaviors.
SandBlast Mobile also determines risk scores for devices, which are regularly updated once
new findings are uncovered. This continuous analysis provides organizations an up-to-date and
accurate picture of mobile threats in their network, as well as detailed information about what
is being done to mitigate those risks.
_____________________
_____________________ 639
SandBlast Mobile Components

SandBlast Mobile has four dedicated components that constantly work together to protect
mobile devices and their data. The constant communication between these components ensures
that you are informed of any suspicious activities and threats occurring in the device. The
components are:
• SandBlast Mobile Protect Application

• Behavioral Risk Engine
• SandBlast Mobile Dashboard
• SandBlast Mobile Gateway
Figure 522 — SandBlast Mobile Components
The SandBlast Mobile Protect Application

SandBlast Mobile Protect is a lightweight mobile application that gathers data and helps
analyze threats to the mobile device. The application monitors the mobile operating system,
application information, and network connections. It also provides data to the mobile Threat
Prevention solution, which is used to identify suspicious or malicious behavior. The
application examines critical risk indicators found in the data it collects. It does not collect or
examine sensitive data such as content or files.
_____________________
_____________________ 640
To minimize use of device resources and bandwidth, SandBlast Mobile Protect performs some
of its analyses on the device, while resource-intensive analyses are performed in the cloud.
Figure 523 — SandBlast Mobile Protect Application
The Behavioral Risk Engine

The cloud-based Behavioral Risk Engine (BRE) receives information sent by the SandBlast
Mobile Protect application, which includes the device’s network, configuration, operating
system integrity, and metadata related to the installed applications. It harnesses this data to
perform an in-depth mobile threat analysis. This analysis helps detect and monitor possible
dubious activities on the device.
The BRE generates a risk score based on threat type and severity. The risk score determines if
and what mitigation is needed to keep the device and its data protected. Once a threat is
identified, it triggers the SandBlast Mobile Protect application to notify the end user of the risk
level and possible mitigating actions.
_____________________
_____________________ 641
The SandBlast Mobile Dashboard

The cloud-based SandBlast Mobile dashboard helps you manage and monitor devices and
policies. It is configured as a per-customer instance.
This dashboard can be integrated with an existing Mobile Device Management/Enterprise

Mobility Management solution for automated policy enforcement on at-risk devices. When
integrated, the Mobile Device Management/Enterprise Mobility Management serves as a
repository on which the dashboard synchronizes enrolled devices and identities.
Using the dashboard, you can register new devices using personal information such as a user’s
name, email address, and phone number. The personal information is processed by the
dashboard and may also be stored in the dashboard.
Figure 524 — SandBlast Mobile Dashboard
The SandBlast Mobile Gateway

The cloud-based SandBlast Mobile gateway is a multi-tenant architecture to which mobile
devices are registered. It handles all solution communications with enrolled mobile devices.
The gateway also stores data elements, such as the unique identifier of the registered device
and application certificates that may be viewable per customer instance from the organization’s
dashboard. Personal information is not processed by or stored in the gateway.
_____________________
_____________________ 642
S a n d B l a s t M o b i l e Wo rk fl ow
The SandBlast Mobile Threat Prevention solution and its components protect mobile devices
from advanced mobile malware, spyware, viruses, and other threats. Below is a detailed
workflow of how the components work together.
Figure 525 — SandBlast Mobile Components Workflow
1. The SandBlast Mobile Protect application detects changes in applications or network con-
nections with possible MiTM vulnerability.
2. SandBlast Mobile Protect sends encrypted artifacts to the SandBlast Mobile gateway
using SSL.
3. The gateway receives data from the device. The gateway process application list is com-
pared to known Application Risk Assessment based on application_id.
4. The gateway aggregates application artifacts for identification and analysis. It retrieves the
copy of the application online or from the device if not available online.
5. The BRE initiates the analysis to identify the risk type and assess severity of the risk.
6. The BRE assigns a risk score to the specific application_id.
7. Analysis results and application metadata are stored in the BRE database. The BRE sends
out a risk score and application_id to the gateway.
8. The gateway evaluates risk, score, and application_id. If malicious, it sends a warning to
the SandBlast Mobile Dashboard.
9. The dashboard sends an alert to SandBlast Mobile Protect. The dashboard also alerts the
company’s Mobile Device Management/Enterprise Mobility Management, so long as they
are configured to do so.
_____________________
_____________________ 643
L a b 7. 4
Deploying Threat Emulation and Threat Extraction
_____________________
_____________________ 644
7.4
L
Deploying Threat Emulation  A
and Threat Extraction B
Sometimes it’s a good idea to inspect files for viruses before sending them to external users, such as
partners, to verify that the files pose no threats. Upload files to the Check Point ThreatCloud for inspection.
Then, to handle threats entering the network, configure your Security Gateway to perform Threat
Emulation functions to identify and stop zero-day attacks.
Ta sks :
• Use ThreatCloud to verify file safety.
• Configure Threat Emulation to inspect incoming traffic.
• Upload a file for Threat detection and emulation.
• Configure Threat Emulation.
_____________________
_____________________ 645
Use ThreatCloud to Verify File Safety

Upload a file to the ThreatCloud Emulation Service to confirm it is safe to send.
1. From the A-Host virtual machine, locate the following file on the desktop:
Safe.pdf
2. Launch a Web browser and navigate to the following site:
https://www.checkpoint.com/threat-prevention-resources/
Figure 526 — Check Point ThreatCloud Emulation Service - Login Page
3. Click the icon for the following page:
Emulate A File For Malicious Behavior
_____________________
_____________________ 646
4. In the Username and Password fields, enter your User Center account login information.
NOTE
If you have not already created a User Center account, do so now. Visit
www.checkpoint.com. Next, select Support/Services and click Enter Support Center.
Click the Sign Up Now button and enter the requested information. Your user center
account should always be created with your work email address.
5. Click the Go icon.
NOTE
The Upload page may not be visible from all versions of all browser. If you do not
see this page, attempt these steps with an updated Internet Explorer or Chrome
browser.
6. Click the Choose File button, and the system displays the following window.
7. Browse to the Safe.pdf file.
8. Select Safe.pdf, and click Open. The system adds the selected file to the Selected File field.
9. Click the Upload & Test button, and the system uploads the file to ThreatCloud to be evaluated.
10. Once the file has been evaluated, the system displays the Results page.
11. Close the Browser window.
_____________________
_____________________ 647
Configure Threat Emulation to Inspect Incoming

Traffic
Configure the Security Gateway Cluster to send incoming files for review to the Check Point ThreatCloud.
1. In SmartConsole, edit the Security Gateway Cluster object.

2. In the Network Security tab, select Threat Emulation. The system displays the Threat Emulation First
Time Activation wizard:
Figure 527 — Threat Emulation First Time Activation - Emulation Location
ThreatCloud Emulation Service
_____________________
_____________________ 648
Figure 528 — Threat Emulation First Time Activation - Compatibility
NOTE
If the system displays an error and the next button is grayed out, this may be the
result of an expired IPS contract. If this happens, it will not negatively affect the lab.
Select the option to Ignore the error and continue. Then click Next.
5. Verify that you have Internet connectivity by launching a browser on A-GUI, and navigating to the
following site:
www.CheckPoint.com
_____________________
_____________________ 649
Figure 529 — Threat Emulation First Time Activation - Summary
_____________________
_____________________ 650
7. Click Finish, and the system shows that Threat Emulation is now configured on the Security Gateway
object:
8. Click OK.
_____________________
_____________________ 651
9. Since you have modified the configuration of the Security Gateway Cluster object, publish and install
the Security Policy.
10. In the Security Policies tab, select the Threat Prevention > Policy:
Figure 531 — Threat Prevention Policy Rule Base
_____________________
_____________________ 652
11. Edit the Optimized profile.
Figure 532 — Optimized Profile
_____________________
_____________________ 653
12. In the navigation pane, select Threat Emulation Settings:
Figure 533 — Threat Emulation Settings
13. Verify that the following Protected Scope option is selected:
Inspect incoming files from External and DMZ interfaces
_____________________
_____________________ 654
14. In the navigation pane, expand the Threat Emulation Settings branch.
15. Select Emulation Environment, and the system displays the following:
Figure 534 — Emulation Environment
16. In the Analysis Location section of the page, select Specify > Check Point ThreatCloud.
_____________________
_____________________ 655
17. In the navigation pane, select Advanced:
Figure 535 — Advanced
18. Verify that the Emulation Connection Handling Mode selected is as follows:
Background - connections are allowed until emulation handling is complete
19. Click OK to save the new profile.
_____________________
_____________________ 656
20. Verify that the Threat Emulation icon appears in the Internal Network
Figure 537 — Threat Prevention Policy Rule Base Configured
_____________________
_____________________ 657
21. Install the Threat Prevention policy:
Figure 538 — Threat Prevention Policy Installation
22. Click Close.
END OF LAB 7.4
_____________________
_____________________ 658
Review Questions
1. How does SandBlast Threat Emulation and Threat Extraction prevent threats like zero-day
attacks and APT?
2. How does IPS complement the Firewall Software Blade when it comes to preventing
threats?
_____________________
_____________________ 659
A
A
P
P
Check Point Security Engineering E
N
Questions and Answers D

I
X
End of chapter review questions are answered in this Appendix.
_____________________
_____________________ 660
Chapter 1
S y s te m M a n a g e m e n t
1. What is CPUSE and what is it used for?
CPUSE is Check Point’s Update Service Engine. It is used to support the deployment of
single hotfixes, hotfix accumulators, and major version upgrades.
2. Name at least three Stateful features provided with the Connection table.
Streaming based applications, such as Web security
Sequence verification and translation
Hide NAT
Logging, accounting, and monitoring
Client and server identification
Data connections
_____________________
_____________________ 661
Chapter 2
Autom a t i o n a nd O rc h e s t r a t i o n
1. What are the four command sources which allow you to communicate with the manage-
ment server using management API?
The four command sources which allow you to communicate with the management server
using management API are:
The SmartConsole GUI
The mgmt_cli tool
Gaia CLI
Web Services
2. What does the sid command string identify?
The sid command string identifies the session unique identifier.
_____________________
_____________________ 662
Chapter 3
Red u n d a nc y
1. What happens when the Sticky Decision Function (SDF) is enabled?
A connection is sticky when all of its packets are handled, in either direction, by a single
cluster member. The SDF enables certain services to operate in a Load Sharing
deployment. VPN deployments with 3rd party VPN peers and Endpoint Connect/SSL
Network Extender encrypted connections are both supported when SDF is enabled.
2. Describe what a cluster VMAC is and how it works.
Cluster Virtual MAC (VMAC) is a virtual MAC address assigned to a Virtual Router. It is
a variation of the High Availability New mode and Load Sharing Unicast mode.
Configuring the cluster to use VMAC mode allows all cluster members to use the same
Virtual MAC address and minimizes possible traffic outages during a failover. In addition,
G-ARPs for NAT’d addresses are no longer needed.
_____________________
_____________________ 663
Chapter 4
Ac c e l e r a t i o n
1. Describe the three paths of traffic flow for SecureXL.
Firewall path — Packets and connections that are inspected by the Firewall. These
packets and connections are not processed by SecureXL.
Accelerated path — Packets and connections that are offloaded from the Firewall to
SecureXL. These packets and connections are quickly processed.
Medium path — Packets that cannot use the accelerated path because they require deeper
inspection. Although it is not necessary for the Firewall to inspect these packets, they can
be offloaded by another feature. For example, packets that are examined by IPS cannot
use the accelerated path and can be offloaded to the IPS Passive Streaming Library (PSL),
which provides stream reassembly for TCP connections. As a result, SecureXL processes
these packets quicker than packets on the slow path.
2. How does CoreXL improve network performance?
CoreXL acts as a load balancer and improves Security Gateway performance in situations
where much of the traffic cannot be accelerated by SecureXL or when the gateway has
many IPS features enabled, which disables SecureXL functionality. It also improves
performance for gateways with a large Rule Base and/or NAT rules.
3. When should you consider using Multi-Queue?
Check Point recommends configuring Multi-Queue when the following conditions are
presented:
The CPU load for SND is high (idle is < 20%).
The CPU load for CoreXL Firewall instances is low (idle is > 50%).
There are no CPU cores left to be assigned to the SND by changing interface affinity.
_____________________
_____________________ 664
Chapter 5
S m a r t E ven t
1. What are the main components of the SmartEvent Architecture?
Check Point Security Gateway
Log server
Correlation unit
SmartEvent server
Events database
SmartEvent client
2. Explain how SmartEvent identifies an event.
SmartEvent retrieves logs from Log servers and searches for patterns. The Correlation
Unit scans logs for criteria that match an event definition. SmartEvent uses the following
procedures to identify events:
• Match a log against global exclusions

• Match a log against each event definition
• Create an event candidate
3. How would a System Administrator reduce the number of false positives?
To eliminate false positives, change the thresholds and other criteria of an event. For
example, increase the number of connections, logs, or failures and/or the period of time
for them to occur.
_____________________
_____________________ 665
Chapter 6
Rem o te a n d M o b i l e Ac c e s s
1. What is the difference between an SSL VPN and an IPSec VPN?
In the SSL VPN solution, users can connect securely to business web-based applications
through a web portal, which can be accessed using a web browser. This solution does not
require users to install a VPN agent or client and can be configured to enforce two-factor
authentication.
IPSec, Layer 3 VPN requires remote workers to install a VPN client before gaining access
to corporate resources. Once a user installs the client, the Layer 3 VPN provides a secured
connection to both web-based and native business applications.
2. How do Capsule Docs and Capsule Workspace work together?
As business documents are edited and viewed on personal devices using Capsule
Workspace, Capsule Docs protects business data and documents no matter where it is
transmitted.
_____________________
_____________________ 666
Chapter 7
T h r e a t P r eve n t i o n
1. How does SandBlast Threat Emulation and Threat Extraction prevent threats like zero-day
attacks and APT?
To prevent these threats, Threat Emulation performs CPU-level inspection of incoming

files to look for signs of exploit methods. It runs the inspection in a sandbox environment,
away from the organization’s network. If files exhibit malicious routines, Threat Emulation
deletes them promptly.
While Threat Emulation performs the inspection, Threat Extraction provides a clean,
sanitized version of the file. This is to avoid any disruption to the company's daily
operations.
2. How does IPS complement the Firewall Software Blade when it comes to preventing
threats?
While Firewall blocks network traffic based on source, destination, and port information,
IPS analyzes its contents. This is to prevent threats such as drive by download, which are
known to hide malicious codes behind hijacked, legitimate websites.
_____________________
_____________________ 667

Manual CCSE R80.10 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual CCSE R80.10 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

SECURITY ENGINEERING

RESTRICTED RIGHTS LEGEND:

International  5 Ha’Solelim Street

U.S. Headquarters 959 Skyway Road, Suite 300

Technical Support,  6330 Commerce Drive, Suite 120

Preface: Security Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 1: System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Lab 1.1: Upgrading to R80.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Lab 1.2: Applying Check Point Hotfixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Lab 1.3: Configuring a New Security Gateway Cluster . . . . . . . . . . . . . . . . . . . . . . . 103

CLI Commands .......................................................................................................................................... 183

Lab 1.4: Core CLI Elements of Firewall Administration . . . . . . . . . . . . . . . . . . . . . 193

Advanced Firewall ..................................................................................................................................... 220

Lab 1.5: Viewing the Chain Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Stateful Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Lab 1.6: Configuring Manual Network Address Translation . . . . . . . . . . . . . . . . . . 271

Review Questions ....................................................................................................................................... 294

Chapter 2: Automation & Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Review Questions ....................................................................................................................................... 322

Chapter 3: Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Lab 3.1: Deploying a Secondary Security Management Server . . . . . . . . . . . . . . . . 339

VRRP Clusters ........................................................................................................................................... 365

Lab 3.2: Enabling Check Point VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Review Questions ....................................................................................................................................... 396

Chapter 4: Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Lab 4.1: Working with SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

CoreXL: Multicore Acceleration ................................................................................................................ 413

Lab 4.2: Working with CoreXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Review Questions ....................................................................................................................................... 435

Chapter 5: SmartEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Identifying an Event ................................................................................................................................... 443

Lab 5.1: Evaluating Threats with SmartEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Review Questions ....................................................................................................................................... 485

Chapter 6: Remote and Mobile Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Check Point Capsule .................................................................................................................................. 492

Lab 6.1: Managing Mobile Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

Review Questions ....................................................................................................................................... 543

Chapter 7: Threat Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544

Lab 7.1: Understanding IPS Protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

Geo-Protection ............................................................................................................................................ 593

Lab 7.2: Deploying IPS Geo Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

Antivirus ..................................................................................................................................................... 607

Lab 7.3: Reviewing Threat Prevention Settings and Protections . . . . . . . . . . . . . . . 609

Sandboxing ................................................................................................................................................. 623

Lab 7.4: Deploying Threat Emulation and Threat Extraction . . . . . . . . . . . . . . . . . 645

Review Questions ...................................................................................................................................... 659

Chapter 8: Questions and Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660

Check Point Security Engineering Course

• UNIX and Windows operating systems

Chapter 1: System Management

Chapter 2: Automation and Orchestration

Chapter 6: Remote and Mobile Access

Chapter 7: Threat Prevention

Figure 1 — Starting CCSE Lab Topology

The Makings of Gaia

Check Point Gaia offers these key values:

• Combine the best features of IPSO and SecurePlatform.

Figure 2 — Gaia Portal

Dynamic Routing Protocols Multicasting Protocols

Package File Description

The Upgrade Verification Service

Migrating Management Server Data

3. In the navigation pane, click User Management > Users.