Checkpoint_Technology

A Quick Recap

CheckPoint security revolves around 3 key components

• GUI Clients – This is is mainly SmartConsole and it’s contained applications such as Update, Tracker and Dashboard. All release candidates for this are a separate track to the main product suite and HFAs for this set are independent of the main software release. These are effectively the software configuration and interaction between the user and the SMS/Gateways/Reporting
• Security Management – Responsible for all management of the CheckPoint system. It interacts in User-Mode Processes (Explained later) in order to configure all product suites and relies on the following (most significant) processes
  • FWM
  • FWD
  • CPD
  • FWSSD
  • CPWD
• Gateway – The gateway is the device that enforces your security policy. It is really just a computer running software including an OS as normal (IPSO, SPLAT,GAIA etc.) and as such is technically vulnerable. To get around this the firewall runs in the Kernel of the system, separating the hardware from the OS and protecting itself. The above listed processes run as User-Mode processes in the OS. Traffic flow is therefore NIC -> Kernel -> OS (Including IP stack) -> User-Mode features

User and Kernel Mode Processes

So what’s the difference between the two? The Kernel is in effect the binder for the Hardware to Software traffic flow. It intercepts all traffic and provides the interaction between the Modules and Drivers. Modules here (in the Firewall-1 Kernel) would included processes for NAT, Security Enforcement, Encryption and Decryption. Pretty much the things we think of that make it a firewall. Every bit of data (or packet) that arrives at the firewall will hit the Kernel and be inspected. the inspection decides what happens to it, whether it be dropped, forwarded or some other operation applied such as crypto functions.

On top of this (almost literally!) resides the User-Mode. These processes allow the Gateway to utilise functions of the underlying operating system in a protected environment. An example of these are the processes listed earlier such as FWM and FWD.

Communication is handled from the Kernel to User-Mode using traps (Think SNMP) and from User-Mode to Kernel using IOctl, allowing the entity to call a function in the Kernel and write to it.

This entire segregation here is necessary and understanding it allows you to debug effectively. For example, if your log server is no longer receiving logs, why? The Security Policy (In the Kernel) looks fine and you have enough disk space. Start debugging the right User-Mode process and it will usually direct you where to look – FWD. This can save a lot of time.

By Process of Elimination

The core process we find on every CheckPoint product is CPD. This is the life of the devices and handles many things. The primary features we may see it handling are:

• SIC
• Status (AMON status pulled from GW/SMS and sent to SmartEvent)
• Message handling between Firewall-1 processes
• Policy installation on Gateways

I suppose you could think of it as a conductor, it calls and controls how other parts of the system interact.

FWM is a management process that exists on all management products such as the SMS. Some of the functions it does are:

• Talking between the GUI and SMS (SmartConsole)
• Database Editing; adding objects, users rules etc.
• Security Policy Compilation
• Log display
• Management HA Sync between SMSs

Logging to internal and external servers including the management server is handled by FWD(TCP/257). It also handles calling some child processes such as VPND and interacts with policy installation. FW commands in the shell such as fw ctl chain are also handled here

FWSSD is spawned by FWD as a child process and runs the Security Servers. There are multiples of these that run, one for each service and are labelled as in.xxx or out.xxx where xxx = service (such as DLP or SMTP). Some examples are:

• in.asmtpd = SMTP Security Server
• in.ahttpd = HTTP Security Server
• in.emaild.smtp
• in.emaild.pop3

You can view these by entering Expert mode and running

cat $FWDIR/conf/fwauthd.conf

THE EBB AND FLOW (PLUS CHAINS)

One of Checkpoints’ inventions as they like to tout (and rightly so) is the idea of Stateful Inspection, which we have looked at before. The overview here is that it allows a packet to be identified not only by it’s IP and Port, but also by it’s state, flow and extensibility. This allows us to allow our firewall to add in permit statements as and when needed based upon the conversation it is having – allow traffic to the Internet from your LAN and return traffic is allowed by default, but only once verified and by conversation. The other thing to note is that passing traffic based upon a state table is MUCH faster than sequentially querying a rule base each time a packet comes in (providing it has already been identified). We will cover this more later.

