SmartConsole cli: built-in shell inside the SmartConsole. You just click its link/icon in the SmartConsole and get the shell (emulation). While it is not very suitable for automation, you can still prepare bunch of cli commands to copy and paste to this shell.

The main advantage of the API is in automating daily tasks. Some tasks I can think of: deploying gateways to the cloud (AWS/Azure), creating/deleting/editing objects and rules in the Rule Base, creating your own custom web interfaces to the management server and many more. In the webcast, the presenter Ryan Darst showed in real time how using Ansible playbook he could deploy 2 firewall Gateways from scratch into the Amazon AWS cloud, then create their rule bases with network objects, setting on the way all the needed properties of the gateway – IP addresses, routing, anti-spoofing and such. It took him some 10-12 minutes from starting Ansible deployment to having fully functional 2 gateways in the cloud that could pass and secure traffic for the networks behind them.

Doing non trivial things is not, on the other hand, the target of the API. That is, changing the underlying Gaia operating system, doing backups and other things that we are used of doing via bash scripts on the gateway remain as such. This is logical after all, the API in general are designed to automate “boring” daily tasks of large volume and also give management access/capabilities to the less qualified folks. You can for example build web interface and make available very specific tasks and commands to your SOC team, without giving them the powers to destroy something.
In the Enterprise environment, where it is a small team/one person manages the firewall such API usage is less useful, but still, occasionally we can automate time consuming tasks of bulk creation/deletion/import/export of the network objects or rules.

The Checkpoint do not state it clearly in the release notes, but the minimum requirements has changed. If you don’t want to gaze at the stuck browser while doing First Configuration Wizard for an hour or even forever, use these Virtual Machine/Open Server parameters:

Kernel debug in Checkpoint is not rare as it gives full insight how firewall processes the packets. As the most comprehensive type of debug it also loads the CPU, not catastrophically though but still. If you happen to enable kernel debug and see the system goes overload - the fastest way to disable all kernel debug is by using this command on the command line: fw ctl debug 0The last being zero, not ‘o’ .

It is not new to R80 – it has appeared in R77.30 already but somehow went unnoticed, but with R80 all the buzz about multiple administrators this draws the proper attention. I am speaking about GAIA OS administrators roles. Now we can easily create a new role and assign specific commands for a task very granularly! This means that it is not either full expert access on console/ssh, but yes clish access to OS but with very specific capabilities only.

In Checkpoint you have few options in creating NAT rules. Each option creates NAT rules in the NAT Rules policy a bit differently, here is how.
- Automatic Hide rule. Creates 2 NAT rules: one where the source is the object and the destination is the network in which the objects reides, i.e. disables NAT for the same destination case. The second rule is object as a source destination Any, translate to the Hide NAT IP.
- Automatic Static NAT rule. It creates also 2 rules: object as a source with destination Any, translate to the chosen IP, and source is Any destination is object (meaning its external IP) translate to the object (meaning its internal IP).
Always remember of course that Automatic NAT rules are created below the manual ones and Checkpoint passes the rules from the top down so order matters.

The answer is simple – just one. Beware we speak of WRITE access as well here – READ access is available to as many users as you want. But the moment the first user logs in into Gaia he automatically gets the write/read access and all the later logins (it actually can be the same username logging in) get just READ only mode. Any user (if has admin priveleges) can acquire or override the database lock from the current user and this way have write/read role.
Of course all the unsaved changes made by the previous user will be lost.

The usual way to install a policy is by clicking Install in the SmartDashboard of course, but if need arises to do so from the command line of the Checkpoint Management server we do it this way: fwm load <Name of the policy> <name of the firewall gateway object as appears in management server>
All the names in the command are case sensitive.

The Checkpoint documentation is vague about this, so let me warn you. Immediately after first install and completion of First Configuration Wizard the Checkpoint firewall gateway automatically installs preexisting Initial Policy. Which disables routing through the firewall, and by Checkpoint documentation “enables just necessary management protocols for Management Server connection”. In reality it simply means the firewall is open from ANY by ports of ssh/https/SIC communication. Therefore it is of paramount importance to chose a strong password for Gaia OS admin user – this is the only protection against brute force break in your firewall has until first install of the Security Policy.

