Check Point Certified System Administrator (CCSA) Study Notes – R77

CP_ltd_vertical_Pos

I’m now a Check Point Certified System Administrator (CCSA)! I took the R77 exam and passed. I have to say I was a little disappointed with the exam – there were 100 questions in 90 minutes, but I found a lot of the questions were repeated – albeit with a slightly different phrasing.

Below are the notes I made while I was studying. Definitely lab it (download the ISO and set up some VM’s – make use of the free eval mode!). There are a few questions that require familiarity with the UI’s, and knowing where to find certain config options. I’ve been working with Check Point pretty extensively for a couple of years now, and have worked on some pretty big upgrade projects and stuff, but I’m definitely glad I put some hours in studying and labbing – my experience hasn’t exposed me to all of the features and there is no way I would have passed it without putting some time in with a virtual lab.

Below are my notes that I took whilst studying. I haven’t edited them, it’s a straight copy and paste from OneNote, so they may not be formatted correctly or whatever, and contain some notes that might only make sense to me! But here they are anyway, they may be useful to someone.

SMART is acronym, stands for “Security” “Management” “Architecture”……loosely. 🙂

3 parts of architecture:

  • Gateway (firewall – implements policy)
  • Management (Secure management server, Smart Centre, etc. Where policies are defined.)
  • Console (our windows terminal, laptop, desktop, etc. The apps you install for managing it)

Traffic control methods:

  • Packet filtering (layers 3/4 of OSI)
  • Stateful – allowing return connections – uses the Inspect Engine to store connection information in state table.
  • App awareness – uses application inspection to stop tunnelling over other ports – doesn’t check every packet, it can inspect the beginning of a session and then store it in the session table.

Operating systems:

  • IPSO – based on BSD. Optimised and secured version.
  • SecurePlatform, SPLAT. Uses RedHat, an optimised and secure version.
  • GAiA – hybrid of the best of both previous operating systems, with much more support for IPv6.

Installing gateway and management server on different boxes is called Distributed Deployment.

Can both be installed on one box – this is called a Standalone Deployment

They can be installed in routed or bridged mode. In bridged mode, it doesn’t need a different IP on each interface – i.e. it can sit IN a subnet rather than BETWEEN subnets.

SIC – Secure Internal Communication. Initial password (SIC Key) is a one time use – allows the manager and firewall to initially authenticate each other and negotiate keys – manager is a key server.

Smart Console applications can be downloaded by logging in to the web interface of the manager, and selecting Maintenance – Download Smart Console.

First time connection to the manager, you will be presented with a fingerprint. This can be verified by logging in to the web interface and selecting System Management, Certificate Authority. Or, you can log in to the CLI and do a cpconfig, option 7.

The “>” prompt on CLI is the “GAiA” SuperShell mode (used to be CLISH).

When you first initialise SIC is reads the topology information. For spoofing, the “External” interface will automatically be assigned to wherever the default route points.

Common rules:

  • Management – SSH, HTTPS, SNMP, SmartConsole ports, etc, to the gateway and manager.
  • Stealth – Drop all stuff directly to the firewall, should be at the top just after the management rules.
  • Internal Rule – Allows internal to out, not in by default, and questionable – in a true secure environment you would just allow all internal traffic to get out!
  • Cleanup – Deny any any any, last rule in policy. It’s actually the default action, but it allows logging.

Implied Rules are installed by default, and these are part of the policy even though you don’t necessarily see them. Implied rules can be changed by going to “Edit Global Properties”. Logging for implicit rules can also be added here.

SuperShell CLI:

  • fw stat will show you details of the installed policy.
  • fw unloadlocal will uninstall any policies (turns it into a router, all open!)
  • show configuration will give the full config
  • You can add words to the end – show configuration interface
  • show route will show the routing table
  • fw fetch localhost will put the policy back on after an unloadlocal
  • fw fetch <manager IP> allows you to “pull” the policy off of the mgr, rather than the usual push.
  • fw getifs – lists interfaces and IP’s
  • add backup local – generates a local backup and stores it in /var/CPbackup/backups
  • show backup status – shows the status of a backup
  • set backup restore local <tab> – restores a local backup
  • cp_conf sic state – displays sic status
  • pdp monitor client_type portal – shows clients who have authenticated using the portal – shows username vs ip mappings
  • pdp monitor ip <ip address> – lets you search the identity database for an IP to map the user.
  • pdp control revoke_ip <ip address> – removes an entry from the database.
  • dbver – works with the database versions – puts you into a different prompt. Allows you to manage database revisions, similar to how you would in dashboard.
  • fw logswitch – manually flips the logs. Logs stored in $FWDIR/log

