Introduction

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

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

2. Cloud Security: Public, Private and Hybrid,

3. Endpoint Security for both Windows and Macs, and
4. Mobile Security for Android and iOS devices

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

Network Defense. Three Tier

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

Administration process includes the following steps:

1. Security Administrator opens SmartConsole and connects to the Security

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

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

1. Windows – for SmartConsole only. SG and SMS cannot be deployed on Windows.

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

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

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

 R77.30
 R80.10
 R80.20

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

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

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

or as different entities (Distributed Deployment).

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

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

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

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

Bridge Mode can be deployed without changing network topology, to control traffic on
Layer 2. Some functionality is limited in this mode.
Check Point Software Blades
One of the most frequent questions beginners have is about the term “Software Blades”.
In plain words, Check Point is using this term for specific features of its products.

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

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

Security Gateway Software Blades

 Firewall – Basic security filtering functionality

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

Security Management Server Software Blades

 Network Policy Management — to create and manage SG security policies

 Endpoint Policy Management — to create and manage Endpoint Security
Policies
 Logging & Status – central logging and log consolidation functionality
 Workflow — Change Management Cycle functionality with ability to audit and
approve certain policy management operations
 User Directory — User management and integration with external
authentication solutions
 Provisioning — Centralized maintenance tool
 Compliance — Automated compliance tool for security and best practices audits
 SmartEvent — Log correlation and Security Events management tool
Introduction
Before moving forward, we need to build a lab environment. All further discussions
have in mind the virtualization lab setup described below.

Virtual Lab
The virtual lab layout is presented on the diagram below.

It consists of five virtual machines

 Security Management Server (SMS)

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

Virtualization platform
While we are using VMware Workstation 14 in our lab, you can also use ESXI or Virtual
box as a virtualization platform.
Installation Software Images
To install and setup all Check Point machines you need R80.10 Check Point ISO file. It
is available here.

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

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

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

Although going below these requirements is definitely not recommended in the

production, we can have some allowances in the lab.

These are recommended virtual machine parameters for our lab:

 SMS: 6GB RAM, 4 CPU Cores, 80GB HDD

 SG: 4GB RAM, 2 CPU Cores, 50GB HDD

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

We believe the lab can be performed on a virtualization host with the following
parameters:
  4 cores CPU,
 16BG RAM,
 500GB HDD/SSD.

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

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

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

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

Let talk about both options in more detail.

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

 Enterprise (Smart-1 405, 410, 225, 525)

 High End Enterprise (Smart-1 3050, 5050, 3150, 5150)

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

2. Open Server
In case of the Open Server deployment, you install SMS on a dedicated physical server
or as a virtual machine, with Gaia OS. If the physical server is your choice, check the
Hardware Compatibility List.
Deploying SMS as a virtual machine is also a popular option. SMS VM production
deployment is supported on several ESX versions, Hyper-V and KVM. See Hardware
Compatibility List, tab "Virtual Machines" for more details.

We are deploying SMS as a VM in our lab.

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

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

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

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

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

After creating a new network, uncheck – “Use local DHCP service…” setting to disable
DHCP on it.
Now we can create a new Virtual Machine with the following parameters:

 Virtual Machine Name - SMS

 Guest operating system - Other 64-bit
 RAM - 8GB[i]
 Processors - 2
 HDD - 50
 CD/DVD - Check_Point_R80.10_T462_Gaia.iso
 Network Adapter - VMnet2
Once you start the machine, it boots from the DVD ISO image file, and the following
screen appears:
Choose “Install Gaia on this system” to start the installation process. It includes six
steps:

Proceed with the installation by pressing OK

Choose the keyboard locale from the menu (we are using US) and press OK again
Partition the hard drive. In the real world when deploying an Open Server, it is usually
safe to rely default Gaia partitioning. Yet, if require, you can change sizes for System-
root and Logs partitions.

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

Set up the initial admin password. You can chose your own, but we are setting “vpn123”
password at this step.
Set up IP address, network mask, and the default gateway.

Confirm the setup parameters and start installation by pressing OK.

At the end of installation procedure, you will see the note about first time configuration
accessible via https://192.168.1.100. Press reboot and wait until the VM is fully up.
At this point, we have finished the installation. Let’s run a First Time Wizard to
complete configuration of our SMS.

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

To continue, we need to set up an IP address on virtualization host (your PC) VMnet2

adapter as 192.168.20 and network mask for class C (255.255.255.0).
Once the IP address is set, you can connect with a browser to https://192.168.1.100.
Most probably, you will see “Invalid Certificate” security warning. Default Gaia
installation uses self-signed certificates, so you can ignore the message and connect. You
will see an authentication prompt.
Type in username admin and the password you chose previously (vpn123). You will see
the First Time Wizard Welcome screen. Press Next button:

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

