Pushing Policy :
As said in the part-1 of this series, to push policy we need to define some rules or I’d say we need to add some security rules to the security policy.
To define a policy, we need certain objects like network object, host object, ,Address-range, User objects, VPN community objects and so on) , similarly we need to define some service objects but in checkpoint those required service objects have already been defined (like SSH,HTTP,LDAP and so on). We just need to drag and drop these objects in required policies. If it’s not there in the list then we can create also.
In our environment, user will be sitting on the Admin_PC and all these objects will be stored on MGMT server and when after creating a rule , we will push the policy to the actual firewall.
In Checkpoint , No zones are defined like many other vendors. it just takes objects into consideration like going from specific source to specific destination.
First lets set up the management rule on the firewall.
We need access to the firewall like (SSH, HTTPS) , in case if SIC communication fails then we might need to login into the device and have to again initialize the SIC Communication.
There are some other rules also which we call as Stealth
Stealth : Means anyone wants to connect to the firewall (Except a genuine user), in our case other than Admin_PC and MGMT server then deny that attempt.
Internal Rules : What internal users can access on the DMZ and outside world. By default everything is denied.
Clean up : And in the end any traffic going anywhere from anywhere will be dropped.
Now there is 1 important thing, in these policies we can enable logging , so that we can know what kind of traffic is permitted and what is getting dropped.
These are the four basic rules we have to apply on an initial stage. We’ll see other rules when we’ll include our branch firewall and do the HA function and managing everything centrally from our MGMT server.
But Wait, there is another important thing we should taken into consideration. And those are implied rules.
Implied Rules :
Implied rules are the rules which are by default defined on the firewall. we can change the position of implied rules but those will always come up over our manually defined rules.
While making the changes, we can define do we want ICMP enable on the firewall and where we want to place that rule in our database of already defined implied rules.
Also to see what all implied rules are defined , we have to follow from SMART Dashboard — Launch Menu — View — Implied rules.
But here you can see that option but you can’t open. You can’t click on it.
There is a catch here : To see the implied rules, first you have to define at least 1 manual rule and then only we can see implied rules.
Generally we don’t logging implied rules (not to burden firewall CPU/Memory) but if you want you can log the traffic hitting the implied rules (Under global properties we can enable logging).
Now at last, save the rule and push the policy.
- Now to add rule, there are multiple places from where we can insert/create a rule.
So, either way we can select to add a rule.Now, add the objects in the rule like this : Either drag and drop the objects or you can see the little + sign on services tab , that + sign is present on every tab where you want to add/delete/modify the objects.Also if there is no object present then we can create objects on the fly as well. Once any object is created, it will be shown under objects on the bottom left side of the dashboard.See below 2 snapshots :and the rule would see like this :
Here, we can see sequence number, Name of the rule, Source, Destination, VPN(If it is there), Services, Action, Track (To log traffic) , time, comment and last Installed on.
Here i have allowed services http and SSH Version 2 which are not very much necessarily , only SSH and HTTPS needed for management purpose.
Now there is 1 point to keep in mind before pushing the policy. If under “install on” policy target is selected (no specific gateway name) then we have to make sure on which target it is getting installed.
We can check it by go to Launch Menu–Policy–Policy Package Installation targets and there we can specify or check where this policy is getting installed.
Check it, if All internal security Gateways are selected then it will install this policy on all the gateways (If there are many firewalls in the environment) irrespective of their current policy.
Make sure you select the specific gateway and it should be under the list of Installation targets , like in our snapshot, it is on right side.
This generally happens if there are multiple gateways in the target list and you want to install on specific gateway. OR
What we can do , we can define gateway at the time of defining the rule , like this :
Go to the Actual rule , right click on policy targets and specify on which firewall you want this rule to be installed.
Choose the target and the rule will become like this as shown in above snapshot.
Now , our first rule is ready and we can push policy on the firewall. But as mentioned earlier , now we can see implied rules and whole long list of implied rules will be shown :
You know while booting firewall we gave the management IP and we were successfully able to https the device by a web browser. Any guess why ?
Answer is because of these implied rules, there are some rules already allowed in the firewall.
Also, if we want to allow any specific implied rule then click on global properties (Below Icon on main screen)
And then above window will appear. you can set rule position as last (even after manually specified rules) , before last and first (First actually not means the first implied rule but only Checkpoint decides where to place this rule among already defined implied rules).
By default, you can https to the firewall but not ping from Admin_PC because ICMP is blocked on the firewall. To allow , allow it specifically via manual rule or via implied rules and push the policy.
Now it’s time to push the policy.
Click on save and then click on install policy. However policy gets saved first if you directly install the policy after defining the rules. But in case you don’t install and exit from Dashboard then whole changes will be lost.
I have marked red rectangle showing where to click to save and install the policy.
When going for install below screen will appear and then click on ok to push the policy. It will first verify and then push the policy. If you get an warning post installation check them and try to resolve them else click on close.
Also click on create database version which we will discuss later in this series.
Once database version will be created , then click on OK to install the policy.
Once Installed, it will show the below message :
Now, we have installed few more policies on the gateway : Take a look and you can understand by just seeing the rules what I allowed and what I blocked.
Now, check the policy installed on the device , either see on GUI as marked by red rectangle in previous image (Standard in our case) or via cli.
Through cli, if you don’t know the subsequent commands then just type “?” and press enter
To check policy installed : see below
It tells the policy name , when was it last installed on the device and on what all interfaces on the gateway it includes.
To check the routing table : either use netstat -nr in expert mode or use show route in clish mode
To Uninstall the policy and then again install use below commands :(Do not use in production unless specifically advised)
FW fetch local : It will fetch the policy from local host.
We can also change the policy name just by going to file–save as and change the name and then push the policy on the device.
When you’ll install another policy on the gateway, it’ll ask are you really sure of installing the policy other than the current one. Say yes and it will install the new policy.
you can see all the policy under file–open
Also we can check policy installation status by click on the icon present on the main dashboard page and below pop up window will open :
–if there is some situation when we really lose the access of firewall and we only have the console access then also we can log into firewall and ask to fetch the latest policy from MGMT server.
Use Command : fw fetch <MGMT server IP> (Use carefully in production)
In our case it was already installed so the local policy was up-to-date, otherwise it’d have installed the required policy.
Natting as we all know to translate one IP address into another IP address (generally private to Public) either via static NAT or via dynamic NAT or PAT.
In this Section, i am not going to discuss how NAT works but will show how can we configure NAT on a checkpoint firewall.
So, in our topology we have R4 as our Internet Router which is having IP as 188.8.131.52 and loopback IP (184.108.40.206) and to reach them what we’ll do , we are going to NAT the source IP. In our case we are initiating the traffic from Admin_PC. So, if traffic is going from Admin_PC to Internet (220.127.116.11) then we are going to nat the Source IP.
(Also as this is our Test environment, we are considering 192.168.10.X also a public scope IP used on R1)
Reason to do Natting : Private IP to go to internet, Security(To Hide actual IP’s), Limited IP Space
Type : Source and Destination
Source NAT : we generally do source NAT when clients from internal network goes to the internet, then to translate their source to publically reachable IP , we do source translation so that return packet from destination can return back to the client.
Destination NAT : This type of NAT we generally do when we are hosting a server in our DMZ/internal zone. we basically assign private IP to our internal servers and NAT that IP to some publically routable IP, So when clients coming from internet then their destination IP is changed from public to Private(Actual DMZ server IP) and vice versa while returning the packet back to client.
There are many exceptions of NAT but this generally depends on specific requirements.
How to Translate : Static or Dynamic
In Dynamic NAT, We are going to NAT many internal IP’s to many external IP’s. But that’s not a good idea to translate each and every user to 1 specific IP. What we can do is to translate all internal users behind 1 single IP. Like in our case we can NAT our internal users on 192.168.1.100 (Firewall Outside IP) , in Cisco we call it as PAT and in Checkpoint we call it as “Hide NAT”.
We can hide the internal users either on Gateway’s outside public facing interface IP or on any other publically routable IP. Firewall will then translate the Source IP as well as the source port number of the packet originating from internal network.
Where this NAT actually happens on firewall : lets say an example in our topology, packet is originating from 10.1.1.15 (Admin_PC) then this packet will hit the firewall on it’s internal interface , then firewall will check the route and send it towards the outside interface but before going out the source of this packet will be translated to Public NATTED IP (192.168.1.100 in our case).
So with Hide NAT we are translating not only the source IP but source port as well.
Destination NAT (Use of static NAT) : Let’s say we have a server in our DMZ zone that is always up and running. then users which are coming from outside will get their destination translated only on a specific IP. In this case we need a static NAT means that client’s public destination IP should always translate on the same private DMZ server IP to access the services. Otherwise let’s say we used dynamic NAT in this case and firewall translated the destination IP on some other private IP on which required services are not running then it’ll be of no use. End user won’t be able to access the services.
So in these kind of scenarios we need static NAT.
Again, where this NAT actually happens : When client packet hits the firewall then just after entering the firewall the destination IP of the packet translates to the statically defined actual server IP and then routing happens and packet exits from the firewall from the DMZ interface.
Now, let’s demonstrate it on our firewall :
Now, go to dashboard and select NAT
And once you click on NAT, you’ll see some already defined NAT rules. We’ll generally see CP_default_office_mode_address_pool. And this is related to some VPN work which we’ll discuss later but for now we are going to set up hide NAT for our internal network.
Create an internal network object contains whole 10.1.1.0/24 network and set the network translation like this : In General tab , define the actual network and mask and any comment if you wish to and in second tab, click on the translation icon and either select Hide or static NAT (at this moment i am selecting Hide NAT). Also in Hide NAT we can see, we can define any specific IP address or hide the internal network behind gateway IP. In this case we are going to hide our internal network with gateway’s outside IP (192.168.10.100) and click on ok.
Now save and install the policy.
Once you enable Hide NAT then we’d be seeing below window
We can see rule no 3 and 4 are created once we enabled hide NAT on our internal network.
Rule no 3 Says : if packet is originating from internal network and going to the same internal network then don’t perform NAT operation.
Rule no 4 Says : for any other traffic going to any IP , translate the source IP to gateway’s outside interface IP.
Point to Note : Don’t miss the ‘ H ‘ symbol in rule no 4 in red circle, that means this is Hide NAT. For static NAT you’ll see a ‘ S ‘ there.
Now, i have opened https session to 18.104.22.168 and lets see what our firewall did to this packet.
Below is the Smart view Tracker output which we’ll discuss later but we can see from the output that source IP (10.1.1.15) and port 49177 is getting translated to 192.168.10.100 and destination port 10003. XlateSrc means the translated source address.
See the below Snapshot :
Also in above snapshot, we can see which policy name/rule number in the policy is permitting this traffic. Also if you want who did the change and when and what changes were being done then you can see in Management tab under “SMART view tracker”. We’ll talk on this later.
Now, we’ll see the destination/Static NAT :
For destination NAT, as I already mentioned clients who are coming from internet to access the server placed in DMZ zone, their destination (public) IP will be static NAT to actual server internal IP.
So, here we’ll be do the static NAT of 172.16.1.50 to 192.168.10.115 (any available IP from the assigned range).
Once this will be natted there will be again 2 NAT rules will be seen.
Here, we can see the static NAT and how the packet is translating.
In our case let’s sat 22.214.171.124 (internet router) we are going to telnet DMZ server. Now we will telnet to IP 192.168.10.115 and that destination IP should translate to 172.16.1.50 and should give us response.
Yes for that policy should be in place on the firewall from external network to actual DMZ server IP.
Why on actual IP and not on Natted public IP ?
I have already explained the destination NAT packet flow in this blog. See that and find the answer.
So below policy rule should be installed :
And now let’s test this :
R4#telnet 192.168.10.115 443 /source-interface ethernet 0/0
Trying 192.168.10.115, 443 … Open
Great….here we can see it is open.
So we saw we telnet the destination IP 192.168.10.115 from 126.96.36.199 on port 443 and it is open/permitted.
Now, let’s check it on the firewall. Again SMART view tracker will show us all the details.
Here, we can see the destination address 192.168.110.115 is being translated to 172.16.1.50 successfully and permitted by rule number 5 of the policy.
Policy Packages and database Versions :
Policy package is the policy which we install on a particular gateway. In large environments where hundreds of firewall are there, we can have separate-separate policy packages for a particular set of firewalls and in some small environments we can manage multiple firewalls from the single policy package as well. It just all depends on requirement to requirement.
In our case, I’ll be installing and managing the Branch firewall from our same MGMT server.
So, in same policy package we can define sections means these rules are for firewall-1 and these are for firewall-2 and so on.
Or we can have multiple policies for different gateways.
Now to manage the branch firewall, what i am doing is to NAT our MGMT server IP because from this IP we’ll be managing the remote firewalls and hence this should be publically routable IP and STATIC NAT needed here.
So, i am going to NAT MGMT IP (10.1.1.20) to 192.168.10.120 (our outside publically routable IP)
As you can see we have static NAT the MGMT server IP on externally routable IP 192.168.10.120. We are going to install this NAT rule on HQFW1, so we can specify this and there is one more click “Apply for securing gateway control connection”. This means as we are going to manage another firewall at the branch office, we’ll be using this NAT address to reach the remote BRFW address. And this NAT rule will be seen under NAT rules like this :
First install the BRFW on the system. Give IP 192.168.20.200 on eth0 interface of the firewall which will also be the management IP with default gateway 192.168.20.1 (Refer to topology diagram).
Also complete the first time wizard on the BRFW same like HQFW.
Interface configuration after completing the first time wizard on BRFW:
Now, to discover the branch firewall i am going to use the Wizard mode like as we did use classic mode when we discovered the HQFW1.
Go to Checkpoint(Bottom left under network objects on main Dashboard page)–right click and select security gateway/management and then choose the wizard mode to continue…
To test the SIC connection : click on test SIC as per above snap and you’ll see below screen :
And to manage this firewall let’s create a whole new branch firewall policy.
Go to Launch Menu–file–new and below pop up window will appear
Give the firewall policy name and click on the URL filtering line icon and click ok. Once you click ok whole new screen will appear with no rules (of course implied rules will be there).
and to manage the branch firewall I am creating some branch objects, adding the below rules and installing the policy on BRFW.
(10.2.2.0/24 Branch Inside network)
To Install the policy package, click on install policy. But now to where to install this. If we are going to install it on our HWFW also then we’ll lose all our access then here we have to carefully choose our branch firewall. But what if we have hundreds of firewall then to select 1 gateway do this :
Click on the select target and check the policy package which are installing and select the specific gateway and click on ok. and then only BRFW will be seen under installation target and click on ok to install the policy. By this way BRFW-Policy will be installed on the branch firewall only.
To SSH the BRFW from our Admin_PC, apply Hide NAT on the Admin_PC and install on HQFW1.
Install the policy and take SSH of the BRFW.
To take the SSH session from Admin_PC of the BRFW, make sure you are not netting the traffic as per given rules we defined on the BRFW-Policy else the traffic will be dropped @BRFW end.
database Version (Revision control) :
As we go on to push our policy, under advance section there is database version option. Whenever we create this, this not only includes rules but objects also which are present in security manager.
If you only want to create the database version then go to :
Launch menu–file–Database revision control and click on create.
Also click the keep this version from being deleted automatically if you don’t want to get it deleted automatically.
And to configure how many revision controls you want to keep before it gets deleted. Configure it like this :
Also if we click on create a new database version upon installation of policy then this will always get selected every time we will go for policy installation.
Save and push the policy.
Now, let’s merge both the policies and rules will be like this :
I’d be also be mentioning sections (In Yellow lines) to clearly distinguish one rule-set from another.
Also once we will install the policy, after creating the database revision it will pop up with below message for both the firewalls. Say yes to continue and install the new HQ-BR-Policy.
Now if for example any catastrophic failure happens or someone has pushed some rule to block the production mission critical traffic or someone has unload the policy then what to do :
In that situation database version is a great thing to restore last saved version.
First check the SIC communication with firewall and if that is communicating then load the latest saved database revision which you think was correct and load that version.
For an example : let’s delete few rule and check this. I am going to delete rule no 5 to 8 and some objects from our dashboard and then will use the database version.
To restore go to : launch menu–file–database Revision control–select the latest version–click on action–restore version and then in new window click on next.
click next here, and then it’ll ask for the creation of backup version (Backup of currently installed version in case the reverted one is worse than the present one)
and in next window click on restore. Once it will be completed then dashboard will again restart and now click on save and install the policy again to make it functional.
- Checkpoint – Checkpoint Fundamentals and first time configuration Wizard – Part I
- Checkpoint – Pushing Policy, NAT , Policy Packages and database Versions – Part II
- Checkpoint – SMART View Tracker and SMART View monitor – Part III
- Checkpoint – LDAP, identity Awareness, HTTPS inspection, App control and URL Filtering – Part IV
- Checkpoint – Command line Interface and IPSEC VPN – Part V
- Checkpoint – SMART Update, Remote Access VPN and High Availability – Part VI