This is one the most strong points of the Checkpoints with me from the very beginning. Unlike many other vendors, Checkpoint made possible to configure and easily ANY packet field taking part in NAT. You want IP destination based NAT ? No problem. Source based NAT ? Easy.
Port destination based NAT? Piece of cake. You will appreciate this power once you try to configure destination based NAT in Cisco ASA with access-lists.

They tried to approach this already with Checkpoint Provisioning control, but was too complicated to be adopted by a laymen like as, it was more complicating life of super admin then helping having put burden of approving changes on him.
But with R80 they take the different path – now multiple administrators can edit the same Security Policy simultaneously. And what makes it useful and practical is that granularity of such changes is per security rule. That is, if administrator A changes/changed some rule, the Administrator B will see this rule as greyed out and not editable. On the other hand all other rules are available to Administrator B to work on.
That is nice indeed.

Checkpoint firewalls are pretty dynamic and interactive to our changes, for the most of the changes done by administrator it is enough to install the policy for the changes to take immediate effect. In the rare cases when changes (seemingly) do not take effect, it is probably because the particular connection got stuck in the connection table of the firewall. There are 2 ways to fix it: the elegant and the axe way. I will post the elegant way some other day, which includes deleting only the specific stuck connection entry from the connections table, but this post is about the axe way – clearing ALL connection entries from the table in one go. This means, of course, temporary disconnection for all traffic passing the firewall, therefore use it with caution. Here it is: fw tab –t connections –x

For the correct functioning the Checkpoint uses quite a lot of ports, some are a must some or not. The ports listed above are in ‘a must’ category. Let’s see:

18190 The CPMI (Checkpoint Management Interface) is used by SmartConsole client to connect and manage the Management server. This is the port to check if trying to connect by SmartConsole you get the error “Please verify that Management is running and you are allowed to connect by GUI client”.

18209 SIC (Secure Internal Communications) protocol uses this port for all SIC conversations between the Management server and the firewall modules managed by it. This is the port to check when you try to install the Security Policy and it fails with an error “could not establish connection …” .

18210, 18211 These ports are used for the internal certificate exchange between ICA ( Internal Certificate Authority) which is part of the Management server and Checkpoint firewall modules. You don’t need this port constantly, the firewall modules and Management server exchange certificates once in a while, but still – all the communication between Management server and firewall modules is encrypted using these certificates, and if the certificate is expired and the new one cannot be downloaded the SIC will break.

It may happen to anyone – mistaken security rule “Any Any Drop”, or using dynamic object for URL block. The end result – after the policy install you have no administrative access to the firewall with SmartDashboard/ssh/https. For this case Check Point came with fw unloadlocal console expert level command to unload the Security Policy. Unlike the Initial policy when installing the firewall, here you get a firewall without ANY policy – open by any port from any source. So probably a good idea to do so after you physically disconnect the firewall from the Internet. Next step is to connect to this “naked” firewall with SmartDashboard and fix the mistake that caused this situation and install the fixed Security policy.

You may need occasionally to disconnect some or all connected users from the firewall forcibly. There are few ways I can think about to do so, for example installing Security Policy clears the cached authentication of the remote users, and while it does not disconnect them it will force a user to reenter his/her credentials. So, if you say want to disconnect a user you could expire it in SmartDashboard or change its password and then push the Security Policy.
But actually there is an easier way to do it : just go to the SmartView Monitor -> Users -> click on any of the options: Users by Gateway, Users by Name, All Users, CheckPoint Mobile Users and after finding the user you want to disconnect, right click on it and Reset Tunnel.
Here is the screenshot of this procedure:
Continue reading

Throughout its history CheckPoint firewall changed versions and names, incorporated other products. The last, so far, evolution has been the Gaia operating system released in 2012. All this holds true of course but nevertheless the base platform for the firewall all these years has been Red Hat Enterprise Linux server of different versions. The latest one used for the whole R75 and R77 line of firewalls is based on Red Hat RHEL 5.2 that was first released in 2008. This in part explains why even new firewalls still work on the old kernel 2.18. It doesn’t mean something bad in terms of its security, to remind - 'based on' means even though it is based on RHEL 5.2 it is still heavily secured and stripped down. In their latest communications Checkpoint promise in 1st quarter of 2017 to upgrade Gaia to the kernel version 3.10 as part of the move to Red Hat RHEL 7.