Do not change Management Connection settings and continue by pressing Next:
Set up a Host Name - SMS, Domain Name - testlab.local, and DNS server – 8.8.8.8, then
press Next:

You can leave default time and date settings:

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

We will be using Gaia administrator settings for Security Management default

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

Finally, confirm all the settings and press Finish to start configuration process.
The process takes 10 to 15 minutes:
Once it is finished, we get access to Gaia OS WebUI:
Check Point Security Appliance
With Check Point, there are four categories of Security Gateway Appliances:

 Small and Medium Business,

 Enterprise,
 High End Enterprise and Data Center,
 Large Data Centers and Telcos, also known as Scalable Platforms (SP).

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

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

Open Server / virtual machine

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

Installing a Software Gateway

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

Create a new virtual machine with the following parameters:

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

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

Initializing Security Gateway

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

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

Leave interface eth2 settings as is.

Wizard will advise you to set up other interfaces. Skip them at this point by pressing
Next. We will set up other networks later on.
In Device Information menu, set up the machine hostname (SG), domain name
(testlab.local) and the Primary DNS Server (8.8.8.8):

Leave Date and Time as default and press Next.

Choose “Security Gateways and/or Security Management” for Installation Type and
press и Next:
For Products, chose only Security Gateway. Press Next to continue.
Choose No for Dynamically Assigned IP (DIAP) and press Next:
The last part of the Wizard is about SIC – Secure Internal Communication. In a few
words, all parts of Check Point based Security System are using TLS encrypted channel
to interconnect. This tunnel is known as SIC. It uses certificate based encryption.
Certificates are issued by the Management Server and are initialized with an activation
key we are defining at this step.

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

Press Finish to conclude the initialization process. The machine will reboot.
After reboot, you will be able to login into Gaia WebUI, same as in the case of SMS in the
previous lecture.
Congratulations, you have successfully finished installation and initial configuration of
two major elements of Check Point security system: Security Management and Security
Gateway
Gaia Management Tools
To function properly, Check Point devices need some OS level settings: IP addresses,
routing parameters, DNS, DHCP, SNMP, system updates, and backup settings. OS
parameters can be managed either through WebUI or CLI.

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

The Gaia WebUI supports the following browsers:

 Internet Explorer 8 or higher (including IE11).

 Microsoft Edge
 Chrome 14 or higher
 Firefox 6 or higher
 Safari 5 or higher

You can always check if you browser is supported in SK92668

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

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

For more details, refer to the Gaia Administration Guide.

Network Interface Setup

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

To do so, go to Network Management > Network Interfaces. All physical interfaces

detected by the systems are listed there:

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

You can also add “Inside” to the Comment field of eth2. All interfaces should be shown
Up at this point.
Setting Default Gateway
Now, let’s set up default gateway. Go to Network Management > IPv4 Static Routes.
The only entry there is Default.

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

Type in the IP address of the default gateway. In our case it is 192.168.206.2 (Vmware
Workstation has .2 for NAT Adapter gateway).
Note: Gaia OS allows only a single admin session in write mode. If you close your
browser window without logging off first, or the session times out due to inactivity, you
will see the system configuration locked on the next entry to WebUI.
To unlock the settings, just click on the lock icon.

Gaia command line interface (CLI)

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

There are several different way to invoke Command Line Interface:

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

Terminal Window with a login prompt pops up:

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

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

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

If you want to access Linux bash, you need to enter Expert mode. Entering Expert mode
require “expert” password which is different from the user password.
Clish CLI syntax is simple and can be vewed as Operation > Feature > Parameter.

Let’s take a look at some examples:

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

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

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

There are a number of options here, but we will start with reviewing the configuration,
which can be done by typing the command show configuration. You will see all Gaia
configuration settings in the output, including the ones related to the network
interfaces:
Never try setting any Gaia OS parameter with standard Linux tools. These settings will
not survive reboot and will be get overridden by clish or WebUI configuration changes.

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

Set the expert password and type in expert again, than enter the configured password.
CLI prompt sign will change from > to #:

Standard Linux tools and commands are now fully available.

Working with SmartConsole

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

