Check Point R75 Terminology

and Architecture
Posted on June 11, 2012 by Shoaib Merchant

14 Votes
Before diving into Check Point firewalls and creating security policies and other stuff it is
essential to understand the architecture of Check Point and how it exactly works. This post will
help you to get a feel of what Check Point firewalls are and how it works in a multilayer
approach developed by Check Point. Below are the most common terms that should be sufficient
for you to get started with Check Point firewalls.

The Terminology
Smart Console It is a set of GUI applications that allows security administrators to configure
and manage the global security policy for the entire organization. There are quite a few clients
available in the smart console, each for a different purpose. Of all those clients the main client
application used is called SmartDashboard , which is used to configure the security policy of the
network. SmartDashboard connects to the Security Management Server which houses the actual
security policy database of rules and objects.
Security Management Server The Security Management Server contains the global security
policy for an organization. This policy is defined using the SmartDashboardhowever, the
policy is actually saved on the Security Management Server. It contains the following databases:
Object database, User database, Security rules and Log database. The Security Management
Server interacts with the Security Gateways by uploading security rule sets specific to the
Security Gateway and by receiving logging information from the Security Gateways. The
Security Management Server package can be installed on the following supported platforms:
Windows 2003 and 2008, IPSO (FreeBSD) and SPLAT (Linux based).
Security Gateway They are nothing but the firewalls you have always known. Security
Gateways are installed/located where the security rules must be applied. So, the security rules are
created using the SmartDashboard which is then saved on the Security Management Server and
pushed on the intended Security Gateway.

Platforms Check Point is a complete software based firewall which has to be installed on a
Guest OS such as Windows 2003/2008, SPLAT (Check Point Linux distribution based on RHEL)
or Nokia IPSO (based on FreeBSD) running on appropriate hardware.
When installing Check Point on Windows you have to make sure that Windows is properly
hardened and the OS itself is completely secure. The other flavors SPLAT and IPSO are custom
made for installing Check Point on hardware manufactured by Nokia (which is now bought by
Check Point) and do not need any hardening process to make it secure as the bare essentials of
what is required from the OS is made available and the rest is done away with. Once the guest
OS is ready you can install Check Point firewall right away by installing the appropriate image
based
on
your
guest
OS.
The installation is obviously a little different than the normal applications you install everyday,
but you get the point right? And, this is what makes Check Points architecture different from the
other vendors.

The Architecture
Now that you know what is what, the architecture of Check Point firewalls should be a little
easier to understand. Check Point firewalls can be deployed in a standalone fashion or a
distributed one. Lets look at the difference between the two:Stand-alone deployment:

In a stand-alone deployment, your Security Management Server and Security Gateway is

installed on the same platform and your smart console will most probably be installed on a
separate platform with which you will access the Security Management server to create policies
and push it to the Security Gateway (which is the same device in this case). However, this
deployment defeats the whole purpose of Check Points three-tiered architecture and is not
recommended by Check Point, except for small businesses.
Distributed deployment:

A distributed deployment is more commonly known as a Three-Tired architecture, wherein each

component is installed on a separate platform and this type of deployment is highly
recommended by Check Point. Smart Console is usually installed on Windows for its ease of use.
Security Management Server can be installed on Windows/Linux/FreeBSD platform depending
on the requirement. And the Security Gateway too can be installed on a
Windows/Linux/FreeBSD platform as per the requirements (but seriously, Windows for a
security gateway?!)
P.S: The terminology defined above mainly applies to R75 but the architecture is the same for
below versions as well.

Order of Rule Enforcement in Check

Point R75
Posted on March 29, 2013 by Shoaib Merchant

6 Votes
The following lists the order in which the rules/policies/ACLs (whatever you may call it) are
enforced in Check Point R75:1. Anti-spoofing check
2. Implied rules configured First in the Global Properties.
3. Stealth rule (normally the first explicit rule)
4. All explicit rules except the last rule
5. Implied rules configured Before Last in the security rule base
6. Cleanup rule (normally the last explicit rule)
7. Implied rules configured Last in the security rule base
8. Implicit drop rule
9. Address translation rule base
P.S: Implied rules are configured under Policy > Global Properties, and can be viewed in View
> Implied Rules.

