Checkpoint Lab - 9 (Policies and DB versions) Tutorial

Before we discuss the policies and db versions lets start expanding our lab a little bit. We will start working on the Branch Office setup and Branch Office DMZ configuration. Go ahead using the previously discussed steps in LAB-4. Set it up a Security Gateway/Firewall only for Branch Office. We will use the existing Manager to connect to both the firewalls (Main and Branch Office).
Assuming you are done installing the firewall and are ready to add it to the Manager, we first need to create rules for manager to access the branch Office firewall. To add it to the manager, this time we will use the wizard mode (Previously we used classic mode)

Once you select the Wiz mode you will see the screen below - Select the external ISP ip 10.100.100.253 and Gateway name appropriately.

Click "Next" and enter the one time password for the manager to establish SIC.

And as expected it will fail. The manager will not be able to connect since its in the internal Main office. For it to reach the branch office firewall we need to NAT the manager traffic to use an external ISP IP address. Refer the below screen print.

Double click the "Manager" object and in the NAT assign it a public ISP address, select MainOffice_Firewall on the install on gateway option and check the Apply for security gateway control connections. This option means use this NAT to manage any other firewalls via this manager.

Now try establishing the SIC communication again between the manager and the BR_Firewall with the NAT in place the devices will communicate and trust will be now established.

Earlier chapter covered how to create policy now lets try to create a consolidated policy that can be applied on multiple firewall gateway since its not feasible to maintain different policies for different firewall, it can be confusing and tedious. So below is the example on how to create single policy and push it to multiple gateways.

 The first management policy can be applied to all the firewall gateways in the company. So the destination would include both the firewalls. Same applies to the Stealth, Netbios and cleanup. The install on will actually decided which device the policy will be applied. If the "Install on" is "Policy Targets" it will be pushed to all the gateways. For targeted deployments just chose which device it needs to go to. Form the above above example - "Main Office rules3-4" will get pushed to MainOffice Firewall and "Branch Office Rules 5-6" will go to the Branch Office firewall. When the policy is pushed you will be presented with both the devices selected and we can opt out at this point as well to where the policy goes.

Don't forget to dynamically NAT the inside traffic going external for both Main and Branch internal networks. You can select option "Hide behind gateway". Choose the appropriate firewall device on with this will be deployed as well.

Now lets take a look at the DMZ policies that were implemented as per our lab setup. Assumption - DMZ servers at both sites will be running web and ftp services. First the DMZ server objects needs to be defined as Nodes.

The DMZ server at MAin office DMZ - 172.16.1.2

And we are enabling a static NAT to a public IP - 10.100.100.205, the ip that can be accessed from "outside" the network by clients. This would add the NAT rule automatically - 

Outbound - 
Original Pkt - Source - DMZ server (172.16.1.2) , Destination - Any, Service - Any
Translated as - Source - DMZ server NAT ip (10.100.100.205), Destination - Same as Original pkt, Service - Any

So when the server initiates outbound connection like a response to client 1.2.3.4, the packet inside the DMZ network before it hot the firewall would be
Src - 172.16.1.2, Client - 1.2.3.4, Port 80
and when it leaves the firewall interface that packet will be modified as
Src - 10.100.100.205, Client - 1.2.3.4, Port 80
This way the client cal talk back to the 10.100.100.205 ip since it does not know the private DMZ ip 172.16.1.2

Inbound - 
Original Pkt - Source - Any , Destination - DMZ server (172.16.1.2), Service - Any
Translated as Source - Same as Original pkt, Destination - DMZ server NAT ip (10.100.100.205), Service - Any
Same rule applies for an inbound connection as well. When a client 1.2.3.4 connect to DMZ server to consume ftp service, before the packet hits the firewall - 
Src - 1.2.3.4, Client - 10.100.100.205, Port 21
After it hits the firewall - 
Src - 1.2.3.4, Client - 172.16.1.2, Port 21
The red S symbol implies that the object has a Static NAT, Similarly H implies its a hide NAT.Now we create the policy as below where we specify the services and on what firewall that this rule must be applied.