Installation
SmartConsole is a Windows based GUI Client. To install it, we need to get an installation
package. The easiest way to obtain it is to download it from our SMS. Open WebUI to
your lab SMS (https://192.168.1.100) and log in.
On Overview screen, press “Download Now!” green button at the top of the page.

Download the installation package and start installation:

In the welcome pop-up window accept Check Point EULA and press Install:
The installation process will take some time:

Press Finish at the end:

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

Confirm SMS Fingerprints and press PROCEED:

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

Go through the Tutorials screens, especially if you are already familiar with R77.30
SmartDashboard. The R80.x SmartConsole has quite a different look and feel.
Close the What’s New tutorial. You can always go through it again by pressing What’s
New icon at the left bottom corner of SmartConsole screen.

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

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

You can see more details about resources utilization:

Browse System Counters > System to review graphic representation of utilized

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

Choose Wizard Mode and continue:

In the Wizard pop-up window, choose Open Server for Gateway Platform, type in IP
address 192.168.1.254 and then press Next:
Type in SIC - One Time Password we have defined during SG installation REFERENCE
and press Next:
Under normal circumstance, (SG is up, and SIC password is correctly typed), you should
see Get Topology Results pop-up screen:

Check IP addresses and networks; then press Close and Next. Press Finish to end the
Wizard.
You can now see Check Point Security Gateway pop-up for the newly defined SG.
Choose General Properties and review Gateway Software Blade available. As you can
see, Firewall Software Blade is marked by default. Do not change any settings and this
point and press OK:
Press Publish button at the top of the screen to make all changes you performed
available to other administrators.

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

When the Publish operation is finished, you should see a green Status indicator for SG:
 Security Policies
There are four types of Security policies:

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

In this lecture, we will cover Access Control only.

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

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

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

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

Anti-Spoofing and Security Zone settings

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

Double-click on eth0 and the following screen appears:

Three parameters needs to be adjusted:

 Leads To
 Security Zone
  Anti-Spoofing

Click on Modify and set up those as shown below:

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

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

Click on OK twice and move to eth2 settings:

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

Network objects

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

Objects are managed through Objects Panel on the upper right part of SmartConsole screen
or with Object Explorer:
Let us start by creating a new network object called LanNetwork. To do so, in the Object
Panel, press New > Network

In the new pop-up, set up the object name (LanNetwork), IP address and Mask:
 Leave NAT (Network Address Translation) settings untouched. They are a subject of our
next lecture. Press OK to finish.

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

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

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

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

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

 The purpose of this rule is to allow HTTPS and SSH access from our LAN to Security
Gateway and SMS.
Put “Mgmt” in the Name field. Chose LanNetwork object as Source, add SMS and SG to
Destination, finally, HTTPS and SSH to Services & Applications:

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

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

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

Put the following parameters:

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

Our new rules should look as below:

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

option default (None

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

Finally, add another policy rule allowing access from LanNetwork to DMZ-Srv with Any
service. Your rulebase should now be as shown:
 Note: R80.x Security Management Server allows multiple administrators to make parallel
changes. To make your changes available to other administrators, you need to publish them
by pressing on Publish button at the top of SmartConsole screen.

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

Installing Security Policy

We need to apply our Security Policy. Click on Install Policy button at the upper left corner
of your SmartConsole screen:
The pop-up message reminds us we did not publish changes. Note that amount of changes
and the admin account are mentioned in the Description field. Press Publish& Install:

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

Once done, you will see Policy installation progress notification at the left bottom corner of
your SmartConsole screen.
 When installation process is finished, you will see a notification about success:

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

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

Select DMZ Access rule in SmartConsole and then chose Logs tab. You should see access
logs for this rule:
 Types of NAT
NAT settings are part of the Access Control policy, as we have mentioned in Part 7:

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

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

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

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

Static NAT is commonly used to ensure reachability of DMZ resources from Internet.
 Let’s review cases of Automatic and Manual NAT configurations on more details.

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

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

Mark “Add automatic address translation rules” checkbox.

The translation method menu has two options: Hide (which is the default one) or Static.
Leave the default value and press OK.
This action will create Automatic NAT rules. Move to Security Policies > Access Control >
NAT to see them:
 In a similar manner, set up Automatic NAT for our DMZ-Srv object:

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

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

2. Manual NAT
Manual NAT rules need to be explicitly created in the NAT Policy rulebase.
 In our case, we want to forward only HTTP traffic to our DMZ server when someone is
trying to reach it from external networks.

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

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

Create a new host object with the external IP address of our Security Gateway:
 Now, let’s add our new manual static NAT rule.

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

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

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

Create the manual NAT the rule in the following manner:

Original Source: Any

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

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

Finally, we need to add an access rule allowing external users to reach DMZ server via HTTP
service. To do so, go to Security Policy Rulebase and add a new rule called DMZ-Srv Access
at the very top of the rulebase, with the following parameters:
  Name: DMZ-Srv Access
 Source: Any
 Destination: PublicIP
 Services & Applications: http
 Action: Accept
 Track: Log

Install Policy:

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

 Once policy is installed successfully, we can start testing.

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

Our Access and NAT policies allow Lab User PC to access Internet Web resources, but ping
should not be working for the routable Internet IP addresses:
To check Port Forwarding functionality, we should access the external IP address of our
Security Gateway with HTTP. In our case, with a VMware Workstation based lab
environment, we can use VMware host PC, through VMnet8 adapter.

Let’s test it:

Thus, we have completed the basic NAT settings.