Packet Flow

A firewall has two main directions that traffic can flow, and most of the time it will abide by both. Simply this is “Inbound” and “Outbound”. Sounds simple, and really it is – a packet heading to the firewall is inbound and traffic exiting the firewall is outbound. This is an important consideration when reflected upon as follows. We receive a reply packet that has traversed over a VPN from a partner company. What do we do with it? Common sense says “decrypt the packet and apply to to a rule base”. Common sense would mostly be right, but let’s say the packet was NATd originally on our firewall, what then? Looking at this logically allows you to mostly guess what happens, but the real order of operation comes from what is known as an FW CTL Chain, or Firewall Control Chain. These are similar between gateways but can vary depending on the blades you’re running. Some basic facts around these

• The Kernel makes no assumptions – just because another part of the kernel may have inspected it before, it takes no chances and will do so again
• Some functionality occurs both inbound and outbound
• Each direction has its own chain modules and they will vary slightly
• The modules known as Handlers, each decide whether to pass or drop the traffic based upon their inspection role
• Inspection is performed on virtually defragged packets

The gateway will assume however that if something didn’t come IN an interface (or chain) then it (the gateway) generated the packet. Likewise, if it came through an inbound module then it didn’t send it.

Some example chain modules are:

• IP Options (strip in)
• IP Options (strip out)
• VPN Decrypt (Inbound)
• IP Options Restore
• HA forwarding
• VPN Encrypt (Outbound)
• TCP Streaming

Expert@CPGW-01]# fw ctl chain
in chain (20):
0: -7ffffff0 (f163cf00) (00000001) tcpt inbound (tcp_tun)
1: -7f800000 (f21eadc0) (ffffffff) IP Options Strip (in) (ipopt_strip)
2: -7d000000 (f1644440) (00000003) vpn multik forward in
3: – 2000000 (f162ab50) (00000003) vpn decrypt (vpn)
4: – 1fffff8 (f16358e0) (00000001) l2tp inbound (l2tp)
5: – 1fffff6 (f21ec0c0) (00000001) Stateless verifications (in) (asm)
6: – 1fffff5 (f2788530) (00000001) fw multik VoIP Forwarding
7: – 1fffff4 (f229f6f0) (00000001) fw early SIP NAT (sipnat)
8: – 1fffff2 (f16515d0) (00000003) vpn tagging inbound (tagging)
9: – 1fffff0 (f1628bd0) (00000003) vpn decrypt verify (vpn_ver)
10: – 1000000 (f2241650) (00000003) SecureXL conn sync (secxl_sync)
11: 0 (f219ae00) (00000001) fw VM inbound (fw)
12: 1 (f2204d00) (00000002) wire VM inbound (wire_vm)
13: 2000000 (f162b8b0) (00000003) vpn policy inbound (vpn_pol)
14: 10000000 (f2247410) (00000003) SecureXL inbound (secxl)
15: 7f600000 (f21e14e0) (00000001) fw SCV inbound (scv)
16: 7f730000 (f232e6b0) (00000001) passive streaming (in) (pass_str)
17: 7f750000 (f2497090) (00000001) TCP streaming (in) (cpas)
18: 7f800000 (f21eb150) (ffffffff) IP Options Restore (in) (ipopt_res)
19: 7fb00000 (f2459170) (00000001) HA Forwarding (ha_for)
out chain (17):
0: -7f800000 (f21eadc0) (ffffffff) IP Options Strip (out) (ipopt_strip)
1: -78000000 (f1644420) (00000003) vpn multik forward out
2: – 1ffffff (f1629c80) (00000003) vpn nat outbound (vpn_nat)
3: – 1fffff0 (f2496f10) (00000001) TCP streaming (out) (cpas)
4: – 1ffff50 (f232e6b0) (00000001) passive streaming (out) (pass_str)
5: – 1ff0000 (f16515d0) (00000003) vpn tagging outbound (tagging)
6: – 1f00000 (f21ec0c0) (00000001) Stateless verifications (out) (asm)
7: 0 (f219ae00) (00000001) fw VM outbound (fw)
8: 1 (f2204d00) (00000002) wire VM outbound (wire_vm)
9: 2000000 (f162b360) (00000003) vpn policy outbound (vpn_pol)
10: 10000000 (f2247410) (00000003) SecureXL outbound (secxl)
11: 18000000 (f22cf850) (00000001) fw record data outbound
12: 1ffffff0 (f1635570) (00000001) l2tp outbound (l2tp)
13: 20000000 (f1629ef0) (00000003) vpn encrypt (vpn)
14: 60000000 (f163d160) (00000001) tcpt outbound (tcp_tun)
15: 7f700000 (f2499100) (00000001) TCP streaming post VM (cpas)
16: 7f800000 (f21eb150) (ffffffff) IP Options Restore (out) (ipopt_res)