Similarly configure the branch office DMZ server  and group the Common (go on both), Main office - HQ_Firewall, Branch - BR_Firewall and you should have something like below -

Database -

Checkpoint gave admin's a great option to backup the policies and objects that are created. This options is presented when the policies are being installed on the gateways. By giving the option to backup we can take easily recover when a bad policy is deployed and cause an outage. Using the previously taken backup we can restore in matter of min and then investigate what happened with the bad policy at leisure.

Once you hit "OK" a backup is created and stored in the database of the manager. To view options of the backups, go to File--> Database Revision Control option. I created multiple backups when building the lab and it looks like below - 

There are diff options you can configure
You can rotate/restrict the number of backups that are saved on the system.
Select "Automatically delete old versions - Configure" tab

Multiple options are available on how the versions can be retained. Since this is a lab setup I choose 10 options. It also depends on how much disk space was allocated during the initial install.
If you want to lock on to a backup which you know is good and can fall back to
it as safety net you might want to mark that as "don't delete" copy. Select the db version and click "Properties" tab and choose - "Keep this version from being deleted automatically." This options will display a crossed trash can which visually indicates that it will not be deleted when the version deletes happen.

The restore can be done by clicking "Action" and selecting the "Restore Version"...since its a lab setup...try deleting few objects and rules and use this option to check if the deleted items are restored correctly. "Remove Keep" will negate the "Keep this version" option and will enable the policy to be deleted. "View version" will open that version in a new dashboard instance.

Checkpoint Lab - 8 (Secure Internal Communication issue)

Secure Internal Communication issue

During the SIC setup (If you are paying attention to the screenshots) I wanted to change the firewall IP from external 10.100.100.254 to internal 10.1.1.222 (Just experimenting to see what happens). Since I already established trust using the external IP  during "Manager and Firewall hookup lab" when I tried to switch to internal ip I got “Trust could not be established” errors. The only logical think at that time for me to do was to reset SIC  one time pass phrase and try again.

SSH into the MainOffice Firewall and invoke “CPCONFIG”

Choose option 5 and hit enter. Input any new activation key/passphrase again (Circled red)

Use option 9 to exit and it was interesting to see what happened next –

After logging in…I initiated the SIC with the internal IP and it was able to connect and established trust. Looks like based on modules that were selected the services were restarted. I will try to read up more and run few other tests and add few notes that I have in progress.

Checkpoint Lab - 7 (Creating Policy) Tutorial

Creating Policy on Checkpoint

Policies are definitions/filters/rules which define what traffic should be allowed/denied/rejected/dropped. Policy in general can be defined in several ways google it up if you need to learn more.

I will help you understand 5 basic policies that are defined in most environments. Before we go ahead just keep in mind that the policies are processed according to order top to bottom, so where you place and create the policy is important.

5 Policies - 

Management rule - In this rule we can define who and what services can connect to our firewall. You need to administer and connect to the firewall directly for some reason from ClientA machine you would define it as 

Source -->Destination -->Services -->Action --> Track --> Install on

Computer-->Firewall -->   https,ssh -->Allow-->   log it -->  Firewall

Whole point of Distributed Topology is for the manager to connect to the firewall centrally and administer it, so you need to create a rule for that as well...

Manager-->Firewall -->https,ssh -->Allow-->log it -->Firewall

Stealth Rule - In this rule we drop traffic to the firewall unless its explicitly specified.

Any-->Firewall -->Any -->Drop-->log it -->Firewall

Network Rule - Here we define what are the services allowed to go out and connect to internet from internal network.

Netbios Rule - Generally in any network there is lot of chatter via Netbios, the same is true externally as well. This rule when applied drops all the netbios traffic from anywhere to anywhere.

Cleanup Rule - Last rule at the bottom of the list is cleanup rule. This is defined as drop anything that is not defined period.

Notice cleanup rule is at the end of the list because its deny everything. So any traffic that meets this criteria will get passed down from top to bottom and finally gets rejected.

Finally we have implied rules that are inbuilt rules that comes with checkpoint products. These rules cover "Control Connections" which will let other checkpoint products talk to each other, there is a rule that lets check point to and check/fetch updates from checkpoint website, default allow ssh and web connections for gateway admin (this is how we connected to the firewall via browser in the first place)