Understanding Inspection Points in

Check Point
Posted on June 29, 2014 by Shoaib Merchant

12 Votes
I was just about to put some FW Monitor templates on my blog for quick reference when I need
to troubleshoot some issues in Check Point but I thought it would be a nice thing to explain this
first (for myself too, as I keep forgetting this stuff :D).
When traffic flows through a Check Point Security Gateway (look here if you want to know
about the architecture) it has to cross a series of inspection points. This post tries to explain what
those inspection points are and how to troubleshoot traffic flows based on the inspection points.
The next post will show how to use the FW Monitor.

Inspection Points (in the order they are passed):

1st
2nd
3rd
4th

i Pre-inbound
I Post-inbound
o Pre-outbound
O Post-outbound

rule/inspection is applied at this point

after being permitted by the rule/inspections
route look up has been performed to determine the egress interface
after egressing the correct firewall interface based on route lookup

The above image shows how a firewall kernel protects the Check Point OS. The start and end
depict the start and end of the originating traffic flow. The return traffic too goes through the
same inspection points. The below diagram shows how a complete two-way traffic is treated by
the inspection points.

For a complete two-way communicating traffic you should see 8 logs

(also depends if you do want to see 8 or less)
So looking at the above diagram you see that a complete traffic flow of a two-way
communication goes through 8 inspection points;
Originating
traffic
from
A
to
and the return traffic from B to A = 4 logs of iIoO

logs

of

iIoO

I you dont want to see what is going on at the inspection points I and o then you only grep i
and O and get 4 logs in total for a complete two-way traffic;
Originating
traffic
from
A
to
and the return traffic from B to A = 2 logs of iO

logs

of

Sometimes you wont see 8 logs for a complete two-way communicating traffic
and will only see 4 logs

iO

If you are grepping iIoO in your captures and you still dont see a I or o, but you do see a i
and an O, then most likely SecureXL is fast switching/accelerating the traffic because the initial
packets of that flow were already allowed.
You can disable SecureXL while setting captures if you want to inspect them at that granularity
(i.e I and o). In my experience, disabling SecureXL hasnt been a problem* and I havent seen
any performance impact as such.
Right before the capture, turn off SecureXL on the gateway:
fwaccel off

Immediately after the capture, turn on SecureXL on the gateway:

fwaccel on

To turn on fw accel on multiple VSXs at once:

fwaccel on -a

*Do it at your own risk, I do not take any responsibility for anything going wrong with this as it
does affect the live traffic immediately. Read the site disclaimer. :)

Troubleshooting the inspection points

Troubleshooting i When you dont see any traffic on the i inspection point:Traffic isnt hitting your firewall. You wont get back any captures and the console will just be a
black blank screen (or any other background color you use on your terminal :D).
Troubleshooting I When you see traffic hitting the i inspection point but dont see it hitting
I:The firewall is blocking that ingress traffic either by a rule, improper NAT, IP spoofing,
Application Inspection or anything else that you can think of.
Troubleshooting o When you see an i and I but dont see an o:Im not very sure on this but in one case that I observed, there was a route missing for the
destination in the routing table, so the route look up failed to determine an egress interface and I
didnt see the traffic hitting o and it was stuck at I.
Troubleshooting O When you see an i, I and o but not an O:I too dont know, please tell me what that would be and Ill update it here. :) I think it might be
some kind of inspection or something. But Im quite sure it will be a very rare case.