Reasons for NAT:

  • Private IP’s
  • Security – inbound connections cannot happen if hosts don’t have a public IP
  • Limited IP’s

Source NAT is performed on egress, AFTER policy has been matched.

Destination NAT is performed on ingress – AFTER policy is matched, but BEFORE routing lookups – you don’t need routes on the fw for the NAT’s.

————————————————————–

NAT Experiment

Some tests to see what the firewall rule needs to be when you do destination NAT.

NAT on object

Add the NAT to the object – creates automatic NAT rules – not manual NAT’s added. Firewall rule just uses object.

No NAT on object, manual NAT only

Firewall rule has to be to the PUBLIC IP. This proves that it checks the rulebase BEFORE it does destination NAT. However, I did not need to add any routes – so the destination NAT MUST happen before routing.

So for destination NAT, the order of operations MUST be:

  1. Policy
  2. Destination NAT
  3. Route

Manually adding the destination NAT can cause problems with ARP though – if you use NAT on an object, a proxy ARP is added automatically. When you manually put the NAT rule in, you also have to add a Proxy ARP using the web interface of the gateway for the public IP to the interface. Also, you must ensure that “Merge manual proxy ARP configuration” is enabled under NAT in global properties in dashboard. The other way to do it is to add a /32 static route on the next hop devices so that it is routed to the main interface rather than ARP’d for, although this is arguably less preferred.

Source NAT happens on outbound side, so always after a policy match.

Where in fw monitor does destination NAT happen?

Automatic NAT rule configured on object.

Client side NAT (default)

[vs_0][fw_0] eth0:i[60]: 192.168.1.222 -> 192.168.1.120 (TCP) len=60 id=433

TCP: 10004 -> 80 .S…. seq=bffbb464 ack=00000000

[vs_0][fw_0] eth0:I[60]: 192.168.1.222 -> 172.16.1.1 (TCP) len=60 id=433

TCP: 10004 -> 80 .S…. seq=bffbb464 ack=00000000

[vs_0][fw_0] eth2:o[60]: 192.168.1.222 -> 172.16.1.1 (TCP) len=60 id=433

TCP: 10004 -> 80 .S…. seq=bffbb464 ack=00000000

[vs_0][fw_0] eth2:O[60]: 192.168.1.222 -> 172.16.1.1 (TCP) len=60 id=433

TCP: 10004 -> 80 .S…. seq=bffbb464 ack=00000000

Destination NAT happened between i and I.

[vs_0][fw_0] eth2:i[60]: 172.16.1.1 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10004 .S..A. seq=e8711f91 ack=bffbb465

[vs_0][fw_0] eth2:I[60]: 172.16.1.1 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10004 .S..A. seq=e8711f91 ack=bffbb465

[vs_0][fw_0] eth0:o[60]: 172.16.1.1 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10004 .S..A. seq=e8711f91 ack=bffbb465

[vs_0][fw_0] eth0:O[60]: 192.168.1.120 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10004 .S..A. seq=e8711f91 ack=bffbb465

The source NAT happened between o and O.

Destination side NAT

Static route added:

HQ-FW1> set static-route 192.168.1.120/32 nexthop gateway address 172.16.1.1 on

This enables to NAT to work again by routing the public IP to the server.

[vs_0][fw_0] eth0:i[60]: 192.168.1.222 -> 192.168.1.120 (TCP) len=60 id=58791

TCP: 10012 -> 80 .S…. seq=8cc5d69d ack=00000000

[vs_0][fw_0] eth0:I[60]: 192.168.1.222 -> 192.168.1.120 (TCP) len=60 id=58791

TCP: 10012 -> 80 .S…. seq=8cc5d69d ack=00000000

[vs_0][fw_0] eth2:o[60]: 192.168.1.222 -> 192.168.1.120 (TCP) len=60 id=58791

TCP: 10012 -> 80 .S…. seq=8cc5d69d ack=00000000