Above is an example of the chains

X – Module location in chain (Serial Number)

X – Chain Position

X – Function Pointer

X – Mode: Stateful Mode

X – Mode: Wired Mode

X – Mode All Packets (00000003 & ffffffff are identical)

X – Chain Name

The location of modules within the chains are relative and can differ between gateways depending on the modules installed. the Chain Position is an absolute number and never changes between gateways

INSPECT AND INSTALL PROCESS

Some of the sections we go over are going to be partial recaps on others. A lot of the course does this, especially considering how closely they are tied together within processes (not to mention my less than professional writing ability). After looking at the inspection areas, lets have a look at the “complete” packet flow.

1. Packets arrive at the NIC on the appliance inbound, for the sake of assumption it’s from an internal client accessing the web
2. The firewall kernel will process inspection on the packet
3. Once a packet is matched against the rulebase a log is sent to the Gateways’ user-mode FWD process
4. The GW FWD process sends a log to the SMS FWD process using the CPD daemon
5. FWM on the SMS logs to SmartConsole (SmartviewTracker)
6. Lastly the packet is routed (usually, unless it’s VPN for example) using the OS to the relevant outbound NIC where the kernel intercepts and does its outbound work

The policy installation process is am ore interesting one, simply because compared to certain other firewalls, there is rule computation, compilation and composition based upon a number of internal files within the units. This is also an extremely good reason (There are many) to have a distributed deployment as opposed to standalone. Have your SMS sitting on a secured internal VM where it doesn’t matter what happens to the gateways – you can’t recover as easily from a failure by just copying and pasting config like you can on an ASA or NetScreen. Here’s an overview of policy installation:

1. Create your policy within Smart Dashboard – let’s assume it’s just some outbound rules and a few manual NATs with a policy called SUPERSECURE
2. When you save you create a new file called SUPERSECURE.W within $FWDIR/conf. All these aresaved within rulebases_5_0.fws
3. The fwm_gen process then compiles your selected policy (SUPERSECURE.W) into a .pf file within the same location.

The .pf files themselves are composites from a number of files: *.W and objects.C and are stored in machine language within $FWDIR/conf. Objects.C is also a file specific to the policy installation only, it exists in $FWDIR/database and is relevant to that gateway only. Objects_5_0.C contains all objects defined, whether in use within that policy or not and exists on the SMS under $FWDIR/conf

One reason for this is as such: if you have an SMS, say a Smart-1 that is managing multiple nodes, they may share the same objects. Each gateway may have VPNs between them so will need to know the CheckPoint Gateway objects, their subnets, ports etc. The objects_5_0C file means that you only need to have them specified once, why duplicate? Each gateway then borrows the relevant parts from this file and has its own objects.C file created for it.

Actually installing the policy goes through an umber of steps:

1. Initiation – You click your install button within SmartDashboard to start the process and provide information it needs (such as the gateway it needs to install on, does it matter if it fails one one, DB revision?)
2. Verification – This is where the SMS goes over your policy to ensure it meets a number of rules before continuing. An example here might be flagging up one rule specifically hiding another and it will fail (or pass if it’s fine)
3. Conversion – The databases have their relevant information taken and converted to separate formats needed by later processes
4. Compilation & generation – Here the policy is translated to the INSPECT language and then passed to the INSPECT compiler to be…compiled!
5. CPTA – CheckPoint Transfer Agent uses SIC to send the relevant policy to the necessary gateways
6. Commit – The gateway loads up its new policy

The processes themselves handle the process as follows:

1. SmartConsole CPMI sends the policy installation command to FWM on the SMS
2. FWM then does its verification and compiling of the policy elements. This is then sent to CPD
3. CPD generates the necessary code  and compiles it before initiating CPTA to forward the policies to the relevant gateways for installation
4. CPD on the gateway receives the compiled policy and verifies it
5. FWD then updates the relevant processes – VPND and FWSSD for example, with the new policy elements CPD then starts the work of replacing the kernel
6. As the new policy is getting ready for replacing, the GW starts to queue all incoming traffic and stops forwarding
7. The Atomic load (What a cool name) then starts where by the kernel is replaced
8. Queued traffic is now forwarded through the new policy

KERNEL TABLES (BITS TO CHECK)

Although we have mentioned the  Kernel a fair bit and identified that certain processes run in User Mode or Kernel Mode, we haven’t touched on a massively practical application of knowing this (other than using them to identify the possible cause of  an issue). Checkpoint units themselves have a lot of tables – you can see this list easily enough using the command

fw tab -s | more

That gives you a summary list similar to:

Fair bit of info, but what we really want to interrogate is the contents of some of the tables. Lets look at the connections table

[Expert@CPGW-01]# fw tab -t connections -f | more
Using cptfmt
Formatting table’s data – this might take a while…

13:06:25 xx.xx.xx.xx > : ———————————–(+); Direction: 0; Source: 172.23.117.111; SPort: 53874; Dest: 192.168.10.202; DPort: 161; Protocol: udp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 172.23.117.111; SPort_1: 53874; Dest_1: 172.20.140.202; DPort_1: 161; Protocol_1: udp; FW_symval: 17; product: VPN-1 & FireWall-1;

13:06:25 xx.xx.xx.xx > : ———————————–(+); Direction: 1; Source: yy.yy.yy.yy; SPort: 80; Dest: 172.19.201.16; DPort: 3555; Protocol: tcp; CPTFMT_sep_1: ->; Direction_1: 0; Source_1: 172.19.201.16; SPort_1: 3555; Dest_1: yy.yy.yy.yy; DPort_1: 80; Protocol_1: tcp; FW_symval: 5; product: VPN-1 & FireWall-1;

These are great. Lets digest what we can see.

The examples shows us:

• Direction: O, so we know it is inbound from an external source initially.
• We can see the source and destination IPs and port numbers
• We can see the protocol type too
• Direction: 1, this is outbound
• Notice the difference between the way the UDP and TCP connections are listed. I don’t know why this is but think it’s to do with the connection-oriented/connectionless style of the protocols and linking to their previous packet.

We can’t see anything relating to the information on it’s interface or sequence number. I actually struggled to find anything solid about how to interpret this table, there just doesn’t seem much out there, even on other blogs or the CP support knowledge base. I have my own assumptions but as I can;t prove them, I won’t pass information around.

The connections table itself achieves some very important goals for firewall security and performance:

• It’s faster to pass traffic based upon an entry in the state table than it is querying the firewall policy as part of the INSPECT module
• Replies are allowed back – this means we don’t need to add specific reply entries in to our rule base
• Stateful items such as TCP sequencing, AAA, NAT etc. can all be handled within the table