FW Monitor
FW Monitor is the tool that can be used to see your traffic flowing through different inspection
points. FW Monitor cannot give you the information what SmartviewTracker/Monitor can,
because it is a wire capture. It just tells you what is on the wires and does not look into the rule
base to see which policy allowed the traffic and was it NATd or not. So the Smartview Tracker
and Monitor serves a slightly different purpose than the FW Monitor.
Im writing a separate post on how to use the FW Monitor at its best and in different ways so
you can be better at troubleshooting traffic flow issues in Check Point.

Analyzing FW Monitor Output in CLI

Posted on November 11, 2014 by Shoaib Merchant

3 Votes
If you understand the inspection points in Check Point and can use FW Monitor to get the
required logs/captures then you can read further on how how to analyze those logs.

So to start off with, lets see what the different fields are in the above picture of a sample log from
the console;
Virtual Firewall
System
Firewall interface
Inspection Point
Packet Length
Source IP
Destination IP
Header/Payload

This shows the VSX from which the log was captured from.
Depending on your hardware/software platform you may or may not
see this field.
This is the interface where the traffic was seen and captured.
This can be either (i), (I), (o) or (O) based on what you are grepping
when you setup the fw monitor. Read more about inspection points
here.
This is the size of the frame as seen on the wire
The source
The destination
The type of header on that packet. Can either be TCP/UDP or
something else in similar lines.

Packet ID
Source Port
Destination Port

TCP Flags

Sequence Number
Acknowledge
Sequence Number

This is a unique number assigned to a packet until it is changed/altered

in its course. Quite important when it comes to reading the fw monitor
logs on your the console. (I also want to say this is locally significant
on the firewall, but not very sure about it.)
The source port
The destination port
One of the most important fields in my opinion. These are the TCP
flags you have always know about. 6 bits are reserved for the TCP
flags denoted by 6 dots () in the logs. Each dot is a TCP flag in
this order FSRPA* = FIN-SYN-RST-PUSH-ACK-*** and I dont
know what the last one is, yet. So, you will usually see something like
this for a SYN-ACK = .S..A. | RST = ..R.. | PUSH ACK = PA. |
Hope I made this simple enough for you to be able to interpret the TCP
flags.
This is the sequence number that is the usual thing for TCP because of
which it gets its name for being a reliable protocol.
This is again a part of its reliable behavior where the other end host
responds to denote that it has received its previous packet.

Now that we know which field means what, lets see how all of this fit together; Below is a
complete set of logs for a two-way communication between two hosts (from the time
it originates and gets back a reply from the destination). I omitted the (I) and (o) to minimize the
amount of logs here so were only inspecting (i) pre-inbound and (O) post-outbound. Well take
our time to analyze the logs and see what each set of packet ID means.
Logs on the console:
[vs_4][fw_0] wrp256:i[48]: 10.1.1.1 -> 20.2.2.2 (TCP) len=48 id=27361
TCP: 59255 -> 443 .S.... seq=6cc07657 ack=00000000
[vs_4][fw_0] bond31.69:O[48]: 10.1.1.1 -> 20.2.2.2 (TCP) len=48 id=27361
TCP: 59255 -> 443 .S.... seq=6cc07657 ack=00000000
[vs_4][fw_0] bond31.69:i[48]: 20.2.2.2 -> 10.1.1.1 (TCP) len=48 id=44853
TCP: 443 -> 59255 .S..A. seq=37a73c7d ack=6cc07658
[vs_4][fw_0] wrp256:O[48]: 20.2.2.2 -> 10.1.1.1 (TCP) len=48 id=44853
TCP: 443 -> 59255 .S..A. seq=37a73c7d ack=6cc07658
[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27386
TCP: 59255 -> 443 ....A. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27386
TCP: 59255 -> 443 ....A. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] wrp256:i[158]: 10.1.1.1 -> 20.2.2.2 (TCP) len=158 id=27396
TCP: 59255 -> 443 ...PA. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] bond31.69:O[158]: 10.1.1.1 -> 20.2.2.2 (TCP) len=158 id=27396
TCP: 59255 -> 443 ...PA. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] bond31.69:i[87]: 20.2.2.2 -> 10.1.1.1 (TCP) len=87 id=45365
TCP: 443 -> 59255 ...PA. seq=37a73c7e ack=6cc076ce
[vs_4][fw_0] bond31.69:i[633]: 20.2.2.2 -> 10.1.1.1 (TCP) len=633 id=45621
TCP: 443 -> 59255 ...PA. seq=37a73cad ack=6cc076ce
[vs_4][fw_0] wrp256:O[87]: 20.2.2.2 -> 10.1.1.1 (TCP) len=87 id=45365
TCP: 443 -> 59255 ...PA. seq=37a73c7e ack=6cc076ce
[vs_4][fw_0] wrp256:O[633]: 20.2.2.2 -> 10.1.1.1 (TCP) len=633 id=45621