[vs_0][fw_0] eth2:O[60]: 192.168.1.222 -> 172.16.1.1 (TCP) len=60 id=58791

TCP: 10012 -> 80 .S…. seq=8cc5d69d ack=00000000

Destination NAT now happens between o and O

[vs_0][fw_0] eth2:i[60]: 172.16.1.1 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10012 .S..A. seq=df632078 ack=8cc5d69e

[vs_0][fw_0] eth2:I[60]: 192.168.1.120 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10012 .S..A. seq=df632078 ack=8cc5d69e

[vs_0][fw_0] eth0:o[60]: 192.168.1.120 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10012 .S..A. seq=df632078 ack=8cc5d69e

[vs_0][fw_0] eth0:O[60]: 192.168.1.120 -> 192.168.1.222 (TCP) len=60 id=0

TCP: 80 -> 10012 .S..A. seq=df632078 ack=8cc5d69e

Also changed the place for the source NAT – now happens between i and I. If I had to guess, I would assume that this is done earlier so that the firewall state tables all still match and the stateful reply is allowed – presumably if the source NAT for the reply packet still happened on the outbound side then the state tables would get confused – so the source NAT for the reply traffic always happens on the opposite interface to the destination NAT for the inbound traffic.

——————————————————-

SmartDashboard organizes the automatic NAT rules in this order:

  1. Static NAT rules for Firewall, or node (computer or server) objects
  2. Hide NAT rules for Firewall, or node objects
  3. Static NAT rules for network or address range objects
  4. Hide NAT rules for network or address range objects

Policy Packages

You can use one policy for multiple firewalls – adding the “Install On” to each rule to install them on the relevant gateway.

Or you can use a package per gateway, which can be cleaner in a large deployment.

Or you can use a package for a group of devices. Whatever suits!

Packages do NOT include objects…they are shared across policy packages.

Policy packages can include the following policy types:

  • Firewall, NAT and App & URL Filtering
  • Threat Prevention
  • QoS
  • Desktop Security

To change the targets shown on the install policy dialog, hit select targets and only add the ones you want.

A database version would include all policies and objects.

Tracker

3 modes:

  • Log (Network & Endpoint)
  • Active – CAUTION: CPU overhead, can crash a gw
  • Audit (Management)

Rolling over logs in tracker – File – Switch Active File. This will create a new log file immediately.

Log roll over settings are configured inside the manager object.

Some log settings are in global properties.

Monitor

To set the alerting thresholds, initially you have to start the system alert daemon – Launch – Tools – Start System Alert Daemon.

The “Monitoring” blade has be enabled on the gateway – this is done on the firewall object in dashboard.

Also has to be a licensed blade.

Traffic can be blocked temporarily by implementing a suspicious activity rule.

You can do this by going to Tools – Suspicious activity rules, or by right clicking on a graph and selecting “block service”

LDAP

First, global properties, select Use User Directory for Security Gateways.

Then set up an account unit for LDAP – Manage / Servers and OPSEC Applications

Machine generated alternative text:
LDAP Server Properties 
General Encryption 
Username: 
Login DN: 
Password: 
Confirm password: 
Default priority: 
ccsgrDc 
Administrator 
CN4dministrator, CN:Llsers, DC-ccsa, 
(I is highest) 
Check Point Gateways are allowed to: 
V Read data from this server 
V Write data to this server

Screen clipping taken: 18/01/2016 16:39

Next, Create LDAP Group

Identity Awareness

4 Options:

  • AD query – check the security event logs on the AD server which user logged in with which IP
  • Captive Portal – Redirect users to a login page before they can use the rule- only works on HTTP, not HTTPS
  • Agents – Endpoint or Terminal Services
  • VPN

Steps:

  1. Enable the feature – add the blade to the firewall object.
    1. Ad query – checks security event logs
    2. Browser based – captive portal or transparent kerberos
    3. Terminal servers
  2. Create an access role
  3. Use the access role in a rule

As the captive portal only works on HTTP, you may need to allow DNS above it – because otherwise they will never hit the captive portal.

Legacy user authentication:

  • User Authentication (Telnet, rlogin, FTP, HTTP, HTTPS) – redirects the client to a login page before access is allowed.
  • Session Authentication (Agent based, triggered using HTTP:900, Telnet:259)
  • Client Authentication – based on IP – triggered using HTTP:900, Telnet: 259

