Tuesday, December 29, 2020

Checkpoint Updatable Objects vs Domain Objects vs Dynamic Objects


Updatable Objects

An updatable object is a network object that represents an external service, such as Office 365, AWS, GEO locations. For each location, there is a network object you can import to SmartConsole. 

To add the Microsoft Exchange Updatable Object to the Security Gateway

  1. Make sure the Security Management Server and the Security Gateway have access to the Check Point cloud.

  2. Go to SmartConsole > Security Policies > Access Control > Policy.

  3. Create a new rule.

  4. In the Destination column, click the + sign and select Import > Updatable Objects.

    The Updatable Objects window opens.

  5. Select the objects to add. For this use case, select the Exchange Services object.

Domain Objects

A Domain Object allows you to specify a domain name for matching in the rule base. It can be used in Source and Destination columns of Access Policy.

How to Create Domain Object in R8x?

  1. Right-click on Network Objects on the right hand side object panel

  2. Navigate to more -> Domain

  3. Now you have 2 different modes to create Domain Objetcs: FQDN mode and Non-FQDN mode. 

FQDN mode

When FQDN mode is selected, only traffic to the exact domain will be matched on the rule using the FQDN domain object.

Non-FQDN mode

When FQDN mode is unchecked, traffic to the domain and its sub-domains (up to 10 levels) will be matched on the rule using the non-FQDN Domain object.

Dynamic Objects

Easily confused with updatable and domain objects. This construct enables objects to resolve to different ip addresses based on the gateway they are installed on. So a common object name in the rule base installed on multiple gateways, can resolve to different ip ranges.

Next post. cli tools to examine ip addresses in play


Saturday, November 28, 2020

Networked Lab without GNS3

 GNS3 has come a long way since its early Dynamips beginnings.  There is no doubt it now offers a feature set that can make multivendor topology setups a reality with the integration of the GNS3 VM.  With the large feature set though there is still an incumbent learning path. If setup is not quite right you can often find yourself in a worm hole of troubleshooting, and online forums to fix niggles.

I recently setup a basic network topology outside of GNS3 just using the native capabilities in Virtual Box on a windows workstation. This does offer a good alternative if you just want to jump straight to a required lab.

Home lab containing Cisco CSRs, Checkpoint Firewalls in an HA pair, Windows VM and Kali Linux VM below.  These are all run and connected just using Virtual Box

This can be done by making full use of Virtual Box 'Host Network Manager'.  This is accessed from via the main menu File option in Virtual Box and selecting the host network manager feature.

Use the Create option to add multiple Host Only Ethernet Adapters. These will be auto assigned /24 networks, and added to you PC as virtual adapters.

At this point create the required VM machines in VBOX and join them to the required virtual network. Goto machine settings Network TAB. Use the Bridged network adapter to connect to your 'real world' home subnet

Your host machine will be able to reach any Host Only adapter networks, and hence logon to the VMs you have created e.g. via SSH.

A quick fix solution to running a networked VM lab, without spinning up GNS3.

Sunday, January 12, 2020

AWS Security Model

AWS identifies a shared responsibility model for their cloud services.  AWS operates, manages and controls the cloud and is responsible for security of this infrastructure. AWS is also responsible for the security of the managed services e.g. OS database and patching, firewall config etc.  

Customers are responsible for everything they place into the Cloud: what to store, in which service, in what location, access rights to that data etc

As a generalisation AWS is responsible for ‘Security Of the Cloud’ whereas customers are responsible for ‘Security In the Cloud’.

The shared responsibility model changes dependent on what AWS service is used. E.g. for EC2 instances the Customer is responsible for any updates and security patches, however for a managed service such as Amazon RDS, Redshift AWS will handle patching.