TCP: 443 -> 59255 ...PA. seq=37a73cad ack=6cc076ce

[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27478
TCP: 59255 -> 443 ....A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27478
TCP: 59255 -> 443 ....A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27479
TCP: 59255 -> 443 F...A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27479
TCP: 59255 -> 443 F...A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] bond31.69:i[40]: 20.2.2.2 -> 10.1.1.1 (TCP) len=40 id=11794
TCP: 443 -> 59255 ....A. seq=37a7436b ack=6cc07a19
[vs_4][fw_0] wrp256:O[40]: 20.2.2.2 -> 10.1.1.1 (TCP) len=40 id=11794
TCP: 443 -> 59255 ....A. seq=37a7436b ack=6cc07a19

Each packet ID is shown at different inspection points depending on how the fw monitor is set.
In our example we are looking for only (i) pre-inbound and (O) post-outbound so we see two
logs with the same packet ID. If we were looking for all 4 inspection points (iIoO) we wouldve
seen 4 such logs with the same packet ID. Makes sense? Okay, lets proceed
Starting with the first packet ID 27361:
[vs_4][fw_0] wrp256:i[48]: 10.1.1.1 -> 20.2.2.2 (TCP) len=48 id=27361
TCP: 59255 -> 443 .S.... seq=6cc07657 ack=00000000
[vs_4][fw_0] bond31.69:O[48]: 10.1.1.1 -> 20.2.2.2 (TCP) len=48 id=27361
TCP: 59255 -> 443 .S.... seq=6cc07657 ack=00000000

The first log with packet ID 27361 was seen on the virtual firewall 4 on ingress interface wrp256
on the (i) pre-inbound inspection point. Requestor 10.1.1.1 has sent a SYN (.S.) to 20.2.2.2 to
setup an HTTPS (443) connection. In the second log with the same packet ID we see the exact
same information but the inspection point has changed here to (O) and the egress interface to
bond31.69. This tells us the SYN packet was successfully passed through the firewall towards
the destination IP. Keep an eye on the seq and ack numbers from now on.
Next packet ID 44853;
[vs_4][fw_0] bond31.69:i[48]: 20.2.2.2 -> 10.1.1.1 (TCP) len=48 id=44853T
CP: 443 -> 59255 .S..A. seq=37a73c7d ack=6cc07658[
vs_4][fw_0] wrp256:O[48]: 20.2.2.2 -> 10.1.1.1 (TCP) len=48 id=44853
TCP: 443 -> 59255 .S..A. seq=37a73c7d ack=6cc07658

This is the SYN-ACK (.S..A.) that responder 20.2.2.2 is sending back to the requestor 10.1.1.1.
Notice how the ingress/egress interfaces are swapped now, since this is the exact opposite traffic
flow, obviously. Now carefully compare the seq and ack number with that of the first packet ID
27361. Packet 27361 did not have an ack number since it was the first packet that was being sent
but it did have a seq number 6cc07657 to which 44853 replied back incrementing it by 1 in its
ack 6cc07658. It has also sent a seq number of 37a73c7d in the SYN-ACK, so in the next
packet that will be an ACK from the requestor, we should see the ack number of 37a73c7e.

Next packet ID 27386;