HTTPS Inspection

The firewall cert has to be trusted, or the browser will complain. Basically means the firewall terminates the SSL and then plays man in the middle, generating its own SSL connection outbound and relaying between the two.

HTTPS Inspection is enabled under the firewall object.

  1. Generate or import the cert
  2. Export the cert and push it out to all machines in the organisation (i.e. via group policy)
  3. Enable it.

To view the HTTPS inspection, go to App and URL filtering, advanced, HTTPS Inspection, Policy.

This is where you can configure which ports to apply this to, and which categories of sites – i.e. you can exclude banking sites etc.

The Checkpoint site says it is not a blade and does not need licensing, but it didn’t work in my tests until I enabled the Application Control and URL filtering blades.

It doesn’t support EV certs – the user will always see a regular cert.

Basically the CP acts as a root CA (and this is the root CA that must be installed in the browser), and “issues” a cert for each domain you visit.

Application Control

Protects against malware, bandwidth abuse, non-approved sites.

Actions:

  • Allow
  • Inform – takes user to a page where they have to click ok to proceed.
  • Ask – Similar to inform, but takes user input…you can ask a user to give a reason or agree to AUP.
  • Block – with or without a message

Messages can all be edited. You can also set a timer for inform / ask – how often will it re-ask the user.

Bandwidth limits can be set for upload, download or both.

VPN Site to Site Tunnels

Symmetrical encryption algorithms:

  • DES
  • 3DES
  • AES

Data Integrity / Authentication:

  • MD5
  • SHA

IKE Phase 1:

  1. Negotiation
  2. Diffie Hellman
  3. Authentication

IKE Phase 2:

  1. Negotiate
  2. Build IPSEC tunnel

IKE Main Mode takes 6 packets to establish.

Aggressive mode takes 3 packets but is considered less secure.

VPN Community refers to everything within the VPN. Can be full mesh or star (star is hub/spoke).

Each firewall is called a VPN member.

VPN domain is what networks are included. VPN domain is either based on topology by default, are edited on the topology page of the gateway object properties.

Need to disable NAT for VPN domains.

Tunnel management:

  1. One VPN tunnel per pair of hosts
  2. One VPN tunnel per pair of subnets
  3. One VPN tunnel per pair of gateways

  1. Enable the IPSEC software blade
  2. Define the gateway’s encryption domain on the properties of the firewall object.
  3. Select the IPSEC VPN tab and create a new star topology
  4. Identify the centre gateways (hubs)
  5. Identify the satellite gateways (spokes)
  6. Define encryption methods
  7. On firewall, add “only connection encrypted in specific VPN communities” to policy rule to identify traffic. (not mandatory – if a fw rule covers it it will be encrypted without explicitly matching the VPN on the fw)

Backup Types

  • DB Version – Fairly small, includes policy and objects. Usually done using database revision control in dashboard, but can be done using dbver on CLI. Cannot be done via HTTPS.
  • Backup – Medium sized, includes GAiA config and CP database. Must be done at CLI, or via HTTPS to the gateway (or manager). CLI commands are show/add/set backup (add backup local, set backup restore local)
  • Image / Snapshot – Massive. Includes the entire OS partition (so therefore includes the DB). Must be done at CLI or via HTTPS to the gateway (or manager). CLI commands are show/add/set snapshot.

Smart Update

For remotely updated packages for the OS, patches and hotfixes.

License management – two licensing options:

  • Central – licenses are all linked to IP of manager
  • Local – Licenses are linked to IP of gateway – less flexible if you change gateways.

A licensed can be:

  • Unattached – installed on the manager but not assigned to a gateway
  • Assigned – assigned to a gateway but not installed in use.
  • Attached – Installed and active license.

Content can be obtained from the download centre, user centre, DVD.

Licenses are stored in $FWDIR/conf

To distribute a package (i.e. the jumbo hotfix):

  1. Launch Menu / Packages / Add / From File (or d/l centre or whatever)
  2. Wait until it adds – takes a few minutes
  3. Right click on the gw and Distribute Package

To license:

  1. Launch Menu / Licenses / Add
  2. Right click on the gw and attach it

Posted in Checkpoint and tagged .

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.