In this lab we implement a basic security architecture to demonstrate the operation of a firewall cluster to protect our network. Our “security domain” is segmented into four zones:
- management: only for management, operation and control purposes of equipments and services.
- intranet: our secured ressource
- internet: the untrusted network
- and dmz; the part of our network (trusted) that faces internet
Our security topology is compound by two security gateways (SG) that are managed by a single security manager server (SM). The SG gateways (firewall) are in the same cluster such as to appear as a single entity to the rest of the world.
A management PC is configured with Check Point utilities such as: SmartDashboard, SmartUpdate, SmartView Tracker, and PuTTy for remote access to the gateways and manager using SSH. This PC belongs to the management network that connect only management interfaces. This network is physically separeted from the production trafic still that some ressources (memory, CPU, disk) may be sharable at single physical nodes…
Three routers emulate the operation of intranet, internet and dmz, are directly connected to both gateways: R3 connects intranet ressources, R2 simulates internet access and R1 our internet exposed servers…
The following topology summarizes this implementation:
To implement this architecture we first emulate gateways and manager using Oracle VirtualBox (installed on Windows). In figure we show the 3 emulated VM supporting: SM, SG1 and 2. We used this .iso image to build our VMs: Check_Point_R77.20_T124_Install.Gaia.iso.
Next, on a windows 10 64-bit operating system we create 4 VirtualBox Host-Only Ethernet Adapters (loopbacks) that represent each a security zone such as in the figure:
These adapters correspond to the switches: Mgmt, Intranet, Internet and Dmz, in our topology. We configure them with the corresponding .254 ip addresses.
In VirtualBox we map each loopback (adapter) to the corresponding firewall physical interface: MGMT adapter to eth0, INTRANET to eth1, INTERNET to eth2 and DMZ to eth3.
Security gateways and manager need to be configured with the correct ip addresses in the management network from the console (CLI or command line) at initial install or using this command:
At this stage we could check that all firewall are pingable from the corresponding consoles. On the management PC we install the Check Point management suite: Check_Point_SmartConsole_and_SmartDomain_Manager_R77.20_T124_Windows.exe. We gain access to SM using SmartDashboard and add our security gateways. In this procedure SIC (that stands for Secure Internal Communication) is used to establish trust between gateways and security manager.
At the gateway level, SIC is initiated in expert mode by cpconfig command. At the security manager level, SIC initialization is done using SmartDashboard as show in this figure:
SIC operation is handled by cpd process and it is based on PKI and SSL/TLS. The gateways listen on TCP ports 18211. Traffic from the gateways to SM on TCP port 18209 should be also permitted. Another requirement for SIC to succeed is time synchronization within few minutes.
Also included in SIC procedure:
- SM Internal Certificate Authority (ICA) generate both SM and firewall certificates (SMS-cert and FW-cert).
- The initial established secure communication tunnel, using the One-Time SIC Activation Key, helps provide the gateways with this information.
We use SmartUpdate to check attached licences:
Evaluation licences could be easily retrieved from Check Point UserCenter in case. They are valid for a month.
Now that we’ve set up our VM (SM, SG1, SG2) and get them synchronized (Host interface using Windows loopbacks) let’s move to our network configuration using GNS3 (network emulator).
Moving to GN3 world…
In GNS3, we add 3 routers: R1, R2, and R3 corresponding to different security zones that are represented by cloud objects. Each cloud object maps to its corresponding Loopback (previously created) and through those loopback to virtual box objects thus VMs.
When adding links from routers to cloud objects we may encounter this error in GNS3 console.
As a workaround we apply this command in cmd: sc config npf start= auto, and restart the PC.
Back to our gateways
From SmartDashboard (connected to our SM) we’re ready to get gateway topology information,
and push our first policy (with traceable rules) that allows our management traffic and a test traffic (pings) from dmz router (R1) to intranet (R3) using their directly attached interfaces to zones.
To achieve this we configure our routers with default routes to firewalls.
We could confirm on SmartView Tracker that our traffic is getting through the firewalls:
In this post, using only a windows PC we’ve created 3 VM to emulate our firewall (gateways) and their manager (SM). 3 loopback interfaces was created on windows to simulate a switch operation to connect VM interfaces to cloud objects in GNS3. Each cloud in GNS3 maps to the corresponding VM interface through the windows interface (internal switch). GNS3 clouds connects the corresponding emulated routers (networks). These routers are logically separated and any trafic from those router should pass by the cloud objet reach the loopback windows interface before reaching the VM interface at the firewall where the policy is applied…