[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27386
TCP: 59255 -> 443 ....A. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27386
TCP: 59255 -> 443 ....A. seq=6cc07658 ack=37a73c7e

Look at the ack number 37a73c7e, it has incremented by 1 to the seq number of the previous
packet. This keeps on going back and forth until this session is torn down. So if you dont see
proper seq and ack numbers in sync, it should tell you that you are missing some packets (that
would result in seeing many re-transmissions and out-of-order logs in wireshark). So this is an
ACK (.A.) response by the initiator (10.1.1.1) which now completes the TCP three-way
handshake.
Next packet ID is 27396;
[vs_4][fw_0] wrp256:i[158]: 10.1.1.1 -> 20.2.2.2 (TCP) len=158 id=27396
TCP: 59255 -> 443 ...PA. seq=6cc07658 ack=37a73c7e
[vs_4][fw_0] bond31.69:O[158]: 10.1.1.1 -> 20.2.2.2 (TCP) len=158 id=27396
TCP: 59255 -> 443 ...PA. seq=6cc07658 ack=37a73c7e

Immediately after the three-way handshake, the requester sends its HTTPS request to the
responder that we see in the PUSH-ACK messages (PA.). You will also notice the packet
length has changed since it now contains a good amount of payload (len=158).
Next packet IDs are 45365 and 45621;
[vs_4][fw_0] bond31.69:i[87]: 20.2.2.2 -> 10.1.1.1 (TCP) len=87 id=45365
TCP: 443 -> 59255 ...PA. seq=37a73c7e ack=6cc076ce
[vs_4][fw_0] bond31.69:i[633]: 20.2.2.2 -> 10.1.1.1 (TCP) len=633 id=45621
TCP: 443 -> 59255 ...PA. seq=37a73cad ack=6cc076ce
[vs_4][fw_0] wrp256:O[87]: 20.2.2.2 -> 10.1.1.1 (TCP) len=87 id=45365
TCP: 443 -> 59255 ...PA. seq=37a73c7e ack=6cc076ce
[vs_4][fw_0] wrp256:O[633]: 20.2.2.2 -> 10.1.1.1 (TCP) len=633 id=45621
TCP: 443 -> 59255 ...PA. seq=37a73cad ack=6cc076ce

The responder has replied back as we see the PUSH-ACKs going back to the requester and the
packet length has a significant value.
Next packet ID is 27478;
[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27478
TCP: 59255 -> 443 ....A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27478
TCP: 59255 -> 443 ....A. seq=6cc07a18 ack=37a7436b

The requester 10.1.1.1 has replied back with an ACK to the HTTPS response it received from the
responder in the earlier packets that were seen.
Next packet ID is 27479;

[vs_4][fw_0] wrp256:i[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27479

TCP: 59255 -> 443 F...A. seq=6cc07a18 ack=37a7436b
[vs_4][fw_0] bond31.69:O[40]: 10.1.1.1 -> 20.2.2.2 (TCP) len=40 id=27479
TCP: 59255 -> 443 F...A. seq=6cc07a18 ack=37a7436b

The requester then sends a FIN-ACK telling the responder Im done with my requests and Ill
close this session from my end.
Next packet ID is 11794;
[vs_4][fw_0] bond31.69:i[40]: 20.2.2.2 -> 10.1.1.1 (TCP) len=40 id=11794
TCP: 443 -> 59255 ....A. seq=37a7436b ack=6cc07a19
[vs_4][fw_0] wrp256:O[40]: 20.2.2.2 -> 10.1.1.1 (TCP) len=40 id=11794
TCP: 443 -> 59255 ....A. seq=37a7436b ack=6cc07a19

The responder acknowledges the closing of the session too and the connection comes to an end.
Pheww.
Throughout all this traffic going back and forth, you want to keep an eye on the TCP flags as that
is where you will see the most problems. Also when you want to troubleshoot packet loss,
seq/ack numbers are your best friend and you want to track them very diligently.