You can view the "Implied Rules" by going to the "Launch Menu" - "View" and select "Implied Rules" Notice the implied rules have a red tilda in front of them. 

Now lets create all the 5 rules mentioned above - 
On the Smart Dashboard click the "Launch Menu" --> Select "Rules" --> "Add Rules" --> "Top"

You will see an empty rule like below - 

You can also click the above "Red Circled" options to create rules instead of using "Launch Menu" option.
Double Click the empty space under "Name" and enter "Management"

Next when you click the "Source"  "*Any" - Here we need to specify the "Source" which can connect to the destination. As per the above 5 Policies CLientA, Manager need to connect to the firewall. You can drag and drop the objects or click "+" as shown below and select the Objects from the new popup window.

After the selections are made the "Source" should look like below...

Follow the same process for "Destination" (Drag and drop or click +) to add the firewall.

Now should look like below...

You must now decide on what services (ports) needs to be allowed from Source to destination.

After adding the services you can enable "Action" - accept, drop, reject

At the end your rule should look like below after enabling logging and selecting "Firewall" on which this is to be installed.

Now after adding all the 5 Policies should look like...

The last and final step is to SAVE the policy that we just created and INSTALL/PUSH the policy to the firewall.

Go ahead and save the policy in the first. When you save you will see a Standard profile that the checkpoint already comes with. Also if you notice you will not be able the firewall from your ClientA machine. So try to add ICMP service allow in the "INTERNAL" rule (refer the final policy screenshot above)

Save the policy as Lab_Policy_1, Notice now on the dashboard it will reflect the policy name. Next step is to Install the policy on the firewall. Check point allows you to do version control of policy by providing you an option with "Create a database version" option. There is a little bit of over head in terms of processing the request but its a good practise to create a db version. Keep in mind the disk space limitations. With logs and backups make sure you have enough disk space.                                                                           

You will see the below message once the db version is created. Click "Ok" and proceed with the policy installation on the Main Office Firewall.

Now after completion the 5 Policies we created are applied on the firewall and are active. Try pinging the firewall or do tests based on the policies we created above.
Open the "Smart ViewTracker" to look at the logs.

Clicking the Track Logs will open the Smart view tracker. Sample trace below.

We did enable ICMP to the firewall from ClientA machine.

This is the most important aspect of firewall administration is your ability to study the logs and piece together why and how traffic flows. Looking at the above you can determine

• Source - ClientA
• Dest - Firewall
• Service - ICMP
• Which interface the traffic came in - eth1
• Which rule it hit or was processed by - Management.

The above is very simple example. I will try to include more complex examples further.

Try to Play with the filters and see how you can use them. Get familiar with the "Smart ViewTracker"

Checkpoint Lab - 6 (Creating Objects) Tutorial

Objects concept - 

Before we run off any start playing with policies and rules there is one important concept I would like you to understand - Objects.

Objects are parameters that you can define and assign for example - a computer, network, services (http, icmp, ftp). The concept of creating Objects is same across multiple firewalls vendors. Creating and defining objects help us to consolidate and arrange different resources in orderly fashion.

For example let me create ClientA computer object. On the smart dashboard, under "Network Objects" select "Nodes", right click nodes, expand "Node" and select "Host" as shown below...

Fill out the name. ip address and comments sample below. You can also colour code it like for example all the internal trusted hosts or networks I use green, DMZ we can use yellow, external like firewall we can use red...again your choice. Hit "Ok"

Hit "Ok" and you should see your client machine under "Nodes". Same can be done for networks (internal and external). Go ahead and delete the "CP_default_Office_Mode_Address_Pool" object under network, we will not be using it. That object is created by default for VPN users. We will be creating the objects from scratch.

Get comfy with creating objects, using the right naming conventions (just make one up and follow it). I see admins using IP_ what ever but make sure you follow the naming convention and standardize it.
We create objects using Smart Console connected to manager. So initially rules, objects and any thing we create are stored on the manager. Once satisfied that objective has been achieved you need to then push this as a policy to the firewall gateway.