CCSA R80: Intro to Check Point Architecture (Part 1)

This post - the first part of two, in order to prevent things becoming unnecessarily long-winded - covers the first objective of the Check Point CCSA R80 exam, Introduction to Check Point Architecture. As well as offering a basic explanation of what a firewall is and does, it will also serve as a primer to Check Point’s technologies and components; part two will focus on the practical elements.

What is a Firewall? What Does it Do?

Simply put, a firewall is a network appliance (hardware-based for the most part, but also software-based¹ or indeed a combination of both) that acts as a barrier between a trusted and untrusted network (i.e. a company’s internal network/s and the Internet), monitoring and deciding whether to allow or deny incoming/outgoing traffic. While far from the only component of an organisation’s security posture, they remain an important one.

Modern, next-generation firewalls (also called NGFWs) come with a wide variety of features, ranging from NAT and basic/advanced routing to more sophisticated capabilities such as anti-virus and malware prevention. However, for the purposes of this objective, the focus here will only be on three fundamental methods of traffic control: packet filtering, stateful inspection and application awareness. (A basic familiarity with the OSI model is assumed; here’s a good introduction if that’s not the case.)

Packet Filtering

The simplest form of traffic control, packet filtering takes place at the Network and Transport layers of the OSI model. Traffic is inspected on a per-packet basis and - as previously mentioned - gets allowed through or dropped by the firewall based on user-defined criteria (also called a ruleset), usually by checking the source and destination IP addresses along with port numbers and protocols. This mechanism is illustrated below:

However, packet filtering at its most basic has an important downside: it treats each packet in a given traffic flow as a standalone entity, rather than taking the overall picture into account. Why is this a disadvantage?

Consider the diagram above. When the client PC sends a request out to the Web server, it is assigned an ephemeral port number (that is, a random port within the range 1024-65535 that is assigned by the operating system); in this case, 2001. Since the firewall has been configured to allow traffic from this PC to the server on port 80, this goes through without any issues. However, because there isn’t a rule allowing inbound access on port 2001, the return traffic from the server will be dropped. (Suffice it to say that opening up all ports to the outside world to mitigate this shortcoming is not a good idea.)

Stateful Inspection

Unlike switches and routers - which use the more rudimentary form of packet filtering described above - firewalls are able to maintain the context of all incoming and outgoing connections using a state table: this is what’s known as stateful inspection. But what exactly does that mean? Let’s use the previous example:

When you connect to a website via your Web browser of choice, your PC (or laptop, or phone…) starts the connection using the TCP three-way handshake. The firewall will examine the TCP control bits in the packet it receives from the Web server, determine that it is a response to the initial request from the internal PC, stores this information in its state table, and automatically permits the inbound traffic - along with all other traffic in either direction between the two for as long as that connection remains active.

There is a catch, though. As you might imagine, keeping track of the state of all current connections can have an impact on the firewall’s resources, resulting in a performance hit and longer inspection times.

Application Awareness

As attacks have increasingly shifted over the years towards exploiting applications themselves rather than only targeting the lower reaches of the OSI model, so too have firewall technologies evolved. Most, if not all, of today’s firewalls are capable of deep packet inspection of one form or another; this means that they are able to go beyond the packet header and dive into the content itself, examining everything up to the Application layer.

The biggest advantage of application filtering is that the firewall is capable of intercepting more attacks and threats that would otherwise go undetected using packet filtering alone. For example, rather than resorting to blocking the individual IP addresses that belong to a particular website, the firewall is able to instead block the URL itself. The ability to inspect payloads also means that packets containing known viruses or malware can be blocked.

Check Point Architecture

Check Point’s security management architecture consists of three key components which, taken together, all work as a unified whole to provide full visibility into a Check Point environment, as well as provide ease of administration. These are as follows:

• Security Gateway. Deployed at the access points of the network, this is the appliance which controls and protects traffic that passes through it. Whenever you see this term, just think “firewall”.
• Security Management Server. The Security Management Server, or just SMS for short, is the proverbial “key to the kingdom”. Aside from being the centralised point of management for a company’s security policies, this is also where log files and object definitions for all gateways are kept. It is possible to have the SMS and the gateway on the same hardware appliance (more on this soon).
• SmartConsole. A Windows-only console application via which an administrator connects to the SMS. This is the means by which - among other tasks - security policies are managed, gateways/SMSs are added and updated, monitoring is performed, and licences are provisioned. SmartConsole also includes other components which act as standalone tools by themselves:
  • SmartDashboard - provides access to legacy applications, such as Data Loss Prevention, Anti-Spam & Mail, Mobile Access and HTTPS Inspection;
  • SmartEvent - aggregates logs from all Check Point appliances (as well as third-party devices) and provides insight into various security events including potential attacks, allowing for real-time analysis and data customisation;
  • SmartUpdate - a single pane of glass with which to manage licenses, updates and software packages;
  • SmartView Monitor - gives a centralised view of network and appliance peformance, including gateway statuses, VPN tunnels, user activity, traffic statistics (such as top connections, sources/destinations and services) and system counters.

The general administration workflow can be summarised in four steps, illustrated in the diagram below:

1. The administrator connects to the SMS via SmartConsole.
2. A change is made to the security policy - for example, a rule is created or amended - or a new one is created altogether. Whatever the change, this is published for auditing purposes and then committed.
3. As the policy is being installed, the SMS will perform checks to ensure that no logical errors (i.e. a rule allowing a broad level of access coming before one that is stricter in its scope) or other issues are present. Once this is complete, the policy is sent to the target gateway.
4. The gateway receives the updated version of the policy and applies it to any subsequent traffic that traverses it.

Deployment Options

Like any other network security vendor, Check Point have a range of platform options that are able to be deployed in different ways depending on your specific use case. If you are a Check Point partner, you can use the Appliance Sizing Tool (AST) to receive recommendations on which ones are best for your particular environment and throughput requirements.

Platforms

There are three main platform options for Check Point appliances, hardware and virtualised alike:

• Security Appliances. Supplied directly by Check Point, these come in various form factors - from desktop-sized and rack-mountable to highly redundant chassis-based systems - and with different features that cater for organisations of all sizes and environments, be they small businesses and offices, global enterprises, data centres or ISPs/telcos. Some provide the ability to create multiple virtualised gateways.
• Open Server. If you don’t like the idea of hardware lock-in, then bring your own box. Check Point allows you to deploy their software on non-proprietary devices, allowing for flexibility when it comes to increasing CPU, memory and disk capacity as well as greater scalability. The catch, however, is that whatever you choose must be listed on the hardware compatibility list; you must also ensure that it meet the necessary specifications for your use case, and bear in mind that the AST won’t help with analysing your performance requirements if you choose this option.
• Virtual Machine (VM). Prefer to use your appliance as a VM? You can do this too - Check Point platforms can be deployed on VMware ESXi if you want to keep things in-house. Alternatively, if you make use of the public cloud, popular providers such as Amazon Web Services, Microsoft Azure and Google Cloud Platform are also supported.

Scenarios

Check Point appliances have different deployment scenarios. For the purposes of the exam, there are three of these that you must be aware of:

1. Standalone. As the name suggests, in a Standalone deployment, both the gateway and SMS are installed on the same appliance. While this might be an economical and convenient method for smaller environments, this can come at the expense of performance and scalability. Generally speaking, it is not a recommended practice.
2. Distributed. In a Distributed deployment, the SMS and gateways exist as individual entities and are installed on separate appliances. This is the most common and flexible option; it is also a requirement for specific features.
3. Bridged. In a Bridged deployment, the gateway is installed into a network without having to make any changes to the existing routing. (This could be out of necessity due to complexity, or just reluctance on the part of the network administrator.)

Secure Internal Communication (SIC)

Secure Internal Communication - or SIC - is the means by which the different components within a Check Point environment are able to authenticate and establish trusted connections with one another. This is a requirement for the installation of policies, as well as the transfer of logs between the SMS and gateways. It uses one of three different authentication methods:

• Certificates. These are generated by the Internal Certificate Authority (ICA), an on-board service on the SMS that is created upon its installation. The ICA can issue three different types of certificate, each with its own specific purpose:
  • SIC Certificates - for authenticating between gateways and SMSs;
  • VPN Certificates - for authenticating peers within the same VPN community in order to create site-to-site VPN tunnels and remote access VPNs;
  • User Certificates - for authenticating remote user access to appliances.
• Standards-based SSL. This is used during the initial establishment of trust and creation of secure channels between appliances.
• Encryption. Gateways running software version R71 or above use the AES128 algorithm by default; legacy deployments (i.e. anything below R71) use 3DES, which is nowadays antiquated.

The initial trust between a gateway and SMS is established via SSL with the use of a one-time password that is specified by the administrator during the installation of both. Beyond this point, the one-time password is deleted and a certificate is downloaded from the SMS to the gateway, which is now able to communicate with other appliances that hold certificates issued by the same ICA. (Be mindful of the fact that if the hostname of the SMS is changed, the certificate will renew itself and trust will need to be re-established.)

SIC Statuses

Once the ICA has provided the certificate to the gateway, there are one of three SIC status codes that are displayed to determine whether or not the SMS and gateway are able to securely communicate:

• Communicating. SIC is established; the SMS and gateway are communicating as expected.
• Not Communicating. The SMS and gateway are able to reach one another, but SIC has not been established. (More specific information is displayed in this case.)
• Unknown. A connection between the SMS and gateway does not exist.

Conclusion

This concludes Part 1 of the Introduction to Check Point Architecture objective. In this post, a general overview of firewall functionality and the Check Point landscape was provided. Part 2 will introduce Gaia - Check Point’s own RHEL-based operating system that underpins all appliances and open servers - and the browser-based WebUI that provides it with a graphical frontend for managing gateways and SMSs, and demonstrate how these are used for appliance configuration (as well as show SIC in action).

Hopefully this has been useful for you. All feedback and suggestions for improvement are welcomed.

---

1. Functionally similar to their hardware-based counterparts, software-based firewalls include the likes of Windows Defender and iptables (on Linux) among others. ↩︎