With a lot of attention recently to the SSL protocol vulnerabilities browser vendors
increase security of their SSL implementation almost daily. One of the recommendations is to
use the most up to date SSL version available. Check Point for its SSL based VPNs (by the way
it is the same configuration for Endpoint clients) like SNX SSL and Mobile Access can support
SSL versions in the range SSLv3 up to TLS 1.2. So if your clients’ browsers support it you
can force the specific SSL version for their connections.
Warning: do NOT set minimal SSL version higher than TLS 1.0 because this would cause internal
communication of applications of the Check Point itself to fail.
You set the parameters here: SmartDashboard -> Global Properties -> SmartDashboard Customization-
> Configure -> Portal Properties-> snx_ssl_max_ver and snx_ssl_min_ver

As usual for changes to take effect - click on Ok, Save, Install Policy

There is one setting that may expose your networks and firewall to unexpected dangers if used inadvertently. I mean Star VPN Community -> Advanced Settings -> VPN Routing . You can see there 3 options: To center only, To center and to other satellites through center, To center or through the center to other satellites, to internet and other VPN targets. If you are not sure, or almost always anyway - choose the 1st option “ To center only” . The other 2 options can be a potential risk allowing remote VPN LANs of one VPN peer to communicate with remote VPN LANs behind another, possibly unrelated VPN peer if rules permit.

In the light of all the commotion with the recommended by various vendors switch from SHA-1 to at least SHA-256 hash algorithm you may wonder what is the hash used by ICA for internal communication. The answer is - SHA-1 for all the versions still in use, including R77. You can change it to SHA-256 using the command cpca_client acording to Checkpoint sk103840 but I haven’t done it myself so not sure what are implications of this.

With previous generation of Check Point UTM appliances (so called UTM-1 which included UTM 132, 270, 450 etc.) it was a really nagging issue when firewall run out of space on its hard disk. It was especially problematic for the root partition cause it is used for update downloads, upgrade files etc. It is less of a problem today as Check Point folks made root partition by default much bigger than the old UTM-1 one, still from time to time you may need to increase root or some other partition to add free space to the firewall.
As Check Point is a Linux in disguise to do so is actually easy using native Linux tools . Fortunately UTM appliances come with quite a bit of Unallocated space you can see with fdisk -l.
This unallocated space is used to store images for factory reset in case of need so do not go wild using it up.
For resizing to take effect you will have to reboot the firewall afterwards. Here are commands to be run in expert mode:
Let's say I want to add 15 Gb to the root partition:

That is it .
BTW Officially, it is not supported by Checkpoint to modify the size of partitions / file systems on Check Point appliances. Still, many times I've done it I didn't experience any issues, but be aware.

Well, it is actually a feature not a bug of all Check Point firewalls working on Gaia. If you haven't noticed as opposed to good old SPLAT firewall platform the Gaia is selective about which routes to propagate. I gues it was done on purpose to give more control to the administrator over the routing table. One of the quirks of it is when you add a route via SSH the Linux way you don’t get any error but this new route does not show anywhere – neither in Gaia nor on Linux level. On the other hand if you add the very same route via Gaia GUI or in clish – works fine. The culprit for this behavior is this setting you can change in Gaia https GUI:

Go to Gaia https: Advanced Routing -> Routing Options -> and click to select on “Kernel Routes” -> then Apply. That is it – now if you add routes in expert mode with ip route add 192.13.13.0/24 via 192.168.13.254 this newly added static route will appear on both Gaia and Linux OS with the mark K for Kernel:

Check Point provided us many ways to debug issues. Some are easier, some are harder.
The first thing to do when you have dropped traffic is to see whether the packets are being dropped by the firewall or not. The first impulse is to look at SmartView Tracker's logs and that's ok, unless of course you have some Security Rules without log enabled on them. But there has always been available this command that gives us real time insight of what is being dropped at the KERNEL level! What can be better ? You may use it in cases when fw monitor or SmartView Tracker logs do not give conclusive results. Or, you can use it as the first command as I do - this saves time loading all the logs or decluttering fw monitor output.
The command, run in the expert mode, is fw ctl zdebug drop :

Here you can clearly see that ICMP is being dropped on Security Rule 1 (which blocks all ICMP). The tool becomes even more interesting when a firewall drops some packets NOT on rules, but say on IP Options set field.

Do not miss Netflow capability of Check Point Gaia R77 and above.
In the past measuring the traffic passing through firewall wasn't easy - you had to either query interface counters via SNMP or run custom Bash scripts on the firewall itself to get interface statistics. The problem with both of the ways was that you didn't get exact results. And to get insight into what kind of packets are going through the firewall wasn't possible to do easily at all.
Sure, you have always had SmartView Monitor dashboard to see real-time statistics, but you need a separate license for that.
Finally, starting with R76 for regular firewall and R75.40VS for virtual one we have Netflow export capability available in Gaia OS. It supports Netflow version 5 and 9. I haven't tried version 9 but all common version 5 works as expected.
Features and limitations:

SecureXL (i.e. hardware acceleration) should be enabled for correct results (most of today's firewalls have it on anyway).

You can set up to 3 external collectors to receive Netflow data. Of course it means that the same Netflow packet will be sent 3 times, I don't see reason to do so.

You can specify source IP address for outgoing Netflow packets, the defult is IP of the interface where packets leave.

Do not forget to set Netflow version, as default is 9.

To configure and enable Netflow on Gaia clish (here I send Netflow to 192.168.13.77 port 2055, version 5) :

Many times you get to work on some UTM appliance remotely via ssh and need to know which exact model it is. It takes just one cli Expert level command to know: dmidecode | grep “Product Name” . Then you go and compare the output with the UTM models table which Tobias Lachmann diligently compiled for us Determine appliance hardware from command line .As of 09/07/2016 Tobias’ website is down. So to preserve the useful info I put the list of UTM models to compare with:
G-50 Check Point 21400
P-230 Check Point 12600
P-220 Check Point 12400
P-210 Check Point 12200
T-180 Check Point 4800
T-160 Check Point 4600
T-140 Check Point 4400
T-120 Check Point 4200
T-110 Check Point 2200
L-50 Security Gateway 80

I was trying the other day to exclude on UTM 1180 gateway some IP address and service combination from being encrypted inside VPN tunnel and noted that any changes you do to the firewall files on the CLI, in this case – crypt.def, do not take effect . It is actually logical as every SK asking you to do such changes also specifies that “Changes are to be done on SmartCenter/Management server and then you are to install Security Policy” . The catch here is “installing the policy” – if it is what is known as Locally managed UTM, i.e. you manage it via its Web interface, you have no such action – “install policy” .
One solution would be to restart the UTM – works, but kinda harsh. The other solution is this undocumented (not listed in any Checkpoint documentation I searched) command :
* You should be in Expert mode to run it . Also pay attention to the output – there should be no errors.

The list of available and active Check Point modules depends on the firewall version and installed components. We have the following helpful command fw ctl debug -m to list all the modules. After getting modules and their options using them in a debug session is just a matter of enabling any of them with "+" before the name , e.g. ... +xlate to get debug of NAT translations.

Checkpoint has made available starting with R77 this helpful information utility called cpview of which not many are aware. This is basically a Bash script that runs a bunch of native Checkpoint commands in the background and displays the output on the terminal while updating the data every other second.
– Running the command (you have to be in the Expert mode):#cpview
– File location:# which cpview
alias cpview='/bin/cpview_start.sh'

The new era of sha-256 as opposed to sha-1 signed SSL certificates is slowly gaining the pace, not without a gentle push from the browser providers . And Checkpoint is catching up in its new version R77.30 for Open Servers.
While on both versions – 77.20 and 77.30 cpopenssl package gives the same version info they do differ:

openssl in R77.30 now supports SHA-256 certificates

It doesn’t mean earlier versions do not support SHA256 certificates – just that you cannot issue CSR requests signed with SHA256. Nevertheless, your SSL certificate provider technically is very much able to issue SHA-256 certificate based on SHA-1 signed CSR requests as both are not really related.

The difference is simple - the Local license is issued for the firewall gateway IP address, while Central license is issued and assigned to the IP address of the Management SmartCenter. In more practical terms it means you can attach/un-attach/re-attach Central license to/from Gateway(s) as many times as needed as long as IP address of the SmartCenter doesn’t change, thus allowing the same license to be used for different firewall gateways throughout the lifetime of the license or just changing IP addresses for the same gateway.
The Local license is not like that - from the beginning it is being issued by CheckPoint for a specific IP address of the firewall gateway and later if you want to change this IP address you have to ‘move’ the license to the new IP - and you can do it just 6 times, after that you have to buy a new license.

You may have for some reason, usually it is some compliance requirement (PCI DSS, HIPAA, etc), the need to log
everything that passes the firewall, regardless of the Log setting of each Security Rule. Check Point have thought of this need too - go to Global Properties -> Reporting Tools and click on Enable tracking all rules.
This will NOT interfere with the logging settings in the rule base - this works in parallel. Also
you have to specify another than current log server to send logs to,
which of course will require a separate license as well. This way you can
leave usual Security Policy logging for debug but send complete logs to
some dedicated logging server for storage and later retrieval.

This may happen usually for exceeding the limit of wrong password login trials by the administrator.
Sometimes this occurs when an administrator did not log out properly from the Smart Console for any reason - his/her PC crashed, connection to the Smart Center was lost, etc.
No worries, it is easy to fix, go to the command line of the Smart Center, then (if not already) into the expert mode and type:fwm lock_admin -u <account name>

This question comes up from time to time - can we copy logs of some SmartCenter to another server with installed SmartCenter software to view it. Usually you need this for archival storage of logs - you don’t want to keep terabytes of logs on the active SmartCenter just as archive.
The answer is yes - you can copy binary log files to another Management center or file storage to be later opened NOT in the original server.
Technically you do it as any file sync/transfer/backup of the Linux platform - what you need is all file in $FWDIR/log directory.

While Identity Awareness is relatively new to the Check Point firewalls, its ‘working horse’ is nothing but new - LDAP connection to the Active Directory Domain Controller. As quite extensive and complex component Identity Awareness earned its own tab in configurations menu but still, before you start configuring make sure that underlying Active Directory service is enabled and configured. And you do so by first enabling in Global properties “User Directory” that exists as I can remember at least since R55 there. To make it visual here is the screenshot where to find it:

The firewall itself is implemented as a bunch of kernel modules that plug into LInux kernel (2.6.18 as of R77.30) . From OSI model standpoint it plugs itself between the Data Link Layer and the Network Layer. It means Check Point can inspect any packets bearing IP addresses in their headers. It also means that it does not check/verify/care for Layer 2 information. So it cannot inspect Ethernet headers for example.

Configuring SNMP in Gaia as opposed to SPLAT has been made much simpler. So simple that it is easy to overlook that default configured read-only community is public .
So , it is a good idea to change it while enabling SNMP:
set snmp agent on
set snmp agent-version any
set snmp community public read-only

PS. Another ‘feature’ of the SNMP is that you can either enable SNMP version 1 and 2 or version 3. Trying to enable just version 2c is not possible.

Hi there, not much of a script , just the one-liner to turn output of the Secure Platform cli command route/ip route list into the ready for copy&paste list of Gaia clish commands.
Be aware I am not doing any error checking, so examine the final result before applying to a production system.
See ya.
You should run it on SPLAT cli being in expert mode.
ip route list | awk ‘/via/ {print " set static-route ",$1," nexthop gateway address " $3," on "}’

While not mentioned explicitly in Release Notes for SNX 75 (it lists there only Mac OS X 10.7, 10.7.1, 10.7.2 Lion, 32-bit and 64-bit as supported versions) , it does work with new version of Apple Mac.Yesterday I did it for R71.40 and it worked just fine, you have to install hotfix though – SNX_MACOS.linux.tgz .