ccse-r80 10-instructor-slides

Prévia do material em texto

Instructor 
R80.10 Edition
Security 
Engineering
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
©2017 Check Point Software Technologies Ltd. 
Preface
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
<número>
Certification Renewals
[Restricted] ONLY for designated groups and individuals
No Certification Extension Options
Certification Extension Options:
Security Master
CCSE Update
1
©2017 Check Point Software Technologies Ltd. 
 
 
O R80.10 introduz uma grande quantidade de novos conceitos e recursos para o administrador de segurança. Portanto, nenhuma opção de extensão está disponível para essa certificação.
Para o estudante R80.10 CCSE, a certificação pode ser estendida participando de um curso avançado ministrado por instrutor, como o CCSM ou CCMSE, e passando no exame associado, para enriquecer seu conhecimento básico com experiência prática e prática integrando e solucionando problemas. produtos.
Os alunos sempre têm a opção de participar dos novos exames completos do Administrador de Segurança ou do Especialista em Segurança da VUE a cada lançamento - e isso prolongará sua certificação por dois anos completos.
O exame de atualização do 156-915-80 para a certificação CCSE R80.10 estará disponível no segundo trimestre.
<número>
Key Course Elements
Advanced explanation of Check Point Technology
Advanced upgrading
Key techniques for building, deploying, and enhancing network performance
Features to mitigate security risks
Skills to effectively design, maintain and protect enterprise networks
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Bem-vindo ao curso de Engenharia de Segurança Cibernética da Check Point. Este curso fornece uma explicação avançada e detalhada da tecnologia da Check Point. Inclui atualização avançada, técnicas-chave para a criação, implantação e aprimoramento do desempenho da rede e recursos de gerenciamento e solução de problemas para reduzir os riscos de segurança. O curso destina-se a fornecer a você uma compreensão das habilidades necessárias para projetar, manter e proteger sua rede corporativa com eficiência.
<número>
Course Chapters
System Management
Automation and Orchestration
Redundancy
Acceleration
SmartEvent
Remote and Mobile Access
Threat Prevention
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Course Chapters as outlined in the Student Manual.
<número>
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Laboratórios para este curso foram desenvolvidos usando o VMware Workstation. Seu instrutor terá informações sobre as configurações específicas e os requisitos de configuração de cada máquina virtual. A maioria dos exercícios de laboratório exigirá que você manipule máquinas na rede virtual. Revise a topologia inicial do laboratório ilustrada abaixo. Observe a localização de cada servidor em relação aos Gateways de Segurança e como eles são roteados. Certifique-se de entender o propósito de cada máquina e as credenciais e aplicativos usados durante o curso.
<número>
System Management
01
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Understand system management procedures, including how to perform system upgrades and apply hotfixes.
Identify advanced CLI commands.
Understand the Check Point Firewall infrastructure and other advanced Firewall processes and procedures.
System Management
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Espera-se que os especialistas em cibersegurança adquiram e apliquem um conhecimento profundo dos sistemas usados para gerenciar com segurança a infraestrutura de rede da organização. Este curso começa com um mergulho profundo no sistema operacional Check Point Gaia, com como usar comandos CLI essenciais, executar atualizações e aplicar hotfixes. Também veremos mais de perto a infraestrutura do Check Point Firewall, os módulos de cadeia, as tabelas de kernel, o fluxo de pacotes e muitos processos e procedimentos mais avançados do Firewall.
<número>
Key values:
Combines the best features of IPSO and SecurePlatform.
Increases operational efficiency with a wide range of features.
Provides a secure platform for the most demanding environments.
Advanced Gaia
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
O Check Point Gaia é o sistema operacional unificado, revolucionário e seguro para todos os appliances Check Point, servidores abertos e gateways virtualizados. A tecnologia de ponta combina os melhores recursos da IPSO e do sistema operacional seguro original da Check Point, SecurePlatform, em um sistema operacional único e harmonioso para fornecer maior eficiência operacional e desempenho robusto.
The Makings of Gaia
Gaia foi derivado de IPSO e SecurePlatform. O sistema operacional da IPSO foi desenvolvido pela Ipsilon Networks, uma empresa de redes de computadores especializada em comutação de IP durante os anos 90. A Nokia comprou a Ipsilon Networks em 1997 e incorporou a IPSO em seus dispositivos de rede seguros. A Check Point adquiriu a unidade de negócios de segurança da Nokia em abril de 2009.
Como um sistema operacional simplificado, o IPSO forneceu funcionalidade suficiente para executar o Check Point Firewalls, junto com a incorporação de alguns comandos Unix padrão, como top, ps e df. Ele também forneceu uma ótima visibilidade das estatísticas do kernel, como contadores de rede, interrupções e muito mais.
O sistema operacional SecurePlatform da Check Point é baseado em um kernel da Red Hat Software. O sistema operacional otimizado e otimizado da SecurePlatform eliminou componentes de pacotes de software que eram desnecessários para um dispositivo de segurança de rede e componentes modificados ou removidos que poderiam apresentar riscos de segurança. Seu shell de comando fácil de usar forneceu um conjunto de comandos necessários para a configuração, administração e diagnósticos do sistema, incluindo configurações de rede, utilitários de backup e restauração, atualização e visualização de log do sistema. O gerenciamento de rotina e a manutenção do SecurePlatform foram realizados por meio de um shell restrito chamado modo Standard. O modo Standard melhorou a segurança do SecurePlatform, restringindo o acesso a utilitários que, se usados ​​de maneira inadequada, danificariam a estabilidade do sistema. O SecurePlatform também consistia em uma interface gráfica de usuário da Web (WebUI), que permitia aos usuários definir facilmente as configurações e executar instalações pela primeira vez.
O SecurePlatform permitiu que todos os recursos do sistema fossem dedicados ao sistema operacional e aos produtos Check Point instalados. Com o SecurePlatform, os recursos não eram mais consumidos por software, como GUIs, aplicativos de escritório e sistemas de arquivos de rede.
Gaia Features and Benefits
O Gaia suporta o conjunto completo de tecnologias da Check Point, oferecendo maior capacidade de conexão e toda a segurança da Check Point.
  Check Point Gaia oferece estes valores chave:
Combine os melhores recursos do IPSO e SecurePlatform.
Aumente a eficiência operacional com uma ampla gama de recursos.
Fornecer uma plataforma segura para os ambientes mais exigentes.
O Gaia simplifica e fortalece a gestão com a segregação de funções, permitindo o acesso administrativo baseado em funções. Além disso, o Gaia aumenta consideravelmente a eficiência operacional com um agente de atualização de software avançado e intuitivo, comumente chamado de CPUSE (Check Point Update Service Engine). O gerenciamento do Gaia é simplificado com a WebUI intuitiva e rica em recursos, e opções de busca instantânea para todos os comandos e propriedades. Os mesmos poderosos comandos da CLI da IPSOe da SecurePlatform foram perfeitamente integrados ao Gaia, juntamente com novos comandos e recursos.
<número>
 [Internal Use] for Check Point employees​
Web-based User Interface with search navigation
Full Software Blade support
High connection capacity
Role-based administrative access
Intelligent software updates
Native IPv4 and IPv6 support
Clustering protocol support
 
Key Features of Gaia
1
©2017 Check Point Software Technologies Ltd. 
Key features of Gaia include	:
Web-based User Interface with search navigation — Essa interface integra todas as funções de gerenciamento do sistema operacional Gaia em um painel acessível pelos navegadores da Web mais populares, como o Internet Explorer, Chrome, Firefox, Opera e Safari. A ferramenta de navegação de pesquisa integrada fornece resultados instantâneos e, para os usuários com CLI, uma janela pop-up do Shell Emulator está a apenas um clique de distância.
Full Software Blade support — A Gaia fornece suporte para soluções abrangentes de Security Gateway e Security Management Software Blade implementadas em appliances Check Point e servidores abertos.
High connection capacity — Utilizando a eficiência de um sistema operacional de 64 bits, o Gaia é capaz de aumentar a capacidade de conexão dos dispositivos existentes da Check Point.
Role-based administrative access — A segregação de tarefas é parte de uma boa Política de Segurança, pois melhora a eficiência operacional e a auditoria de eventos administrativos. O acesso administrativo baseado em função oferece aos clientes do Gaia a capacidade e a granularidade de personalizar suas políticas de gerenciamento de segurança para atender às necessidades de negócios. A autenticação e autorização do usuário são baseadas nos protocolos RADIUS e TACACS + padrão do setor. Níveis específicos de acesso podem ser concedidos com base no papel e responsabilidade de cada indivíduo.
Intelligent software updates — Com o Gaia, os tempos de atualização de software são reduzidos e o teste pós-atualização é executado automaticamente. Novos lançamentos e patches podem ser programados para download automático e instalados fora do horário de pico para um impacto comercial mínimo. Os e-mails de notificação são enviados sobre atualizações recomendadas e status de atualização.
Native IPv4 and IPv6 support — O Check Point Gaia permite fácil interoperabilidade com os dois protocolos de rede.
Clustering protocol support — O Gaia suporta totalmente o ClusterXL, o protocolo de redundância de rede proprietário da Check Point e o VRRP padrão em todos os appliances Check Point, servidores abertos e ambientes virtualizados.
Manageable dynamic routing suite — Vários protocolos de roteamento dinâmico e multicast são suportados pelo Gaia, fornecendo conectividade de rede flexível e ininterrupta. Tudo pode ser gerenciado pelo portal Gaia ou pelo CLI.
<número>
 [Internal Use] for Check Point employees​
Install the most recent software release to stay up-to-date with:
 the latest functional improvements and stability fixes.
security enhancements and protections against new and evolving attacks.
Before upgrading appliances or servers:
verify the interoperability and upgrade path of your existing environment.
use the appropriate upgrade tools.
To upgrade from:
R77.XX to R80.10, perform an advanced upgrade with database migration.
R80 to R80.10, use CPUSE.
Upgrades
1
©2017 Check Point Software Technologies Ltd. 
Como engenheiro de segurança cibernética, é importante avaliar a integridade geral, a conformidade e o desempenho de sua rede. Isso geralmente envolve a tarefa de decidir se instalará um novo hardware para atender às necessidades de negócios ou se fará upgrade para versões de software mais recentes para garantir a eficiência do ambiente existente. A Check Point recomenda a instalação da versão mais recente do software para manter-se atualizado com os últimos aprimoramentos funcionais, correções de estabilidade, aprimoramentos de segurança e proteções contra ataques novos e em evolução.
Os upgrades fornecem melhorias adicionais em relação a uma versão anterior e eliminam as complexidades de recriar configurações de produtos, políticas de segurança e objetos. Antes de atualizar dispositivos ou servidores abertos, verifique a interoperabilidade e o caminho de atualização do seu ambiente existente e faça uso das ferramentas de atualização apropriadas do Check Point.
Para fazer upgrade do R77.XX para o R80.10, uma atualização avançada com o processo de migração do banco de dados deve ser executada. Atualizações de R80 a R80.10 são realizadas através do agente de atualização de software, CPUSE.
Nota: Upgrades para R80 e superior não são suportados pelo IPSO e pelo SecurePlatform. Para mais informações, consulte o Mapa de atualização da Check Point.
<número>
 [Internal Use] for Check Point employees​
Upgrade Tools
Back up Check Point configurations, independent of hardware, operating system, and security management platform version.
 A different version of tools is available for each platform.
	Package File	Description
	migrate.conf	Holds configuration settings for Advanced Upgrade with Database Migration.
	migrate	Runs Advance Upgrade with migration.
	pre_upgrade_verifier	Analyzes compatibility of the currently installed configuration with the upgrade version. It gives a report on the actions to take before and after the upgrade.
1
©2017 Check Point Software Technologies Ltd. 
Upgrade Tools
As ferramentas de atualização fazem backup das configurações do Check Point, independentemente do hardware, do sistema operacional e da versão da plataforma de gerenciamento de segurança da Check Point. Use as ferramentas de atualização para fazer backup das definições de configuração do Check Point nas partições de disco dos appliances Check Point e abrir os servidores. Requisitos de espaço em disco para atualizações variam de acordo com a versão de atualização. Antes de iniciar um upgrade, consulte as notas sobre o release da versão da plataforma desejada para verificar os requisitos de espaço para cada partição de disco, como as partições / var / log / e root.
Existe um pacote diferente de ferramentas de atualização para cada plataforma. Faça o download da versão mais recente das ferramentas de atualização no site de suporte da Check Point. Antes da atualização, um contrato de serviço válido que inclua atualizações de software e versões principais deve ser registrado na conta da Check Point na Central de Usuários da sua organização. O pacote de ferramentas de atualização consiste em vários arquivos, incluindo os arquivos observados na tabela abaixo.
Package File	Description
migrate.conf		Mantém as configurações para atualização avançada com migração de banco de dados. 
migrate		Executa a atualização avançada com a migração.
pre_upgrade_verifier	Analisa a compatibilidade da configuração atualmente instalada com a versão de atualização. Ele fornece um relatório sobre as ações a serem executadas antes e depois da atualização.
migrate export	Faz o backup de todas as configurações do Check Point, sem informações do sistema operacional.
migrate import	Restaura a configuração de backup.
O comando migrate exporta o banco de dados do Security Management Server de origem para um arquivo ou importa o banco de dados para o Security Management Server de destino.
<número>
 [Internal Use] for Check Point employees​
The current environment must meet these requirements for database migration:
Available disk space of at least five times the size of the exported database on the target machine.
Size of the /var/log folder of the target machine must be at least 25% of the size of the /var/log directory on the source machine.
Source and target servers must be connected to a network and the connected network interface must have an IP address.
If the source environments uses only IPv4 or only IPv6, the target must use the same IP address configuration. For example, you cannot migrate to an IPv6 configuration if the source environment uses only IPv4.Advanced Upgrade with Database Migration
1
©2017 Check Point Software Technologies Ltd. 
Advanced Upgrade with Database Migration
Como em todos os procedimentos de atualização, é uma boa prática atualizar o Security Management Server ou o Multi-Domain Server antes de atualizar os Gateways de Segurança. Para atualizar de uma versão de software anterior, como a R77.30, para a plataforma de gerenciamento de segurança R80.10 da Check Point, use o método Atualização avançada com migração de banco de dados para migrar o banco de dados e instalar o software. Com esse método de upgrade, o ambiente atual deve atender a esses requisitos para migração do banco de dados:
Espaço disponível em disco de pelo menos cinco vezes o tamanho do banco de dados exportado na máquina de destino.
O tamanho da pasta / var / log da máquina de destino deve ter pelo menos 25% do tamanho do diretório / var / log na máquina de origem.
Os servidores de origem e destino devem estar conectados a uma rede e a interface de rede conectada deve ter um endereço IP.
Se os ambientes de origem usarem somente IPv4 ou somente IPv6, o destino deverá usar a mesma configuração de endereço IP. Por exemplo, você não pode migrar para uma configuração IPv6 se o ambiente de origem usar apenas IPv4.
<número>
 [Internal Use] for Check Point employees​
The target must have the same or higher version and the same set of installed products.
The appropriate package of upgrade tools must be download for each source platform.
The correct ports for SmartConsole must be open in order for SmartConsole to communicate with the Security Management Server.
Advanced Upgrade with Database Migration (Cont.)
1
©2017 Check Point Software Technologies Ltd. 
O destino deve ter a mesma versão ou superior e o mesmo conjunto de produtos instalados.
O pacote apropriado de ferramentas de atualização deve ser baixado para cada plataforma de origem.
As portas corretas do SmartConsole devem estar abertas para que o SmartConsole se comunique com o Security Management Server.
Depois que os requisitos para a migração do banco de dados forem atendidos, crie uma cópia de backup das configurações do sistema existentes no Gaia WebUI. As configurações do sistema operacional Gaia não são submetidas a backup e devem ser configuradas manualmente se o banco de dados for restaurado posteriormente devido a problemas com a atualização. Anote as configurações do sistema operacional (interfaces, servidores, rotas, configurações do sistema, etc.) antes de atualizar.
É importante usar o pacote de ferramentas de migração correto para executar a atualização. Use o pacote de ferramentas de atualização para a versão do software que você está atualizando também. Por exemplo, ao atualizar de R77.30 para R80.10, use o pacote de ferramentas de migração para R80.10. Baixe e extraia as ferramentas para o servidor antigo (R77.30). Use o utilitário de migração do pacote de ferramentas de atualização para exportar o banco de dados de origem do Security Management Server (R77.30) para um arquivo e, em seguida, importe o arquivo para o novo servidor (R80.10).
Nota: Os bancos de dados SmartEvent não são migrados durante uma atualização avançada porque os bancos de dados podem ser muito grandes. A migração desses bancos de dados deve ser realizada separadamente. Consulte sk110173 para obter informações sobre como migrar o banco de dados SmartEvent.
<número>
 [Internal Use] for Check Point employees​
The Upgrade Verification Service
A simulation service used to help customers transition to R80. 
1
©2017 Check Point Software Technologies Ltd. 
The Upgrade Verification Service
O Serviço de Verificação de Upgrade da Check Point é um serviço de verificação de upgrade e simulação de ambiente criado para ajudar os clientes a fazer a transição para o R80.XX da forma mais integrada possível. O serviço usará arquivos de configuração da sua plataforma atual para simular o ambiente e verificar se a atualização pode ser aplicada com êxito nos principais recursos do software. A simulação também garantirá que o banco de dados não seja corrompido durante o processo de atualização. Após a conclusão, uma atualização de status dos resultados da simulação, juntamente com conselhos sobre a melhor forma de proceder, será fornecida. Para obter informações mais detalhadas sobre o Serviço de verificação de atualização, consulte sk110267.
<número>
 [Internal Use] for Check Point employees​
Use the migrate_export command to prepare to upgrade a Security Management Server.
Perform an installation of a Security Management Server.
Use the migrate_import command to populate the database of a Security Management Server.
Perform an upgrade of Security Gateways in a clustered environment.
Lab 1.1: Upgrading to R80.10
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Updates released to correct an issue or provide enhancements and improvements.
HFA is a collection of stability and quality fixes.
The name of an hotfix identifies the version it is compatible with.
Hotfixes
1
©2017 Check Point Software Technologies Ltd. 
Os hotfixes são atualizações lançadas para corrigir um problema descoberto no sistema operacional ou no software. Eles podem ser liberados para solucionar vulnerabilidades e inconsistências de segurança ou para fornecer avanços em funcionalidades e aprimoramentos. Um Acumulador de Hotfix (HFA) é uma coleção de correções de estabilidade e qualidade que resolvem vários problemas em diferentes produtos. Quando instalados, os HFAs sobrescreverão os hotfixes atuais instalados no sistema. O nome de um hotfix identifica a versão com a qual ele é compatível. Por exemplo, R80_JUMBO_HF_1_Bundle _190 é um pacote muito grande de hotfixes para R80. Além de hotfixes, algumas versões podem ter novos recursos que exigem a instalação de um complemento. A Check Point recomenda instalar o complemento apenas se os recursos ativados forem necessários.
Ao fornecer uma correção para os clientes, o Check Point fornece o arquivo atualizado e o pacote de instalação que interativamente instalará a correção. O Gaia fornece automaticamente uma lista de pacotes de atualização disponíveis para download que são relevantes para a versão do sistema operacional instalada. A página Status e Ações do CPUSE exibe hotfixes disponíveis para download e hotfixes que foram baixados, importados e instalados anteriormente.
<número>
 [Internal Use] for Check Point employees​
The CPUSE Agent
Supports the deployment of major and minor software releases, single hotfixes, and HFAs. 
1
©2017 Check Point Software Technologies Ltd. 
The CPUSE Agent
O CPUSE é uma ferramenta avançada e intuitiva usada para atualizar o sistema operacional Gaia e os produtos de software da Check Point. Ele suporta a implementação de versões principais e secundárias de software, hotfixes únicos e HFAs. Uma versão principal introduz novas funcionalidades e tecnologias. Exemplos de uma versão principal seriam R80 e R77. Os lançamentos menores incluem as últimas correções lançadas aos clientes. R77.30 é um exemplo de uma versão menor.
A ferramenta CPUSE localiza e exibe automaticamente pacotes de atualização de software e imagens completas relevantes para a versão do sistema operacional Gaia instalada no computador. Ele também considera o papel do computador (servidor de gerenciamento, gateway ou Gaia autônomo) e outras propriedades.
O agente CPUSE é instalado em todas as máquinas baseadas no Gaia e é responsável por toda a implantação de software nessa máquina. A máquina deve estar conectada à Internet para obter atualizações de software do Check Point Cloud.
 
Antes de cada instalação, o CPUSE executa vários testes de verificação para garantir que o pacote seja compatível e possa ser instalado na máquina sem conflitos. Para visualizar os pacotes disponíveis, no Portal do Gaia, navegue até a seção Atualizações (CPUSE) e selecione Status e Ações. Todos os pacotes de correcções e versõessecundárias são apresentados em categorias e são filtrados para mostrar os pacotes recomendados apenas por predefinição.
<número>
 [Internal Use] for Check Point employees​
The CPUSE Agent
1
©2017 Check Point Software Technologies Ltd. 
A Check Point recomenda fazer o download da compilação mais recente do agente CPUSE antes de aplicar um hotfix. Na maioria dos casos, a compilação mais recente é baixada automaticamente. Para verificar a compilação atual do agente, clique no link Hotfixes ao lado do número da versão do CPUSE, próximo ao topo da página Status e Ações. Uma janela pop-up aparecerá exibindo informações de hotfix. A compilação instalada do agente de implementação é exibida na parte inferior da janela. A compilação atual também pode ser verificada usando o Clish e executando o seguinte comando: HostName:0>show installer status build
Note: A versão mais recente do CPUSE é lançada gradualmente para todos os clientes; portanto, todas as máquinas podem não receber a versão mais recente ao mesmo tempo.
Os hotfixes podem ser agendados para download automático, manual ou periodicamente; no entanto, os pacotes completos de instalação e atualização devem ser instalados manualmente.
<número>
 [Internal Use] for Check Point employees​
Obtain the configuration lock before applying a hotfix.
Verify the package to determine if it can be installed without conflicts.
The download may be paused at any time.
Install the package after it has been downloaded.
Click the Install Update button to download and install all at once.
Download and Install Hotfixes
1
©2017 Check Point Software Technologies Ltd. 
Os hotfixes são aplicados primeiro baixando ou importando o pacote CPUSE e depois instalando o pacote na máquina. No Portal do Gaia, clique no ícone de cadeado para obter o bloqueio sobre o banco de dados de configuração antes de aplicar um hotfix e, em seguida, navegue até a página Status e Ações.
Cada hotfix exibido como disponível para download pode ou não ser permitido ou necessário para instalação em sua máquina. A Check Point recomenda verificar o pacote para determinar se ele pode ser instalado sem conflitos. Para verificar um pacote, execute uma das seguintes ações:
Selecione o pacote e clique no botão Mais na barra de ferramentas. Na lista de opções, clique em Verifier. Ou,
Clique com o botão direito no pacote e clique em Verifier.
A janela Resultados do verificador será exibida, indicando se a instalação é permitida ou não. Se a instalação for permitida, prossiga para baixar o pacote.
O progresso do download é exibido na coluna Status do hotfix. O download pode ser pausado a qualquer momento. Quando pausado, o status do pacote mudará para Pausar download e, em seguida, para Parcialmente baixado e poderá ser retomado a qualquer momento.
Instale o pacote depois de ter sido baixado com sucesso. Para instalar um pacote baixado, selecione o pacote e clique no botão Instalar Atualização ou clique com o botão direito no pacote e selecione Instalar Atualização. Os hotfixes também podem ser baixados e instalados de uma só vez, simplesmente clicando no botão Instalar Atualização.
A maioria dos pacotes Jumbo Hotfix e pacotes de hotfix privados são lançados no Check Point Cloud. Clique no botão Adicionar hotfixes da nuvem para pesquisar ou digite um identificador de pacote postado na nuvem. Entre em contato com o Suporte da Check Point para obter o Identificador do CPUSE do pacote ou copie e cole o nome do arquivo do Check Point Download Center. Use a string de pesquisa do CPUSE Identifier para adicionar o pacote CPUSE relevante da Check Point Cloud. Depois que o pacote for adicionado, seu status será exibido como Disponível para download.
Para importar um pacote, clique no botão Mais, localizado na barra de ferramentas da página Status e Ações, e selecione Importar Pacote. Na janela Importar Pacote, navegue até o arquivo de pacote e clique em Carregar.
<número>
 [Internal Use] for Check Point employees​
Methods for downloading:
Manually
Scheduled
Automatic
CPUSE Software Updates Policy
1
©2017 Check Point Software Technologies Ltd. 
CPUSE Software Updates Policy
A WebUI oferece diferentes métodos para o download de hotfixes via CPUSE:
Manually — Este é o método padrão. Downloads também podem ser manualmente implantados no Clish..
Scheduled — O agente CPUSE pode verificar e baixar hotfixes em um horário especificado, como diário, semanal, mensal ou em uma data selecionada.
Automatic — O agente CPUSE verificará as atualizações a cada três horas e fará o download automático dos hotfixes assim que estiverem disponíveis.
O agente CPUSE também pode enviar notificações por email aos administradores, que podem informá-los sobre eventos de atualização, como quando novos pacotes estão disponíveis para download e o sucesso ou falha de uma instalação de pacote. Para definir a política de atualização do CPUSE e configurar as notificações por email, na seção Upgrades (CPUSE), selecione Política de atualizações de software.
Pacotes de atualização de software podem ser importados e instalados offline se:
a máquina Gaia não tem acesso ao Check Point Cloud.
o pacote CPUSE desejado não está disponível no Check Point Cloud.
o administrador prefere importar manualmente o pacote CPUSE.
<número>
 [Internal Use] for Check Point employees​
Use to automatically install CPUSE offline packages on multiple Security Gateways and cluster members at the same time.
Runs on Gaia OS Security Management Servers and Multi-Domain Servers using software versions R77.30 and higher.
Supported package types:
Upgrades to R77.30
Minor version upgrades
Hotfixes
Jumbo Hotfixes (bundles) or HFAs
The Central Deployment Tool
1
©2017 Check Point Software Technologies Ltd. 
The Central Deployment Tool
Os Administradores do Sistema podem instalar automaticamente pacotes offline CPUSE em vários Gateways de Segurança e membros de cluster ao mesmo tempo, usando a CDT (Central Deployment Tool). O CDT é um utilitário que é executado no sistema operacional Gaia Security Management Servers e Multi-Domain Servers usando as versões de software R77.30 e superiores. A ferramenta se comunica com gateways e membros de cluster pelo SIC por meio da porta TCP 18209. A instalação automática em vários gateways gerenciados e membros de cluster é suportada para os seguintes tipos de pacotes:
Upgrades to R77.30
Minor version upgrades
Hotfixes
Jumbo Hotfixes (bundles) or HFAs
Antes de usar o CDT, todos os Security Gateways e membros de cluster já devem estar instalados e configurados com o SIC estabelecido e com as Políticas de Segurança instaladas. Há também vários requisitos de arquivo que devem ser atendidos antes que o utilitário possa ser executado. Isso inclui os arquivos executáveis e de configuração do CDT, bem como vários arquivos de script de shell opcionais. A versão mais recente do agente CPUSE também é necessária. O CDT usa agentes CPUSE para executar a instalação de pacotes em gateways e membros de cluster gerenciados remotamente. Todo o processo é monitorado e gerenciado pelo CDT. Para começar a usar o CDT, conecte-se à linha de comando no servidor de gerenciamento, efetue login no modo Avançado e acesse o diretório que contém os arquivos CDT.
Não use o CDT para instalações limpas de uma versão principal. Além disso, o CDT não suporta upgrades ou instalações do ClusterXL no modo de compartilhamento de carga. Para obter informações mais detalhadas sobre o utilitário CDT, consulte o Guia de Administração da Ferramenta de Implantação Central do Check Point.
<número>
 [Internal Use] for Check Point employees​
Perform an online jumbo hotfix application to a remote Security Gateway.
Lab 1.2: Applying Check Point Hotfixes
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Install the remote Security Gateway in a distributed environment and establish SIC.
Configure a new Security Gateway cluster object and verify its status.
Lab 1.3: Configuring aNew Security Gateway Cluster
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Common operations: add, set, show, save, delete
Two modes:
Standard mode (Clish): [hostname]>
Expert mode (Bash): [Expert@hostname]#
Expert mode users can run Linux commands.
Use CLI commands and tools to create automation scripts.
Available for all Check Point operating systems, Software Blades, and features.
CLI Commands
1
©2017 Check Point Software Technologies Ltd. 
Comandos CLI
Os poderosos comandos CLI do Check Point Gaia e o shell Clish são projetados para usuários que preferem interagir com o sistema executando comandos ou scripts. As operações mais comuns são: 
add 
set 
show
save
delete 
Comandos CLI podem ser inseridos em dois modos; Modo padrão e modo expert.
O modo padrão é o shell Check Point padrão (Clish) e fornece comandos para fácil configuração e administração de rotina, como cpstart e cpstop. No entanto, a maioria dos comandos do sistema não é suportada. O prompt para comandos do modo padrão é: [hostname]>
O modo Expert permite que o sistema avançado Check Point e as funções subjacentes do Linux acessem o sistema operacional Gaia. Para entrar no modo Expert, use o comando <expert> no Clish. Este comando abre o shell Bash. O prompt para o modo Expert é: [Expert@hostname]#
Um usuário do modo Expert pode executar comandos do Linux, como ls, cd e pwd, como faria em qualquer sistema Linux para manipular diretamente o sistema de arquivos do sistema operacional Gaia. Comandos básicos do Check Point como fw ver e cpconfig também podem ser executados a partir da CLI do modo Expert, semelhante ao Gaia Clish.
 
Os usuários com inclinação CLI também podem usar comandos e ferramentas CLI no modo Expert para criar scripts de automação. Essas ferramentas incluem:
dbedit — cria e configura objetos e regras no banco de dados para a Política de Segurança.
fwm load — instala a política de segurança especificada nos gateways de segurança. 
send_command — executa funções que não estão incluídas nos comandos e ferramentas padrão do Check Point CLI. 
Comandos CLI e múltiplos shells estão disponíveis para todos os sistemas operacionais baseados em Check Point Gaia, blades de software e recursos. Vários comandos úteis são anotados nesta seção, porém muitos outros comandos são discutidos em maior detalhe ao longo deste curso..
<número>
 [Internal Use] for Check Point employees​
To set the client environment:
set clienv <parameter> 
To save the client environment permanently:
save client
To acquire the configuration lock from another administrator:
lock database override
To set inactivity timeout when working with CLI:
set inactivity-timeout <value>
<value> is the timeout in minutes.
Environment Commands
1
©2017 Check Point Software Technologies Ltd. 
Environment Commands
Use estes comandos para definir o ambiente da CLI para um usuário. A sintaxe para definir o ambiente do cliente é: set clienv <parameter>
Para salvar o ambiente do cliente permanentemente:
save client
To acquire the configuration lock from another administrator:
lock database override
To set inactivity timeout when working with CLI:
set inactivity-timeout <value>
With this command, <value> is the timeout in minutes.
<número>
 [Internal Use] for Check Point employees​
System Configuration Commands
To save the system configuration to a CLI script:
save configuration <scriptname>
To restore configuration settings:
load configuration <scriptname>
To see the latest configuration settings:
show configuration
This example shows part of the configuration settings as last saved to a CLI script:
mem103> show configuration
#
# Configuration of mem103
# Language version: 10.0v1
#
Exported by admin on Mon Mar 19 15:06:22 2016
#
set hostname mem103
set timezone London / Europe
set password-controls min-password-length 6
set password-controls complexity 2
set password-controls palindrome-check true
set password-controls history-checking true
set password-controls history-length 10
set password-controls password-expiration never
set ntp active off
set router-id 6.6.6.103
set IPv6-state off
set snmp agent off
set snmp agent-version any
set snmp community public read-only
set snmp traps trap authorizationError disable
set snmp traps trap coldStart disable
set snmp traps trap configurationChange disable
1
©2017 Check Point Software Technologies Ltd. 
System Configuration Commands
Gaia system configuration settings can be saved as a ready-to-run CLI script.
To save the system configuration to a CLI script:
save configuration <scriptname>
To restore configuration settings:
load configuration <scriptname>
To see the latest configuration settings:
show configuration
This example shows part of the configuration settings as last saved to a CLI script:
mem103> show configuration
#
# Configuration of mem103
# Language version: 10.0v1
#
Exported by admin on Mon Mar 19 15:06:22 2016
#
set hostname mem103
set timezone London / Europe
set password-controls min-password-length 6
set password-controls complexity 2
set password-controls palindrome-check true
set password-controls history-checking true
set password-controls history-length 10
set password-controls password-expiration never
set ntp active off
set router-id 6.6.6.103
set IPv6-state off
set snmp agent off
set snmp agent-version any
set snmp community public read-only
set snmp traps trap authorizationError disable
set snmp traps trap coldStart disable
set snmp traps trap configurationChange disable
<número>
 [Internal Use] for Check Point employees​
System Management Commands
To add a user account:
add user <username> uid 200 homedir/home/<username>
To modify user accounts:
set user <username>
To set a user password:
set user <username> password
To show the current system date and time:
show clock
1
©2017 Check Point Software Technologies Ltd. 
System Management Commands
Há uma infinidade de tarefas de gerenciamento do sistema que podem ser executadas e configuradas usando o CLI, como o gerenciamento de usuários, sincronização de relógios do sistema, configuração de SNMP, mensagens de banner, dumps de núcleo e muito mais. Exemplos de várias dessas tarefas são indicados abaixo.
To add a user account:
add user <username> uid 200 homedir
To modify user accounts:
set user <username>
To set a user password:
set user <username> password
To show the current system date and time:
show clock
To display the current system day, date, and time:
Thu Aug 25 15:25:00 2016 CST
<número>
 [Internal Use] for Check Point employees​
A Banner message can be configured to show users when they log in. To set a banner message:
set message banner <on | off> msgvalue <banner>
Example of a banner message:
set message banner on msgvalue “This system is private and confidential” 
To enable SNMP:
set snmp agent on
To enable or disable core dumps:
set core-dump [enable|disable]
To enable or disable IPv6 support:
set IPv6-state [on|off]
show IPv6-state
System Management Commands
1
©2017 Check Point Software Technologies Ltd. 
A Banner message can be configured to show users when they log in. To set a banner message:
set message banner <on | off> msgvalue <banner>
Example of a banner message:
set message banner on msgvalue “This system is private and confidential” 
To enable SNMP:
set snmp agent on
To enable or disable core dumps:
set core-dump [enable|disable]
To enable or disable IPv6 support:
set IPv6-state [on|off]
show IPv6-state
<número>
 [Internal Use] for Check Point employees​
The syntax to configure physical interfaces is:
set interface <IF>
 IPv4-address <IP>
 mask-length <Mask>
 subnet-mask <Mask>
 IPv6-address <IF> mask-length <Mask>
 IPv6-autoconfig [on |off]
 comments <Text>
 mac-addr <MAC>
 mtu <MTU setting>
 state [on | off]
 link-speed <Speed_Duplex>
 auto-negotiation [on | off]
Network Administration Commands
1
©2017 Check Point Software Technologies Ltd. 
The syntaxto configure physical interfaces is:
set interface <IF>
 IPv4-address <IP>
 mask-length <Mask>
 subnet-mask <Mask>
 IPv6-address <IF> mask-length <Mask>
 IPv6-autoconfig [on |off]
 comments <Text>
 mac-addr <MAC>
 mtu <MTU setting>
 state [on | off]
 link-speed <Speed_Duplex>
 auto-negotiation [on | off]
<número>
 [Internal Use] for Check Point employees​
Examples: 
set interface eth2 IPv4-address 40.40.40.1 subnet-mask 255.255.255.0
set interface eth2 mtu 1500
set interface eth2 state on
set interface eth2 link-speed 1000M/full
To delete an interface setting:
delete interface eth2 IPv4-address
To create DHCP server subnets:
add dhcp server <parameter> <value>
 netmask <value>
 include-ip-pool start <value> end <value>
 exclude-ip-pool start <value> end <value>
Network Administration Commands
1
©2017 Check Point Software Technologies Ltd. 
Examples: 
set interface eth2 IPv4-address 40.40.40.1 subnet-mask 255.255.255.0
set interface eth2 mtu 1500
set interface eth2 state on
set interface eth2 link-speed 1000M/full
To delete an interface setting:
delete interface eth2 IPv4-address
Gaia automatically identifies physical interfaces, such as NICs, installed on a computer. Therefore, they cannot be added or deleted using the WebUI or the CLI. 
Gaia devices can also be configured to be a Dynamic Host Configuration Protocol (DHCP) server. DHCP servers allocate IP addresses and other network parameters to network hosts, thus eliminating the necessity of configuring each host manually. DHCP server subnets can be configured on the Gaia device interfaces to allocate network parameters, such as IPv4 addresses and DNS parameters, to hosts behind the Gaia interface. Use DHCP commands to configure the Gaia device as a DHCP server for network hosts.
To create DHCP server subnets:
add dhcp server <parameter> <value>
 netmask <value>
 include-ip-pool start <value> end <value>
 exclude-ip-pool start <value> end <value>
<número>
 [Internal Use] for Check Point employees​
To change DHCP server subnet configurations:
set dhcp server subnet <value>
To configure the DNS server:
set dns primary <value>
To configure the DNS suffix:
set dns suffix <value>
The <value> parameter for both examples is an IPv4 or IPv6 address.
Network Administration Commands
1
©2017 Check Point Software Technologies Ltd. 
To change DHCP server subnet configurations:
set dhcp server subnet <value>
Gaia uses the Domain Name Service (DNS) to translate host names in to IP addresses. To enable DNS lookups, the primary DNS server must be entered for your system. The system will consult the primary DNS server to resolve host names. A DNS suffix, which is a search for host-name lookup, can also be defined.
To configure the DNS server:
set dns primary <value>
To configure the DNS suffix:
set dns suffix <value>
The value parameter for both examples is an IPv4 or IPv6 address.
Additional CLI Commands
There are many more CLI commands available, such as commands which allow you to define static routes and configure system logging. To view a list of all possible CLI commands, log in to Clish and press the Esc tab on your keyboard twice. For operation specific commands, press the tab key.
<número>
 [Internal Use] for Check Point employees​
To view a list of all possible commands:
Log into Clish.
Press the Esc key twice.
For operation specific commands, press the Tab key twice.
Additional CLI Commands
1
©2017 Check Point Software Technologies Ltd. 
Additional CLI Commands
Há muitos mais comandos CLI disponíveis, como comandos que permitem definir rotas estáticas e configurar o log do sistema. Para ver uma lista de todos os possíveis comandos da CLI, faça o login no Clish e pressione a aba Esc do seu teclado duas vezes. Para comandos específicos da operação, pressione a tecla tab duas vezes.
<número>
 [Internal Use] for Check Point employees​
Collects diagnostic data on a machine at the time of execution.
Allows Check Point’s support engineers to analyze customer setups remotely.
Provides a more in-depth analysis of configuration options and environment settings.
CPInfo
1
©2017 Check Point Software Technologies Ltd. 
CPInfo é um utilitário Check Point que coleta dados diagnósticos em uma máquina no momento da execução. O arquivo de saída do CPInfo permite que os engenheiros de suporte da Check Point analisem as configurações do cliente remotamente. O engenheiro de suporte abre o arquivo CPInfo no modo de demonstração, enquanto visualiza as Políticas de segurança e os objetos reais do cliente. Esse processo permite uma análise mais aprofundada de todas as opções de configuração e configurações de ambiente do cliente. O CPInfo coleta todo o diretório de instalação do gateway, incluindo arquivos $ FWDIR / log / *. Algumas das outras informações visualizáveis incluem tabelas de roteamento, logs de mensagens do sistema e a saída de vários comandos, como os comandos ifconfig e fw ctl pstat. Os arquivos CPInfo são enviados para o Suporte Técnico da Check Point via e-mail ou FTP.
<número>
 [Internal Use] for Check Point employees​
CPInfo
-l — This flag is to include log records in the output file. Including log records will yield a very large output.
-z — This flag instructs the utility to gzip (compress) the output.
-v — This flag prints version information.
-n — This flag tells the utility to not collect and create a CPInfo file. It should be used with -f.
-f <file> — This flag uploads additional files to the Check Point server. It should be used in combination with -n and -i. If the file to be uploaded is not compressed, CPInfo will first compress it and then upload it.
-o <filename> — This flag directs the output to a file and to the screen. It also specifies a file name.
-y — This flag instructs the utility to display all installed hotfixes.
-k — This flag includes Firewall tables in the output.
-i — This flag is for non-interactive mode.
-d — This flag instructs the utility not to check for updates.
-a — This flag forces the update check. By default, the update check of CPInfo utility is once a week.
-u — This flag connects to the User Center with username and password.
-e <e-mail> — Specifies a single email or multiple emails of people that should be notified about upload status. Multiple emails must be enclosed in double-quotations and separated by semi-colons. For example: “<email #1>;<email #2>”
-s <SR_Number> — Specifies the Service Request number opened with Check Point Support. For example, -s 28-123456789
-T <timeout> — Specifies the timeout in seconds for the commands executed by the utility. This does not apply to collection of the CPInfo output file itself. The default timeout is 600 seconds (5 minutes).
-h — The flags displays the built-in help.
1
©2017 Check Point Software Technologies Ltd. 
To use CPInfo, make sure that the platform’s current version of cpinfo is installed to extract the CPInfo file. Run the cpinfo command with the relevant flags in Clish or in Expert mode:
-l — This flag is to include log records in the output file. Including log records will yield a very large output.
-z — This flag instructs the utility to gzip (compress) the output.
-v — This flag prints version information.
-n — This flag tells the utility to not collect and create a CPInfo file. It should be used with -f.
-f <file> — This flag uploads additional files to the Check Point server. It should be used in combination with -n and -i. If the file to be uploaded is not compressed, CPInfo will first compress it and then upload it.
-o <filename> — This flag directs the output to a file and to the screen. It also specifies a file name.
-y — This flag instructs the utility to display all installed hotfixes.
-k — This flag includes Firewall tables in the output.
-i — This flag is for non-interactive mode.
-d — This flag instructs the utility not to check for updates.
-a — This flag forces the update check. By default, the update check of CPInfo utility is once a week.
-u — This flag connects tothe User Center with username and password.
-e <e-mail> — Specifies a single email or multiple emails of people that should be notified about upload status. Multiple emails must be enclosed in double-quotations and separated by semi-colons. For example: “<email #1>;<email #2>”
-s <SR_Number> — Specifies the Service Request number opened with Check Point Support. For example, -s 28-123456789
-T <timeout> — Specifies the timeout in seconds for the commands executed by the utility. This does not apply to collection of the CPInfo output file itself. The default timeout is 600 seconds (5 minutes).
-h — The flags displays the built-in help.
<número>
 [Internal Use] for Check Point employees​
Perform basic tasks related to Security Policy management from the Command Line Interface.
Use common commands to evaluate the condition of a Security Gateway.
Lab 1.4: Core CLI Elements of Firewall Administration
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
The Check Point Firewall Software Blade builds on the award-winning technology first offered in Check Point’s Firewall solution and provides the industry’s best cyber security. 
Advanced Firewall
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
O Check Point Firewall Software Blade baseia-se na tecnologia premiada oferecida pela solução de firewall da Check Point e oferece a melhor segurança cibernética do setor. Tendo demonstrado a liderança do setor e a inovação contínua desde a introdução do Firewall-1 em 1994, a Check Point Firewalls é confiável por 100% das empresas da Fortune 100.
<número>
 [Internal Use] for Check Point employees​
GUI Client
Security Management
Security Gateway
Check Point Security Components
1
©2017 Check Point Software Technologies Ltd. 
Check Point Firewall Infrastructure
Como especialista em segurança, considerando as necessidades da sua organização, um conhecimento profundo dos gateways de segurança deve ser aplicado à medida que você os implementa, além de uma implantação distribuída simples. Para estabelecer uma estrutura para avaliar o desempenho do gateway em uma topologia de rede complexa, você deve entender a infraestrutura.
Você deve se lembrar do CCSA que, fundamentalmente, os componentes de segurança da Check Point estão divididos nos seguintes componentes:
GUI Client
Security Management
Security Gateway
GUI Client
Aplicativos GUI, para manipulação de objetos, visualização de logs e relatórios, como SmartView Monitor e SmartEvent, são todos unificados em um único console (SmartConsole). Esses aplicativos GUI oferecem a capacidade de configurar, gerenciar e monitorar soluções de segurança, executar tarefas de manutenção, gerar relatórios e aplicar a diretiva corporativa em tempo real.
A Check Point lança periodicamente novos executáveis que incluem atualizações para aplicativos SmartConsole. Essas atualizações nem sempre estão relacionadas ou alinhadas aos hotfixes do Security Gateway e são consideradas uma faixa de lançamento separada e não relacionada.
Security Management
O componente de gerenciamento é responsável por todas as operações de gerenciamento no sistema. Ele contém vários elementos, como o servidor de gerenciamento, o conjunto de relatórios, o servidor de log, etc. Toda a funcionalidade do servidor de gerenciamento é implementada nos processos do modo de usuário, em que cada processo é responsável por várias operações.
<número>
 [Internal Use] for Check Point employees​
The main management process
Allows the GUI client and management server to communicate
Performs database tasks
Controls the following processes:
web_server
dle_server
object_store
Check Point Management (cpm)
1
©2017 Check Point Software Technologies Ltd. 
O Check Point Management (cpm) é o principal processo de gerenciamento. Ele fornece a arquitetura para um ambiente de segurança unificado. O CPM permite que o cliente da GUI e o servidor de gerenciamento se comuniquem via serviços da Web usando a porta TCP 19009. Ele permite a migração da lógica do lado do cliente herdada para a lógica do lado do servidor. O processo cpm realiza tarefas de banco de dados, como criar, excluir e modificar objetos e compilar políticas. Os processos controlados pelo CPM incluem:
web_services — Transfere solicitações para o dle_server.
dle_server — Contém toda a lógica do servidor e valida as informações antes de serem gravadas no banco de dados.
object_store — Traduz e grava dados no banco de dados.
O CPM salva todos os dados no banco de dados SQL do Postgres e armazena a maioria dos dados no Solr, um servidor de pesquisa independente desenvolvido pela biblioteca de pesquisa do Lucene Java. O banco de dados SQL do Postgres contém objetos, políticas, usuários, administradores, licenças e dados de gerenciamento. Os dados são segmentados em vários domínios do banco de dados. O Solr gera índices dos dados a serem usados para recursos de pesquisa de texto completo. 
<número>
 [Internal Use] for Check Point employees​
fwm – Firewall Management
fwd – Check Point Firewall Daemon
fwssd – Firewall Security Servers
cpd – Check Point Daemon
cpwd – Check Point 
Additional Management Processes
1
©2017 Check Point Software Technologies Ltd. 
Additional significant management processes include:
fwm - O Firewall Management (fwm) está presente em todos os produtos de gerenciamento, incluindo o Multi-Domain Security Management, e em produtos que exigem acesso direto à GUI, como o SmartEvent. O processo fwm é usado principalmente para compatibilidade com versões anteriores dos gateways. Ele fornece comunicação com o cliente GUI, manipulação de banco de dados, compilação de política e sincronização de alta disponibilidade de gerenciamento.
fwd - O Check Point Firewall Daemon (fwd) permite que outros processos, incluindo o kernel, encaminhem os logs para os servidores de log externos, bem como para o Security Management Server. Ele se comunica com o kernel usando ferramentas de linha de comando, como os comandos fw, variáveis ​​do kernel e comandos de controle do kernel.
fwssd - Um processo filho de fwd. É responsável por gerenciar os Firewall Security Servers, que fornecem um nível mais alto de imposição de protocolo.
cpd - O Check Point Daemon (cpd) é um processo central em todos os produtos da Check Point. Ele permite a funcionalidade de Comunicação Interna Segura (Secure Internal Communication - SIC), obtém o status de monitoramento do aplicativo, transfere mensagens entre processos do Firewall, busca e instala políticas e muito mais.
cpwd - Check Point WatchDog (cpwd) invoca e monitora processos críticos, como os daemons do Check Point na máquina local, e tenta reiniciá-los se eles falharem. Entre os processos monitorados pelo cpwd estão cpd, fwd e fwm. O utilitário cpwd_admin mostra o status dos processos e configura o cpwd.
<número>
 [Internal Use] for Check Point employees​
Responsible for security enforcement, encryption/decryption, authentication, and accounting.
Functionality implemented both in User-Mode and in the kernel.
Security Gateway
1
©2017 Check Point Software Technologies Ltd. 
Security Gateway
O Security Gateway, às vezes referido simplesmente como o Firewall, é o componente do sistema responsável pela aplicação da segurança, criptografia / descriptografia, autenticação e contabilidade.
A funcionalidade do Gateway de Segurança é implementada tanto no modo do usuário quanto no kernel. O Security Gateway é um dispositivo de rede que executa um sistema operacional que o torna vulnerável a possíveis ataques na camada de rede. Para atenuar essa vulnerabilidade, algumas das funcionalidades do Firewall são implementadas no modo kernel. Isso permite que o tráfego seja inspecionado antes mesmo de chegar à pilha de IP do sistema operacional.
<número>
 [Internal Use] for Check Point employees​
Responsible for the majority of the Security Gateway’s operations.
Certain processes operate in the User Mode space and others operatein kernel mode space.
The Firewall Kernel
1
©2017 Check Point Software Technologies Ltd. 
O kernel do Firewall é responsável pela maioria das operações do Gateway de Segurança, como aplicação de segurança, criptografia / descriptografia, NAT, etc. Para detectar qual parte do kernel pode ser responsável por um problema específico, comece considerando a estrutura interna do kernel do Firewall e sua interação com o kernel do sistema operacional (Gaia), o hardware e outros componentes do kernel, como a aceleração. Existem certos processos que operam no nível do sistema operacional no espaço do Modo do Usuário e outros que operam no espaço do modo kernel.
<número>
 [Internal Use] for Check Point employees​
Kernel Mode resides in the Data Link layer of the OSI model. Every packet that goes through the Firewall is inspected.
User Mode allows the Firewall to function more efficiently in the Application layer.
Input/Output Controls and traps allow user and kernel processes to communicate.
User and Kernel Mode Processes
1
©2017 Check Point Software Technologies Ltd. 
User and Kernel Mode Processes
O Modo Kernel reside na camada Data Link do modelo OSI. O kernel do Firewall inspeciona os pacotes entre a camada de enlace de dados e a camada de rede. Todo pacote que passa pelo Firewall é inspecionado. Nas camadas de rede, você não veria todos esses pacotes.
O modo de usuário não é obrigatório, no entanto, permite que o Firewall funcione com mais eficiência na camada de aplicativo. O Firewall emprega serviços do sistema operacional e facilita a inspeção de arquivos em conexões abertas.
 
É possível e, em alguns casos, necessário para os processos do usuário e do kernel se comunicarem. Para permitir isso, existem dois mecanismos: Controles de entrada / saída (IOctl) e traps. Quando um processo do Kernel deseja sinalizar para um processo do modo do usuário, ele define uma interceptação alterando um valor em uma chave do Registro. O processo do modo de usuário que monitora esse sinalizador tropeça no trap e executa a operação solicitada. Quando uma entidade User Mode precisa gravar informações em um processo do kernel, ele usa IOctl, que é uma infraestrutura que permite que a entidade chame uma função no kernel e forneça os parâmetros necessários.
Como administradores tentando depurar o Firewall, a primeira observação a ser feita é decidir qual funcionalidade do Firewall é implementada no espaço do usuário e qual é implementada no kernel. Uma vez feita essa distinção, decida qual a melhor abordagem a ser usada para resolver o problema, incluindo qual ferramenta é a mais apropriada para usar.
<número>
 [Internal Use] for Check Point employees​
Inbound and Outbound Packet Flow
Traffic arrives into the Firewall through the NIC.
The Firewall kernel is installed on each NIC.
Inbound and Outbound processes inspect the packet.
Each direction has its own ordered chain of modules, or packet process handlers.
Handlers decide whether to continue, terminate or hold the processing of a packet.
Inspection is performed on virtually defragmented packets.
1
©2017 Check Point Software Technologies Ltd. 
Packet Flow
Para entender como os pacotes são inspecionados, considere o kernel do Firewall mais de perto.
Inbound and Outbound Packet Flow
O tráfego chega primeiro ao Firewall por meio de uma das NICs (Firewall Network Interface Cards). O kernel do Check Point Firewall é instalado em cada NIC de firewall ativada no sistema operacional. O kernel do Firewall consiste em duas partes lógicas completamente separadas, chamadas Inbound and Outbound, que representam o processo de entrada e saída de pacotes do Firewall. Esses processos funcionam em cada pacote através de outro processo chamado inspeção. Cada parte atua independentemente e não assume que um pacote tenha sido inspecionado ou processado pelo outro. Portanto, algumas funcionalidades são implementadas tanto na entrada quanto na saída. Alguns pontos-chave incluem:
Cada direção tem sua própria cadeia ordenada de módulos, ou manipuladores de processamento de pacotes.
Os manipuladores decidem se devem continuar, encerrar ou manter o processamento de um pacote.
A inspeção é executada em pacotes virtualmente desfragmentados.
O processo de inspeção espera que um pacote na Saída que não tenha entrado na Entrada tenha sido originado pelo próprio Gateway de Segurança. Também assumiu que um pacote não originário do gateway era de entrada.
<número>
 [Internal Use] for Check Point employees​
Packet Inspection Flow
The packet arrives at the Security Gateway and is intercepted by the NIC on the Inbound.
The Firewall kernel Inbound chain begins inspecting the packet.
The packet is matched against the Rule Base. A log is generated and sent from the kernel to the User Mode process, fwd, located in the Security Gateway.
The fwd process on the Security Gateway sends the log to the fwd process on the Management server, where it is forwarded to cpm via cpd.
cpm sends the log to the relevant SmartConsole GUI application, such as SmartView Monitor.
At the same time, depending on routing decisions made by the operating system and excluding specific scenarios such as VPN routing, the packet is routed to a selected NIC. The packet must go through the Firewall kernel again, only this time through the Outbound chain to the appropriate NIC and to the network.
1
©2017 Check Point Software Technologies Ltd. 
Packet Inspection Flow
The following diagram describes a packet flow through the Firewall kernel and how the User Mode processes work to control the traffic.
O pacote chega ao Gateway de Segurança e é interceptado pela NIC na Entrada.
A cadeia de entrada do kernel do Firewall começa a inspecionar o pacote.
O pacote é comparado com a Base de Regras. Um log é gerado e enviado do kernel para o processo User Mode, fwd, localizado no Security Gateway.
O processo fwd no Security Gateway envia o log para o processo fwd no servidor de gerenciamento, para o qual ele é encaminhado para cpm via cpd.
O cpm envia o log para o aplicativo relevante do SmartConsole, como o SmartView Monitor.
Ao mesmo tempo, dependendo das decisões de roteamento feitas pelo sistema operacional e da exclusão de cenários específicos, como roteamento de VPN, o pacote é roteado para uma NIC selecionada. O pacote deve passar pelo kernel do Firewall novamente, somente desta vez pela cadeia de saída para o NIC apropriado e para a rede.
<número>
 [Internal Use] for Check Point employees​
Packet process handlers which decide which modules will inspect the packet.
The number of chains on a gateway is based on the number of blades and features enabled.
Chain Modules
1
©2017 Check Point Software Technologies Ltd. 
Chain Modules
Módulos de cadeia são manipuladores de processamento de pacotes. Os manipuladores decidem quais módulos inspecionarão o pacote e, com base na inspeção, poderão modificar, transmitir ou descartar os pacotes. Cada módulo da cadeia tem um trabalho exclusivo. O número de cadeias em um gateway de segurança é baseado no número de blades e recursos ativados para esse gateway. Pacotes de entrada e saída são inspecionados em ambas as direções por módulos de cadeia. A familiaridade com os elementos de um módulo de cadeia é uma etapa importante na compreensão de como o tráfego passa pelo firewall e, em última análise, será de grande ajuda quando a depuração for necessária.
Considere o seguinte exemplo de módulo de cadeia. A localização do módulo na cadeia é um número de série relativo para o local desse módulo em cadeia para essa configuração de gateway específica. Por exemplo, acima da saída de VM fw é o módulo da sexta cadeia. Pode estar em um local diferente em outros cenários de gateway. A posição da cadeia é um número absoluto que nunca muda. No kernel do Firewall, cada kernel é associado a uma chave, que especifica o tipo de tráfego aplicável ao módulo da cadeia. Para a configuração do modo de conexão, os módulos de corrente marcados com 1 não se aplica e para o modo com monitoração de estado,os módulos de cadeia marcados com 2 não se aplica. Módulos encadeados marcados como ffff, como IP Options Strip / Restore e 3 será aplicado a todo o tráfego.
Para dar uma olhada em uma corrente real, use o comando fw ctl chain. Isso mostrará os módulos da cadeia atualmente carregados em sua máquina e seu pedido.
<número>
 [Internal Use] for Check Point employees​
Chain Modules
Inbound fw ctl Chain Modules
Outbound Chain
1
©2017 Check Point Software Technologies Ltd. 
Inbound fw ctl Chain Modules
Veja os módulos de corrente exibidos abaixo. Nessa figura, vemos a cadeia de entrada, embora este seja apenas um exemplo e, em configurações diferentes, alguns módulos da cadeia não apareçam e outros possam ser adicionados. Entre versões diferentes, os módulos de cadeia são adicionados ou removidos, dependendo das decisões de design específicas da versão.
Outbound Chain Modules
Veja os módulos de corrente exibidos abaixo. Mostrada nesta figura, a cadeia de saída mostra aproximadamente os mesmos módulos de cadeia vistos na entrada. A diferença mais significativa é que no Inbound, o vpn decrypt e o vpn decrypt verify módulos de cadeia estão presentes. Isso faz sentido porque é esperado que um pacote seja descriptografado na entrada. Além disso, a cadeia de saída também tem o vpn encrypt módulo de cadeia, se o pacote precisar ser criptografado na Saída.
Wire Mode
O Wire Mode permite que as conexões VPN mantenham com êxito uma sessão VPN privada e segura sem empregar a inspeção com informações de estado. Usando o modo Wire, o Firewall pode ser ignorado para conexões VPN, definindo interfaces internas e comunidades como “confiáveis”. Isso melhora o desempenho do túnel VPN e reduz o tempo de inatividade. Com a Stateful Inspection não mais ocorrendo, os protocolos de roteamento dinâmico que não sobrevivem à verificação de estado em configurações de modo não-wire podem agora ser implantados. O Wire Mode é baseado em uma origem e um destino confiáveis e usa interfaces internas, como o Gateway de segurança e Comunidades VPN.
<número>
 [Internal Use] for Check Point employees​
Demonstrate an understanding of how different Check Point Software Blade deployments can affect traffic inspection on the Security Gateway.
Evaluate how changes in the environment affect the Chain Modules.
Lab 1.5: Viewing the Chain Modules
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Stateful Inspection
Packets pass through the Network Interface Card (NIC) to the Inspection Module, which inspects the packets and their data.
Packets are matched to the policy Rule Base. Packets that do not match any rule are dropped.
Logging and/or alerts that have been defined are started.
Packets that pass inspection are moved through the TCP/IP stack to their destination.
For packets that do not pass inspection and are rejected by the rule definition, a negative acknowledgment (NACK) is sent (i.e. RST packet on TCP and ICMP unreachable on UDP).
Packets that do not pass inspection and do not apply to any of the rules are dropped without sending a NACK.
1
©2017 Check Point Software Technologies Ltd. 
Stateful Inspection
A Stateful Inspection foi inventada pela Check Point para fornecer inspeção de tráfego precisa e altamente eficiente. Além de verificar o cabeçalho IP de um pacote, o Stateful Inspection também implementa verificações de outras características de um pacote, como fluxo TCP, números de seqüência, comunicação UDP e números de porta para monitorar o estado de um pacote operando principalmente na camada de Transporte do pacote. sistema operacional. O mecanismo de inspeção examina todos os pacotes à medida que são interceptados na camada de rede. O estado da conexão e as informações de contexto são armazenadas e atualizadas dinamicamente nas tabelas do kernel. As tabelas de kernel também são conhecidas como tabelas de estado.
To see the process flow of the Inspection Engine, review the flow chart below.
Os pacotes passam pela placa de interface de rede (NIC) para o módulo de inspeção, que inspeciona os pacotes e seus dados.
Os pacotes são correspondidos à base de regras da política. Pacotes que não correspondem a nenhuma regra são descartados.
Logging e / ou alertas que foram definidos são iniciados.
Os pacotes que passam pela inspeção são movidos pela pilha TCP / IP até o destino.
Para pacotes que não passam na inspeção e são rejeitados pela definição da regra, uma confirmação negativa (NACK) é enviada (ou seja, pacote RST no TCP e ICMP inacessível no UDP).
Os pacotes que não passam na inspeção e não se aplicam a nenhuma das regras são descartados sem o envio de uma NACK.
<número>
 [Internal Use] for Check Point employees​
The individual processes within the Firewall system that are responsible for the detailed protocol-specific security inspection such as:
FTP
HTTP
SIP, and
other inspection services like DLP.
Security Servers
1
©2017 Check Point Software Technologies Ltd. 
Security Servers
Security servers are a necessary and crucial element to Firewall functionality. Some Firewall features require a higher level of protocol enforcement and RFC compliance, such as in the Application Layer. 
Security servers are the individual processes within the Firewall system that are responsible for the detailed protocol-specific security inspection such as FTP, HTTP, or SIP and other inspection services like DLP.
Note: When Identity Awareness is deployed, this process operates differently.
How a Security Server Works
Essentially, when a client initiates a connection to a server, the Firewall kernel signals the fwd process using a trap. fwd spawns the fwssd child service, which runs the Security server. Then, the Security server binds to a socket and manages the connection.
fwd waits for connections on the ports of other servers (daemons) and starts the corresponding server when the connection is made. fwd also talks to its children processes on other servers using a pipe and signals.
The $FWDIR/conf/fwauthd.conf file contains the structure of the security servers showing the port numbers, corresponding protocol name, and status. If the real port is 0, then a higher random port is assigned.
<número>
 [Internal Use] for Check Point employees​
Dozens of kernel tables store information relevant to a specific Firewall function.
Use fw tab –t <tablename> to view all existing kernel tables.
The Connections table is an approved list of connections.
Use fw tab –t connections –f to view the Connections table.*
Kernel Tables
* Using this command could impact performance.
1
©2017 Check Point Software Technologies Ltd. 
Kernel Tables
Existem dezenas de tabelas de kernel, cada uma armazenando informações relevantes para uma função específica do Firewall. Usando as informações salvas nas tabelas do kernel, proteções muito elaboradas e precisas podem ser implementadas. Para visualizar todas as tabelas de kernel existentes, digite o comando fw tab -t <tablename> no prompt de comando. Para visualizar apenas os nomes das tabelas e obter uma perspectiva sobre o número de tabelas de kernel disponíveis, use o comando fw tab -s.
A maioria das informações relacionadas ao tráfego é salva nas tabelas do kernel. As informações também são armazenadas em htabs, ghtabs, arrays, kbufs e outros dispositivos. Tabelas podem ser criadas, excluídas, modificadas e lidas. Em particular, considere a tabela Conexões.
Tabela de Conexões
A tabela Conexões é essencialmente uma lista aprovada de conexões. O Firewall, como um dispositivo de segurança de rede, inspeciona cada pacote que entra e sai de cada interface. Depois que o primeiro pacote é comparado com a Base de Regras, assumimos que o pacote retornado pode não ser aceito na Base de Regras.
Por exemplo, permitimos que o 74.100.100.1 se conecte com o 212.150.141.5 usando o Telnet na porta 23 na Base de Regras e descarte todo o resto. O pacote syn corresponderá à Base de Regras e passará; mas o pacote Syn-Ack retornacom a tupla invertida (IP de origem 212.150.141.5, Destino IP 74.100.100.1) e a porta de origem 23 com uma porta de destino aleatório. (Consulte a figura da tabela de conexões na seção a seguir).
Para atenuar isso, para cada conexão registrada, uma entrada correspondente de tupla reversa também é adicionada à lista de conexões aprovadas. Alguns cenários, como NAT, conexões de dados e protocolos elaborados, como Voz sobre IP (VoIP), introduzem mais complexidade à lógica por trás da manutenção da tabela Conexões.
 
A tabela Conexões fornece desempenho aprimorado. Como vimos no Fluxograma do Processo de Inspeção, a ação de combinar um pacote com a Base de Regras pode ser muito cara (especialmente se houver uma Base de Regras muito grande com objetos dinâmicos e servidores lógicos que precisam ser resolvidos). Mantendo a lista de conexões aprovadas na tabela Conexões, o gateway pode impor uma análise inteligente para a correspondência de regras assumida, economizando tempo valioso e capacidade de computação.
 
A tabela Conexões também permite respostas do servidor. Observamos anteriormente que, às vezes, os pacotes Servidor para Cliente (S2C) podem não corresponder à Base de Regras. Nestes casos, eles seriam manipulados pela tabela Conexões. Para visualizar a tabela Conexões, use o seguinte comando:fw tab -t connections -f
Note: Using the fw tab -t connections -f command could impact performance.	
<número>
 [Internal Use] for Check Point employees​
These Stateful features are provided with the Connections table:
Streaming based applications
Sequence verification and translation
Hide NAT (Explicit entries may need to be added to the Connections table.)
Logging, accounting, monitoring, etc.
Client and server identification
Data connections
Connections Table
1
©2017 Check Point Software Technologies Ltd. 
The following Stateful features are provided with the Connections table:
Aplicativos baseados em streaming
Verificação e tradução de seqüências
Ocultar NAT (entradas explícitas na tabela Conexões podem precisar ser adicionadas quando os pacotes S2C que retornam ao Firewall podem não corresponder à Base de Regras.)
Extração de madeira, contabilidade, monitoramento, etc.
Identificação de cliente e servidor
Conexões de dados
<número>
 [Internal Use] for Check Point employees​
Connections Table Format
The Symbolic Link format provides the 6-tuple of the connection we want to pass.
The arrow is a pointer to the tuple of the Real Entry.
The first six attributes in every entry state the connection’s 6-tuple.
The direction can be either 0 for Inbound or 1 for Outbound.
1
©2017 Check Point Software Technologies Ltd. 
Connections Table Format
Cada novo pacote é registrado na tabela em todas as entradas disponíveis. No FireWall-1 versão 4.1, apenas uma entrada foi feita para cada nova conexão. Cada pacote teve que passar pela tabela Conexões várias vezes para verificar todos os tipos de conexão disponíveis. Hoje, cada pacote passa por uma única consulta, pois todas as entradas disponíveis já estão registradas na tabela.
O formato Symbolic Link fornece a 6-tupla da conexão que queremos passar. A seta é um ponteiro para a tupla da Entrada real na tabela Conexões. Os primeiros seis atributos em cada entrada na tabela Conexões indicam a 6-tupla da conexão. A 6-tupla é uma identificação única da conexão dentro do sistema. A direção pode ser 0 para entrada ou 1 para saída.
Na figura da Tabela de Conexões, vemos uma representação de conexão simples na tabela Conexões. A primeira entrada é chamada Entrada Real e contém todas as informações relevantes para esse tráfego, como estado, números de sequência e regra de correspondência.
 
A Entrada Real permite que o pacote Cliente para Servidor (C2S) insira o Firewall na Entrada. A segunda entrada é um Link simbólico, permitindo que os mesmos pacotes C2S entrem no Firewall na Saída. A terceira entrada é outro Link simbólico que permite que o tráfego S2C entre no Firewall na Entrada. A última entrada também é um link simbólico e permite que o pacote S2C entre no firewall na saída.
<número>
 [Internal Use] for Check Point employees​
Three main stages:
Verification & Compilation
Transfer (CPTA)
Commit
Policy Installation
1
©2017 Check Point Software Technologies Ltd. 
The policy installation process is divided into three main stages: Verification & Compilation, Transfer (CPTA), and Commit. 
<número>
 [Internal Use] for Check Point employees​
Initiation
Database Dump
Verification
Conversion
Fwm rexec
 
Verification & Compilation Stage
1
©2017 Check Point Software Technologies Ltd. 
Verification & Compilation
The Verification & Compilation stage of policy installation occurs on the management side. It involves the following steps:
 
Initiation — Policy installation is initiated either from SmartConsole or from the command line. Information required for the policy installation, such as the list of gateways on which the policy is to be installed, is provided. User permissions for policy installation will also occur prior to continuing to the next step in the process.
Database Dump — A database dump from postgres to old file formats for cpmitable only if changes occurred. A dump from non cpmi will occur any time.
Verification — Information in the database is verified to comply with a number of rules specific to the application and package for which policy installation is requested. If this verification fails, the process ends here, and an error message is passed to the initiator. The system can also issue warnings in addition to fail/success messages.
Conversion — The information in the database is converted from its initial format to the format understandable by later participants in the flow, such as code generation and gateway.
Fwm rexec — Fwm loader takes a lot of memory. To release memory after verification and conversion, fwm state is saved to a file located in the $FWDIR/tmp/ directory. fwm is then re-executed as a fwm load command to push the files for code generation and compilation.
Code Generation and Compilation — Policy is translated to the INSPECT language and compiled with the INSPECT compiler. Also, some additional data transformations are completed. After verifying and converting the database, the fwm process compiles the relevant files, such as objects_5_0.C, and AccessCTRRules_0.C, into several compiled files (local.ft, local.set, etc.). The complied policy will be copied to the $FWDIR/state/<gateway name> directory on the management server.
<número>
 [Internal Use] for Check Point employees​
Occurs between both the management server and the gateway.
The Check Point Policy Transfer Agent (CTPA) transfers the compiled policy to the gateway via SIC. The connection is encrypted using SSL.
Once SIC is initialized, SIC authentication will occur for every policy installation.
Transfer (CTPA) Stage
1
©2017 Check Point Software Technologies Ltd. 
Transfer (CPTA)
O estágio de transferência ocorre entre o servidor de gerenciamento e o gateway. Depois que a diretiva é compilada e movida com êxito para $ FWDIR / state / <gateway> no servidor de gerenciamento, o CPTA transfere a diretiva compilada para o gateway usando o SIC. O uso do SIC garantirá que o servidor de gerenciamento esteja qualificado para instalar a política no gateway. Ele também criptografa a conexão via SSL para que os dados da política transferidos para o gateway sejam confiáveis. Depois que o SIC for inicializado, a autenticação do SIC ocorrerá para cada instalação de diretiva.
<número>
 [Internal Use] for Check Point employees​
The Firewall is instructed to load the new policy it received from the Management server.
The following steps occur:
The cpd process will execute the fw fetchlocal –d $FWDIR/state/_tmp/FW1 command to load the policy.
The policy will be loaded into the kernel.
The new policy will be copied to the $FWDIR/state/FW1 folder on the gateway.
If the fetchlocal process fails, cpd will be notified and will inform the fwm process.
Commit Stage
1
©2017 CheckPoint Software Technologies Ltd. 
Commit
During the Commit stage, the Firewall is instructed to load the new policy it has just received from the management server. The following steps will occur:
The cpd process on the gateway will execute the following command to load the policy which was just transferred to the gateway:
	fw fetchlocal -d $FWDIR/state/_tmp/FW1
The policy will then be loaded into the kernel.
If successful, the new policy will be copied to the $FWDIR/state/FW1 folder on the gateway.
If the fetchlocal process fails, cpd will get a notification regarding the failed process and will inform the fwm process that loading the policy has failed.
<número>
 [Internal Use] for Check Point employees​
Policy Installation Flow
The policy is defined in SmartConsole.
The published policy is saved in the postgres database. At a push, verification of user permission is performed.
Database dump from postgres to old file formats (object_5_0.C and others) for cpmitable and a dump for non cpmi will occur. 
After the policy is saved, files are created under $FWDIR/conf/*.W and stored in rulesbases_5.0.fws.
fwm_gen compiles the new $FWDIR/conf/*.W and creates a new file called $FWDIR/conf/*.pf. 
c_preprocessor compiles the *.pf and lib/*.def files and creates a new file called *.cpp. 
All new generated files are stored under $FWDIR/state/ on the management server. *.ccp is compiled, translated, and transferred to the gateway.
$FWDIR/state/ directory is pushed to the enforcement module (gateway).
cpd and the kernel on the gateway performs an automatic load.
1
©2017 Check Point Software Technologies Ltd. 
Policy Installation Flow
The graphic below displays a general process flow for policy installation. Differences are version specific, so $FWDIR is replaced with the compatibility package when other products or versions are used.
The policy is defined in SmartConsole.
After the policy is published, it is saved in the postgres database. At a push, verification of user permission is performed.
Database dump from postgres to old file formats (object_5_0.C and others) for cpmitable, only if changes occurred, and a dump for non cpmi will occur. All *.W files are stored in rulebases_5_0.fws.
After the policy is saved, files are created under $FWDIR/conf/*.W.
fwm_gen compiles the new $FWDIR/conf/*.W into a machine language, creating a new file called $FWDIR/conf/*.pf. The $FWDIR/conf/*.pf is actually the input from the $FWDIR/conf/*.W and the $FWDIR/conf/objects.C files. The $FWDIR/conf/*.W file is the exact same information defined in the GUI, just in a text format instead of a graphic one.
c_preprocessor compiles the *.pf and lib/*.def files, creating a new file called *.cpp. 
All new generated files are stored under $FWDIR/state/ on the management server. *.ccp is compiled and translated to a machine language and transferred to the gateway.
$FWDIR/state/ directory is pushed to the enforcement module (gateway).
cpd and the kernel on the enforcement module performs an automatic load.
<número>
 [Internal Use] for Check Point employees​
Policy Installation by Management Processes
cpmi policy installation command is sent to fwm on the Management server.
fwm performs verification and conversion of the database information for the installation targets for which policy installation is requested.
fwm invokes fw loader to perform code generation, compilation, transfer to all applicable gateways, and commit.
cpd on the Security Gateway listens for install policy connections and receives the files.
cpd invokes fw fetchlocal to load the new policy into the kernel.
cpd waits for fw fetchlocal 
1
©2017 Check Point Software Technologies Ltd. 
Policy Installation by Management Processes
Now we will examine how policy installation is handled the Management processes.
When policy installation is initiated from SmartConsole:
O comando de instalação da diretiva Check Point Management Interface (cpmi) é enviado para o fwm no servidor de gerenciamento.
O fwm executa a verificação e a conversão das informações do banco de dados para os destinos de instalação para os quais a instalação da política é solicitada.
Após a conversão, o fwm chama o fw loader para executar a geração de código, a compilação, a transferência para todos os gateways aplicáveis e o commit.
cpd no Security Gateway escuta as conexões da política de instalação e recebe os arquivos.
O cpd invoca o fw fetchlocal para carregar a nova política no kernel.
cpd espera por fw fetchlocal para concluir o processo e informa ao servidor de gerenciamento o status do comando (a instalação foi bem-sucedida ou falhou).
Note: Additional steps may be included for debugging purposes.
<número>
Rule Matching
Security Gateways prior to R80.10
 
R80.10 Security Gateways and later
Inspect and match rules by column.
Inspection begins in the Destination column.
The integration of application and data criteria requires deep packet inspection before determining the final match.
1
©2017 Check Point Software Technologies Ltd. 
Rule Matching
The Security Gateway determines the rule to apply to a connection; therefore, it is important to understand how rules are matched. The columns of a rule contain the expected elements of a connection and dictate what happens to the connection.
Column Based Matching
Security Gateway versions prior to R80.10, inspect and match connections row by row (left to right), based on the order of rules within the Rule Base. The Rule Base is examined top-to-bottom and the first matching rule is executed.
R80.10 and later Security Gateways match rules by column, such that only the rules within the Rule Base that may possibly match a connection are considered. Column based matching eliminates the process of examining rules which do not contain the applicable elements of the connection.
The Matching Process
Access Control Policy rules use the following columns to filter and match traffic entering and exiting the network:
Source
Destination
VPN (if enabled)
Services & Applications (if Appl Control & URL Filtering Software Blades are enabled)
Content (Content Awareness must be enabled)
Time
Installed On (target gateway)
Inspection starts in the first ordered layer of the Access Control policy (usually Policy or Network). If a matched rule contains an inline layer, that inline layer is processed. Matching continues with each additional ordered policy layer after a successful match. Any drop stops the matching process and drops the connection. 
Currently, the Security Gateway begins examining the fields of the Destination column to identify rules that may match the connection. When possible matches are filtered, matching continues with the Source column. Final inspection on the filtered results occurs when all columns are matched and the first rule (top to bottom) that matches is executed for that layer, and subsequent inline or ordered layers are processed.
The illustration below displays the matching process for traffic connecting to the A-Host from the B-Host using FTP.
A Unified Access Control policy may contain application or data criteria that cannot be matched on the first packet connection. The integration of application and data criteria requires deep packet inspection.
To optimize the matching process, the Firewall may need to turn on one or more inspection engines and inspect the header and body of the connection before determining the final match. Otherwise, the Rule Base may decide to block the connection at an early stage. An early block may indicate that the connection did not contain enough applicable data criteria for the engine to make a proper detection, or that all potential rules matching the connection result in a Drop or Reject action.
<número>
Rule Matching
By default, a service object is matched by port in the first packet of the transport protocol.
Rule Matching by Port
If enabled, provides an additional level of security when the Rule base contains rules including:
an application, URL site, or a service with protocolsignature enabled in the Services & Applications column
a data type in the Content column
Rule Matching by Protocol Signature
1
©2017 Check Point Software Technologies Ltd. 
Rule Matching by Port
By default, a service object is matched by port in the first packet of the transport protocol. When matching by port, the Firewall blade does not consider the actual protocol that runs over the port, although service names and port numbers typically identify services (like HTTP, HTTPS, and FTP) that run over transport protocols (such as TCP and UDP). For example, if the Firewall log indicates that HTTP service was matched on port 80, this means that the first packet contained port 80 in the transport protocol.
Rule Matching by Protocol Signature
For R80.10 and later gateways, more advanced inspection of the protocol for a service is possible if Protocol Signature is enabled for that service. Matching a rule by protocol signature or by service provides an additional level of security when the Rule Base contains rules including:
an application, a URL site, or a service with a protocol signature in the Services & Applications column
a data type in the Content column
Matching by protocol signature and services is discussed in greater detail in the CCSM.
Note: The match by protocol signature feature is disabled by default for R80 and higher gateways. The Firewall cannot match services by protocol signature for R77.30 and lower gateways.	
<número>
When a connection matches rules in more than one layer, the gateway enforces the strictest action and settings.
Rule Matching in the Threat Prevention Policy 
1
©2017 Check Point Software Technologies Ltd. 
Rule Matching in the Threat Prevention Policy
R80.10 and higher Threat Prevention policies may contain multiple Ordered layers in which the Security Gateway installs as one Rule Base. The unified Rule Base determines how all connections are inspected. When a connection matches rules in more than one layer, the gateway enforces the strictest action and settings.
When Threat Emulation and Threat Extraction run in Mail Transfer Agent (MTA) mode, the action of the first rule matched is enforced. Threat Emulation runs in tandem with Threat Extraction for R80.10 and higher gateways. To enable the Threat Extraction Software Blade, the gateway must be established as an MTA.
Threat Prevention solutions are discussed in greater detail in a later chapter.
<número>
 [Internal Use] for Check Point employees​
An infrastructure of services used
Network Address Translation
NAT rules are prioritized according to:
Manual/Pre-Automatic NAT
Automatic Static NAT
Automatic Hide NAT
Post-Automatic/Manual NAT
1
©2017 Check Point Software Technologies Ltd. 
Network Address Translation
Network Address Translation (NAT) and Network Address Port Translation (NAPT) are the two primary technologies traditionally used as methods to hide networks so actual IP addresses are not revealed or required to be publicly routable. This reduces the need for more publicly routable IPs, and allows access to internal (sometimes non-routable) resources from an external network.
How NAT Works
NAT is regarded as an infrastructure of services used, for example, to create clustering solutions, security servers, office mode connections, etc.
Infrastructure		Features	
INSPECT rules and tables 		NAT Rule Base is efficient
Performed on the first packet	Dual NAT (automatic rules)
			Rule priorities	
When NAT is defined on a network object, NAT rules are automatically added to the NAT Rule Base. Those rules are called Automatic NAT rules. NAT is translated during policy installation to tables and performed on the first packet of the connection. The NAT Rule Base is very efficient and can match two NAT rules on the same connection. This is called bi-directional NAT and only applies for Automatic NAT rules.
Note: Even though NAT merges two Automatic NAT rules into one, this feature may be disabled and NAT rules may be manually defined for additional options.	
NAT rules are prioritized according to the list below:
Manual/Pre-Automatic NAT
Automatic Static NAT
Automatic Hide NAT
Post-Automatic/Manual NAT rules
<número>
 [Internal Use] for Check Point employees​
Hide NAT Process
1
©2017 Check Point Software Technologies Ltd. 
Hide NAT Process
Consider first the original packet. When the packet arrives at the Inbound interface, it is inspected by the Security Policy. If accepted, the packet is entered into the Connections table. The first packet of the connection is matched against NAT rules. The packet is translated if a match is found. Then the packet arrives at the TCP/IP stack of the Firewall Module machine and is routed to the Outbound interface.
During the NAT Rule Base traversal, both NAT source and destination are decided. However, they are actually performed at the following locations:
src nat on the server side
dst nat depending on the relevant GUI property
The Reply packet arrives at the Inbound interface of the Firewall machine. The packet is passed by the Security Policy since it is found in the Connections table. The packet's destination, which is the source of the original packet, is translated according to the NAT information. This takes place when the packet was translated in the first initial connection. The packet arrives at the TCP/IP stack of the Firewall machine and is routed to the Outbound interface. The packet goes through the Outbound interface and its source, the destination of the original packet, is translated according to the information in the NAT tables. The packet then leaves the Firewall machine.
<número>
 [Internal Use] for Check Point employees​
There are certain situations when manual NAT rules must be used, such as when:
Rules exist that are restricted to specified destination IP addresses and to specified source IP addresses.
Both source and destination IP addresses translate in the same packet.
Static NAT occurs in only one direction.
Rules exist that only use specified services (ports).
IP addresses translate for dynamic objects.
Manual NAT
1
©2017 Check Point Software Technologies Ltd. 
Manual NAT
Many organizations prefer to define their own NAT rules rather than relying on the system generated rules. There are also certain situations when manual NAT rules must be used, such as when:
Rules exist that are restricted to specified destination IP addresses and to specified source IP addresses.
Both source and destination IP addresses translate in the same packet.
Static NAT occurs in only one direction.
Rules exist that only use specified services (ports).
IP addresses translate for dynamic objects.
<número>
 [Internal Use] for Check Point employees​
Manual NAT
1
©2017 Check Point Software Technologies Ltd. 
The NAT Rule Base is processed one rule at a time from top to bottom, similarly to the Firewall Rule Base. Therefore, Manual NAT rules must be placed in the right order to be applied correctly. Manual NAT rules are added to the NAT Rule Base either above or below any already existing Automatic NAT rules. For example, in the figure below, the first NAT rule was manually created and the other NAT rules were automatically generated based on the NAT settings applied to the respective network objects. The Manual NAT rule is placed at the top of the NAT Rule Base so that it is the first rule to be matched. 
The NAT Rule Base consists of the source, destination, and services information for the original packet and the translated source, destination and services information after NAT has been applied. The processing order for the overall inspection and routing of packets by the Security Gateway is as follows:
Firewall — Inspection on the Original Packet.
NAT — Translate the IP and/or port number as required.
Routing — Forward on the resulting packet.
<número>
 [Internal Use] for Check Point employees​
When configuring Manual NAT in Global Properties, check the Translate destination on client side checkbox.
Manual NAT
1
©2017 Check PointSoftware Technologies Ltd. 
When configuring Manual NAT in Global Properties, check the Translate destination on client side checkbox in the Manual NAT rules section. 
<número>
 [Internal Use] for Check Point employees​
Configure proxy ARPs to associate the translated IP address for Manual NAT rules.
Proxy ARPs allow the gateway to answer ARP queries.
To configure a proxy ARP:
Match the IP of the relevant hosts on the internal network to the MAC of the gateway on the external network.
Create the relevant Manual NAT rules.
Install the policy.
Proxy ARP for Manual NAT
1
©2017 Check Point Software Technologies Ltd. 
Proxy ARP for Manual NAT
For Manual NAT rules, it is necessary to configure proxy ARPs to associate the translated IP address. A proxy ARP allows the Security Gateway to answer ARP queries for a network address that is located on that same network. The ARP proxy is aware of the location of the traffic’s destination, offering its own MAC address as the destination. When the data is received from the external network, the Security Gateway forwards the data to the relevant host on the internal network. 
The configuration of proxy ARPs is necessary for situations such as when a manual Static NAT rule has been created and the Security Gateway does not answer the ARP requests for the Static NAT’d IP address in the Manual NAT rule. Another situation would be when a Security Gateway replies to ARP requests with an incorrect MAC address, mostly for the NAT traffic.
 To configure a proxy ARP:
Match the IP addresses of the relevant hosts on the internal network to the MAC address of the Security Gateway on the external network. This is saved in the $FWDIR/conf/local.arp file.
Create the relevant Manual NAT rules.
Install the Security Policy.
<número>
 [Internal Use] for Check Point employees​
The main sub-grouping of configuration files are divided into the following directories located under /opt:
CPsuite-R80
CPshrd-R80
CPEdgecmp-R80
/lib and /conf directories store definition files.
To view and edit database files use:
dbedit
GuiDBedit.exe
Firewall Administration
1
©2017 Check Point Software Technologies Ltd. 
Firewall Administration
In addition to understanding the Firewall kernel structure, it is important to familiarize yourself with configuration file structure and commands typically used for troubleshooting problems. To begin with, lets consider how the Firewall configuration files are broken down. The main sub-grouping of configuration files are divided into directories located under /opt. 
CPsuite-R80 — Manages Firewall modules (R75.20 - R80). CPsuite is the generic installation. 
CPshrd-R80 — Stores what used to be called SVN foundation, including cpd database, licenses, registry and generic low level Check Point infrastructure. (not version related).
CPEdgecmp-R80 — Manages Edge devices.
The /lib and /conf directories store definition files that are important to take into consideration. For instance, the $FWDIR/lib/*.def files include Rule Base and protocol definitions. User definitions are stored in $FWDIR/conf/fwauth.NDB and Security server configuration settings are stored in $FWDIR/conf/fwauthd.conf.
$FWDIR/conf/classes.C defines fields for each object used in the objects_5_0.C file, such as color, num/string and default value. Though the $FWDIR/database/ directory on the Management server has no relevancy, this directory is particularly noteworthy on the gateway itself, where specific object entries are stored for that particular gateway. There are different ways to view and edit database files such as these.
dbedit — A command line utility on the Management server itself.
GuiDBedit.exe — An executable tool on the Windows-based GUI client machine under: 
C:\Program Files (x86)\CheckPoint\SmartConsole\R80\Program.
Note: The objects_5_0.C file is still used for legacy gateways on R77.30 and older. The database for R80.10 is located in PostgreSQL. x86 was added to the path because most computers now run in 64-bit mode.	
<número>
 [Internal Use] for Check Point employees​
cpconfig
cplic print
cpstart
cpstop
Common Commands
1
©2017 Check Point Software Technologies Ltd. 
Common Commands
cpconfig — This command is used to run a command line version of the Check Point Configuration tool and configure or reconfigure a Security Gateway/Management installation.
cplic print — Located in $CPDIR/bin, this command prints details of Check Point licenses on the local machine. cplic print -x prints the licenses with signatures and cplic del <signature> deletes a license.
cpstart — This command is used to start all Check Point processes and applications running on a machine.
cpstop — This command is used to terminate all Check Point processes and applications running on a machine.
The commands cpstop and cpstart are actually calling fwstop and fwstart scripts for all Check Point products, including the Firewall stop/start scripts located in $FWDIR/bin. These are scripts that run when you perform cpstop, cpstart and cprestart with different flags. cprestart is an internal command used for Dynamically Assigned IP (DAIP) devices, such as Edge devices. Not all Check Point processes are brought down when cprestart is used; therefore, cpstop and cpstart should always be used.
<número>
 [Internal Use] for Check Point employees​
A packet analyzer tool essential for packet capture and Firewall traffic analysis.
It provides kernel level inspection.
The general syntax is: 
fw monitor –e “accept <expression>; “ – o <filename>
FW Monitor
1
©2017 Check Point Software Technologies Ltd. 
FW Monitor
The Check Point tool, fw monitor, is a packet analyzer tool which is on every Check Point Security Gateway and is essential for packet capture and Firewall traffic analysis. It provides kernel level inspection; but will not run in indiscriminate mode. fw monitor works for layers 3 and above in the OSI Network layer stack. The syntax is the same regardless of the platform and supports the .pcap output format used in Ethereal and Wireshark packet analyzer tools.
The easiest way to use fw monitor is to invoke it without any parameters. However, in a busy system, running fw monitor without any filters can create a great detail of output and makes the analysis difficult. Filter expressions are used to specify packets to be captured and limit the amount of output. The general syntax is:
fw monitor -e “accept <expression>;” -o <filename>
Filter expressions include:
host [<IP_Address>]
net [<Network_IP_Address>, <Mask_Length>]
port [<IANA_Port_Number>]
Note: Check Point recommends turning SecureXL (fwaccel off) when using fw monitor to avoid misleading traffic captures. If SecureXL is on, the tool will only show non-accelerated packets. SecureXL is discussed in a later chapter.
For example, to capture everything between host X and host Y:
[Expert@HostName]# fw monitor -e “host(x.x.x.x) and host(y.y.y.y), accept;” -o/var/log/fw_mon.cap
For more fw monitor capture examples, refer to sk30583.
	
<número>
 [Internal Use] for Check Point employees​
C2S Connections and S2C Packets
Inspection Points:
i — Before the virtual machine, in the Inbound direction (pre-Inbound)
I — After the virtual machine, in the Inbound direction (post-Inbound)
o — Before the virtual machine, in the Outbound direction (pre-Outbound)
O — After the virtual machine, in the Outbound direction (post-Outbound)
1
©2017 Check Point Software Technologies Ltd. 
C2S Connections and S2C Packets
fw monitor captures packets as they enter and leave the Firewall kernel and when the packet enters and leaves the Inbound and Outbound chains. In the case of Client-to-Server (C2S) communication, a client designated as Host1, according to the policy, sends traffic destined for a web server located behind the Firewall. Since the traffic is permitted passage through the Firewall based on the policy Rule Base, the packet must traverse and be inspected by both chains of the Firewall.
The command fw monitor worksby loading a special filter that is applied to suspicious packets. This filter is different from the INSPECT filter used to implement a Rule Base. Where the Rule Base determines which packet is accepted, rejected or dropped, the INSPECT filter generated by fw monitor simply captures kernel packet flows. You can capture everything through the kernel using fw monitor, even a particular type of traffic or source.
Once fw monitor is executed, the specified INSPECT filter is compiled and loaded to the kernel. Any parameters following accept in the fw monitor command will be displayed by fw monitor. The same filter is executed on all interfaces in all directions. The fw monitor output uses specific expressions to explain the location of the packet as it moves through the Firewall. 
There are four inspection points as a packet passes through the kernel:
i — Before the virtual machine, in the Inbound direction (pre-Inbound)
I — After the virtual machine, in the Inbound direction (post-Inbound)
o — Before the virtual machine, in the Outbound direction (pre-Outbound)
O — After the virtual machine, in the Outbound direction (post-Outbound)
In our C2S scenario, i represents the packet as it left the client. The I represents the packet already checked against the tables and Rule Base. In case of Static NAT, the destination IP address will be changed. The o means the packet is before the Outbound kernel (same as I) and O means the packet is in the Outbound kernel chain, as it will appear at the web server. In the case of Hide NAT, the source IP address will be different here.
For packets traveling from Server-to-Client (S2C), the inspection points are the reverse. I could be the NAT’d packet on its way out of the Inbound chain in the Firewall in the case of Static NAT. At this point, the packet has already been checked by the tables and Rule Base. The O is the packet as it will appear to the client.
<número>
 [Internal Use] for Check Point employees​
Complete the tasks necessary to perform Manual Network Address Translation.
Create the ARP entries necessary for Manual NAT.
Lab 1.6: Configuring Manual NAT
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
Chapter 1 Review Questions
What is CPUSE and what is it used for?
CPUSE is Check Point’s Update Service Engine. It is used to support the deployment of single hotfixes, hotfix accumulators, and major version upgrades.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 1 Review Questions
Name at least three Stateful features provided with the Connections table.
Streaming based applications, such as Web security
Sequence verification and translation
Hide NAT
Logging, accounting, and monitoring
Client and server identification
Data connections
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Automation & orchestration
02
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Recognize how Check Point’s flexible API architecture supports automation and orchestration of daily operations.
Understand how to use the management API command line tools and web services to read information, create objects, work on Security Policies, and send commands to the Check Point Security Management Server.
Automation & Orchestration
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Trusted Application Programming Interfaces (APIs) enable enterprises using network or orchestration systems to securely integrate a security management solution that has automation capabilities into their workflow processes. The Check Point API makes it easy to integrate securely with orchestration, change management and ticketing systems. With the ability to control exactly what that integration can and cannot do, organizations have the confidence to embed security into their IT ecosystem.
<número>
The process of automating tasks normally performed by human intervention to be performed by a machine.
Automation
 [Internal Use] for Check Point employees​
The choreography of automating the arrangement, coordination, and management of processes performed into a logical workflow.
Orchestration
Codifying tasks
Codifying processes
1
©2017 Check Point Software Technologies Ltd. 
Automation is the process of automating tasks normally performed by human intervention to be performed by a machine as a means to providing efficiency and minimizing human error. Orchestration is the choreography of automating the arrangement, coordination and management of processes performed within complex computer systems and services into a logical workflow. It reduces the time and effort for deploying multiple instances of a single task by automatically performing a series of tasks which previously could only be performed by multiple administrators.
How Automation and Orchestration Differ 
Automation and Orchestration differ in that automation relates to codifying tasks whereas orchestration relates to codifying processes. Automation is concerned with executing a single task, such as launching a web server or stopping a service, in a repeatable, consistent manner. Orchestration takes a series of automated tasks developed through automation and puts them all together into a process workflow which can simplify the complex management of today’s network security infrastructures. For example, an organization may use a cloud orchestrator programming to manage the interconnections and interactions among their cloud-based and on-site business units. Orchestration also involves the process of coordinating an exchange of information through web service interactions, such as XML and JSON.
<número>
 [Internal Use] for Check Point employees​
Check Point APIs
Improve productivity
Efficiency
Execute an automated script to perform common tasks.
Integrate Check Point products with 3rd party solutions.
Create products that use and enhance the Check Point solution.
1
©2017 Check Point Software Technologies Ltd. 
Check Point APIs
Check Point’s R80.10 Security Management platform provides the framework to support both Automation and Orchestration through its flexible API architecture. An API is a set of routines, protocols, and tools for building software applications. Check Point provides a complete CLI and API interface for security management which will enable the automation of daily operations and full integration with 3rd party and other systems, such as network management systems, ticketing systems, virtualization servers, and cloud orchestrators. 
Automation and SmartConsole management operations are allowed based on the same privilege profile. 
Check Point APIs allow system engineers and developers to make changes to their organization’s Security Policy with CLI tools and Web Services. An API can be used to:
Execute an automated script to perform common tasks.
Integrate Check Point products with 3rd party solutions.
Create products that use and enhance the Check Point solution.
<número>
 [Internal Use] for Check Point employees​
Management API – used to read information, create objects, work on policies, and send commands to the Security Management Server.
Threat Prevention API – used to control Threat Emulation, Antivirus, and Threat Extraction products.
Identity Awareness Web Services API – used to add, remove, and show the status of identity parameters.
OPSEC SDK – used to open and monitor connections between the Security Management Server and gateways, and other hosts and objects.
APIs for Check Point Products
1
©2017 Check Point Software Technologies Ltd. 
There are different APIs for various Check Point products:
Management API — Used to read information, create objects, work on Security Policies and send commands to the Check Point Security Management Server. The Management API has a JSON/XML web servicesoption, a Gaia CLI from the R80.10 SmartConsole, the new mgmt_cli tool, and the Gaia Clish.
Threat Prevention API — A cloud-based service used to control Threat Emulation, Antivirus, and Threat Extraction products. See https://sch.checkpoint.com/documents/TPAPI/v1/html.frameset.htm.
Identity Awareness Web Services API — A web services API used to add, remove, and show the status of identity parameters. For example, using the API, a new user can be added to an Access Role or a user can be allowed to connect to the internal network from a different IP address.
OPSEC SDK — These APIs are used to open and monitor connections between the Security Management Server and gateways, and other hosts and objects.
During this course, we will focus solely on the Management API. 
Note: OPSEC SDK contains APIs for commands that were originally used with SecurePlatform. These commands can also be used on the Gaia operating system.	
<número>
 [Internal Use] for Check Point employees​
Check Point API Architecture
1
©2017 Check Point Software Technologies Ltd. 
Check Point API Architecture
The Check Point API Architecture consists of the API server and API interaction mechanisms. The API server communicates with CPM in the same way as SmartConsole. An API automated session will generate audit logs and will display the validation errors and warnings. The API architecture also supports Concurrent Administration. The same permission profiles that control the GUI are enforced when using an automation session.
 The API server uses JavaScript Object Notation (JSON) for data interchanges. JSON is a lightweight data-interchanging format which is easy for individuals to read and write, and for machines to parse and generate. Interaction mechanisms are command sources, such as Web Services and Management CLIs. All API clients use the same port as the Gaia Portal. 
<número>
 [Internal Use] for Check Point employees​
SmartConsole
mgmt_cli
Gaia CLI
 
Command Sources
1
©2017 Check Point Software Technologies Ltd. 
Command Sources
Command sources allow you to communicate with the API server and perform many tasks using management APIs.
The SmartConsole GUI console — From SmartConsole, click the button to open a CLI window and enter API commands. For example, you can use the add host command to create a new host and then publish the changes. 
The mgmt_cli Tool — Runs in Expert mode and lets you enter commands from a Windows or Linux computer. mgmt_cli uses the same authentication (username and password) as the GUI client; however, it does not require a GUI installation.
Gaia CLI — Log in to Gaia with an administrator account on the Security Management Server and enter API commands using Clish.
Web Services — Send HTTPS Post requests to the Security Management Server.
<número>
 [Internal Use] for Check Point employees​
Allow systems to use web services to access, manipulate, delete, change, and add resources.
Use GET, PUT, POST, and DELETE.
RESTful API
To call the login:
HTTP POST https://<mgmt>/web_api/login
Content-Type: application/json
1
©2017 Check Point Software Technologies Ltd. 
RESTful API
RESTful APIs allow systems to use web services to access, manipulate, delete, change, and add resources. They use standard HTTP methods sent by script to GET, PUT, POST, and DELETE data. The management API uses RESTful API to send calls using the POST method. An example of using a RESTful API to call the login would be:
HTTP POST https://<mgmt>/web_api/login
Content-Type: application/json
The content type Header tells the client how to compose requests in the body to the server.
<número>
 [Internal Use] for Check Point employees​
Operational Flow
1
©2017 Check Point Software Technologies Ltd. 
The chart diagrams the operational flow of an API session.
<número>
 [Internal Use] for Check Point employees​
API Server Configuration
1
©2017 Check Point Software Technologies Ltd. 
API Server Configuration
The management API server is part of the R80.10 management server installation. To manage security through API and CLI, you must first configure the API server. 
The API server runs scripts that automate daily tasks on the Security Management Server. It also integrates Check Point products with third party systems. To configure the API server, in SmartConsole, go to Manage & Settings > Blade. In the Management API section, click Advanced Settings and the Management API Settings window will open. Configure the Startup Settings and the Access Settings.
Startup Settings start the API server when the Security Management Server starts. The Automatic start setting is selected by default in the following environments:
Security Management Servers (without gateway functionality) with at least 4GB of RAM
Standalone Security Management Servers (with gateway functionality) with at least 8GB of RAM
Note: Verify your installation requirements prior to configuring the API server.
Access Settings configure IP addresses from which the API server accepts requests. The Management server only option is selected by default. This option instructs the API server to accept scripts and web requests only from the Security Management Server. To send an API request, open a command line interface on the server and use the mgmt_cli utility.
To verify that the API server is running, run the following command in Expert mode:
api status
To start the API server, run the following command in Expert mode:
api start
To stop the API server, run the following command in Expert mode:
api stop
	
<número>
 [Internal Use] for Check Point employees​
Basic API commands include:
login
add
set
show
delete
publish
discard
logout
Management API Commands
In the GUI, scripting begins with a login dialog to receive a session token. A login command creates a session.
Username and password parameters are always required.
1
©2017 Check Point Software Technologies Ltd. 
Using Management API Commands
 To type API commands from the SmartConsole GUI, click the command line interface button located in the bottom left corner to open the Command Line interface window. 
Basic API Commands include:
login
add
set
show
delete
publish
discard
logout
In the GUI, scripting begins with a login dialog to receive a session token. A login command creates a session. User name and password parameters are always required. Here is the syntax for a login script:
login user <username> password <password> --format json
<número>
 [Internal Use] for Check Point employees​
sid string – represents the session unique identifier.
url parameter – identifies the URL used to reach the API server.
uid string – is the session object identifier.
Create scripts for:
Network Objects
Services and Applications
Policy
Access Control and NAT
VPN
Management API Commands
Login user <username> password <password> -- format json
Output:
{
 “sid” : “97BVpRfN4j8logN-V2XqGYMW3DDwIhoSN0Og8PiKDiM”,
 “url” : “https://192.0.2.1:443/web_api”,
 “uid” : “7a13a360-9b24-40d7-acd3-5b50247be33e”,
			 “session-timeout” : 600,
 “last-login-was-at” : {
 “posix” : 1430032266851,
 “iso-8601” : “2015-04-26T10:11+0300”
 }
}
1
©2017 Check Point Software Technologies Ltd. 
{
 “sid” : “97BVpRfN4j8logN-V2XqGYMW3DDwIhoSN0Og8PiKDiM”,
 “url” : “https://192.0.2.1:443/web_api”,
 “uid” : “7a13a360-9b24-40d7-acd3-5b50247be33e”,
			 “session-timeout” : 600,
 “last-login-was-at” : {
 “posix” : 1430032266851,
 “iso-8601” : “2015-04-26T10:11+0300”
 }
}
Note: “--format json” is optional.	
The sid string represents the session unique identifier. This identifier is entered in the ‘X-chkp-sid’ header of each request. The url parameter identifies the URL which was used to reach the API server. The uid string is the session object identifier. It may be used in discard API to discard changes that were made in the session, when the administrator is working from another session.
API commands can be used to create scripts for key security management components, including:
Network Objects — Hosts, Networks, Groups,Access Roles
Services and Applications — Service TCP, Service UDP, Application
Policy — Install policy, policy package management
Access Control and NAT — Access rules, NAT rules
VPN — VPN Community Meshed, VPN Community Star
For example, to create a new host, use the following command:
add host name <New Host Name> ip-address <ip address>
<número>
 [Internal Use] for Check Point employees​
To run a command, provide login credentials or use session-id token.
Arguments are transformed to RESTful API calls.
Run on any Linux or Windows machine.
The mgmt_cli_.exe does not require a GUI installation.
Users logged in as Root can run mgmt_cli commands without providing credentials.
All mgmt_cli commands can use CSV files for automation.
The mgmt_cli Tool
mgmt_cli login user “AdminUser1” password “teabag” > id.txt
mgmt_cli add host name “New_Host_1” ip-address “1.1.1.1 -s id.txt
mgmt_cli publish -s id.txt
mgmt_cli logout -s id.txt
1
©2017 Check Point Software Technologies Ltd. 
The mgmt_cli Tool
The mgmt_cli tool uses the same syntax that is used inside the SmartConsole GUI. The only difference is that when using the tool, for a command to run, you must to provide login credentials or use a session-id token that was obtained previously using the login command. The mgmt_cli tool transforms the arguments it receives to RESTful API calls.
The mgmt_cli tool can be run on any Linux or Windows machine. A Linux version of the command line tool is included in all R80.10 Gaia installations. The executable mgmt_cli is included in the R80.10 SmartConsole installation. The mgmt_cli.exe does not require a GUI installation. It can be copied to run on most Windows-based computers.
The following API script example uses the mgmt_cli tool to log in and create a new host:
mgmt_cli login user “AdminUser1” password “teabag” > id.txt
mgmt_cli add host name “New_Host_1” ip-address “1.1.1.1 -s id.txt
mgmt_cli publish -s id.txt
mgmt_cli logout -s id.txt
In the example above, the output from the login command is redirected to a file called id.txt. By using the -s parameter, the rest of the commands read id.txt and automatically extract the session-id from this file.
Users logged in to a management server as Root, can run mgmt_cli commands without providing their credentials. These are users with Super Administrator permissions. To use this option, add --root true to the end of the mgmt_cli command.
All mgmt_cli commands can use CSV files for automation purposes as well. For example, the following command can be used to create multiple host objects from a Microsoft Excel spreadsheet: # mgmt_cli add host --batch hosts1.csv 
<número>
 [Internal Use] for Check Point employees​
Using Management API Commands
Gaia CLI
Log in as admin user.
All management commands begin with the mgmt command.
Example: mgmt add host
Web Services
HTTP Post to
HTTP Headers
Request payload
1
©2017 Check Point Software Technologies Ltd. 
Gaia CLI (Clish)
To run management API commands in Gaia’s shell, you must first log in as a administration user. The syntax is identical to the commands that you run in the SmartConsole GUI; however, all management commands begin with the mgmt command. For example: mgmt add host.
Web Services
Using Web Services to build an application that communicates with the Check Point management server requires the following components for the web request:
HTTP Post to — Identifies the management server and port. The default port is 443.
HTTP Headers — Consists of the content-type, such as application/json, and the x-chkp-sid header. The x-chkp-sid is the session ID token and is mandatory in all API calls, except login.
Request payload — Text containing the different parameters in the specified format (json or xml).
<número>
 [Internal Use] for Check Point employees​
Management API Support
1
©2017 Check Point Software Technologies Ltd. 
Management API Support
Check Point Management API utilizes the full potential of the R80.xx Security Management Server and can be used within any programming environment. To assist you in building automation tools for your organization, Check Point recommends the following reference tools.
The Management API Reference Guide
This online guide provides an introduction to Check Point Management API. The guide may be accessed via the Check Point User Center and the management server (/api_docs).
<número>
 [Internal Use] for Check Point employees​
Management API Support
1
©2017 Check Point Software Technologies Ltd. 
The Check Point CheckMates Community
Join the Check Point CheckMates community to browse the latest scripts built by experts in the field, get code samples, network with developers, and access additional API documentation. A direct link to Check Point CheckMates is located on the Check Point website, or enter this URL into your browser: https://community.checkpoint.com/
<número>
Chapter 2 Review Questions
What are the four command sources which allow you to communicate with the management server using management API?
SmartConsole
The mgmt_cli tool
Gaia CLI
Web Services
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 2 Review Questions
What does the sid command string identify?
The sid command string identifies the session unique identifier.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Demonstrate how to define new network and group objects using the Check Point API.
Demonstrate how to modify existing objects using the Check Point API.
Lab 2.1: Managing Objects Using the Check Point API
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
Redundancy
03
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Discuss advanced ClusterXL functions and redundancy.
Describe VRRP network redundancy and its advantages.
Redundancy
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Security Gateways can be configured to provide redundancy to prevent network down-time. The failure of a Security Gateway or VPN connection can result in the loss of active connections, many of which can be mission critical and result in the loss of critical data. Whether your preferred network redundancy protocol is Check Point ClusterXL technology or standard Virtual Routing Redundancy Protocol (VRRP), it is no longer a platform choice you will have to make with Gaia. Both ClusterXL and VRRP are fully supported by Gaia. The concept of clustering was introduced in the CCSA course. During this chapter we will explore clustering in greater detail. 
<número>
 [Internal Use] for Check Point employees​
Configure for Load Sharing or High Availability.
Provides in-depth operational and monitoring capabilities using cphaprob commands.
Advantages include:
Tight integration with Check Point management and enforcement points
Transparent failover
Higher performance
Easy deployment
Cost-effective
Advanced ClusterXL
1
©2017 Check Point Software Technologies Ltd. 
Advanced ClusterXL
ClusterXL supplies an infrastructure that ensures no data is lost in event of a system failure. This Check Point cluster solution uses unique physical IP and MAC addresses for its cluster members and virtual IP addresses to represent the cluster itself. The virtual IP addresses do not belong to an actual machine interface, and it is recommended that each cluster member have at least three interfaces: one external interface, one internal interface, and one for synchronization. 
ClusterXL is part of the standard Security Gateway installation and can be configured for Load Sharing or High Availability mode. 
Advantages of Using ClusterXL
Both ClusterXL and VRRP are fully supported by Gaia and available to all Check Point appliances, open servers and virtualized environments.While both platforms provide the ability to monitor the state of their clusters, ClusterXL provides more in-depth operational and monitoring capabilities. For example, when using ClusterXL, System Administrators know when their cluster has failed over and can also see why it failed over by using the cphaprob list command. In addition, if an interface goes down, System Administrators can determine if it is fully down or partially down by using the cphaprob -a if command. They can see which firewall is currently active, or in the case of Load Sharing, which gateway is carrying the load and the percentage of the load carried using the cphaprob stat command. Advantages of using ClusterXL include:
Tight integration with Check Point management and enforcement points
Transparent failover
Higher performance
Easy deployment
Cost-effective
<número>
 [Internal Use] for Check Point employees​
All functioning members are active and handle network traffic.
If any member of a cluster becomes unreachable, transparent failover occurs to the remaining members.
Requires all machines to be synchronized.
Offers two different solutions: Multicast mode and Unicast mode
Load Sharing
1
©2017 Check Point Software Technologies Ltd. 
Load Sharing
ClusterXL Load Sharing distributes traffic within a cluster so that the total throughput of multiple members is increased. In Load Sharing clusters, all functioning members are active and handle network traffic. This is referred to as an Active/Active configuration. Load Sharing clusters increase linear performance for CPU-intensive applications such as VPNs, security servers, policy servers, and User Directory (LDAP).
With Load Sharing, if any member of a cluster becomes unreachable, transparent failover occurs to the remaining operational members in the cluster, thus providing High Availability. All connections are shared between the remaining Security Gateway, without interruption.
ClusterXL Load Sharing configurations require all machines to be synchronized, which differs from High Availability. Machines in a ClusterXL High Availability configuration do not have to be synchronized, however connections will be lost upon failover if they are not.
 
ClusterXL offers two different Load Sharing solutions: Multicast and Unicast. These modes differ in the way members receive the packets sent to the cluster.
<número>
 [Internal Use] for Check Point employees​
Every member receives all packets sent to the cluster IP address.
A decision algorithm decides which member should perform enforcement processing on the packet.
Only that member processes the packet and sends it to its destination.
The other machines drop the packet.
No two members handle the same packets, so traffic is not duplicated.
Multicast Load Sharing
1
©2017 Check Point Software Technologies Ltd. 
Multicast Load Sharing
In ClusterXL Multicast Load Sharing mode, every member of the cluster receives all of the packets sent to the cluster IP address. The Multicast mechanism allows several interfaces to be associated with a single Multicast MAC address. Therefore, when a router or Layer 3 switch forwards packets to all of the cluster members using Multicast mode, a ClusterXL decision algorithm on the cluster members decides which cluster member should perform enforcement processing on the packet. Only that machine processes the packet and sends the packet to its destination. The other machines drop the packet. This decision-making process is the core of the Multicast Load Sharing mechanism. It has to ensure that at least one member will process each packet so that the traffic is not blocked, and no two members will handle the same packets, so that traffic is not duplicated. Only routers or Layer 3 switches that accept a Multicast MAC address as a response to an ARP request with a Unicast IP address are supported for Multicast Load Sharing.
<número>
 [Internal Use] for Check Point employees​
One machine (the Pivot) receives all traffic from a router with a Unicast configuration and redistributes the packets to the other machines.
The Pivot is the only machine that communicates with the router.
The Pivot’s load sharing decision function decides which member should handle the packet.
The Pivot can decide to handle the packet itself.
The Pivot is always the active member with the highest priority.
Unicast Load Sharing
1
©2017 Check Point Software Technologies Ltd. 
Unicast Load Sharing
In ClusterXL Load Sharing Unicast mode, one machine, called the Pivot machine, receives all traffic from a router with a Unicast configuration and redistributes the packets to the other machines in the cluster. The Pivot machine is chosen automatically by ClusterXL.
The Pivot is the only machine that communicates with the router. In this scheme, the router uses the Pivot’s Unicast MAC address to communicate to the cluster. The Pivot functions as a cluster router, both from the internal network outwards and vice versa. This functionality also applies to DMZ networks. 
After the Pivot first receives the packet from the router or switch, the Pivot’s Load Sharing decision function decides which cluster member should handle the packet. This decision function is made in a similar fashion to the Multicast Load Sharing decision. The Pivot may also decide to handle the packet itself. In such a case, Pivot Load Sharing will give the packet to the Pivot’s Firewall component for processing. If the Pivot encounters a problem, a regular failover event occurs and another cluster member assumes the role of the new Pivot. The Pivot member is always the active member with the highest priority. Therefore, when the original pivot recovers, it will resume its previous role. The non-pivot members are also active, but do not make decisions.
Because the Pivot is busy distributing traffic, the Pivot participates to a lesser extent in the actual Load Sharing function. The other cluster members take on more traffic load. Since the Check Point Pivot feature is based on Unicast addresses only, it can work with all routers and Layer 3 switches.
<número>
 [Internal Use] for Check Point employees​
Unicast Load Sharing
When the router sends a packet through the cluster, the following occurs:
The router sends an ARP request for the cluster IP address.
The Pivot returns an ARP reply with its own Unicast MAC address, to the router.
The router sends the packet to the Pivot. The Pivot decides which cluster member should handle the packet.
The Pivot forwards the packet to the designated cluster member without changing the packet. 
The receiving cluster member performs inspection and sends the packet to its destination. 
The return packet first reaches the Pivot. The return packet then goes through the same process although it may not necessarily be forwarded by the Pivot to the same cluster member.
The Pivot assigns the cluster member to handle the packet. 
The receiving cluster member performs inspection and sends the packet to its destination.
1
©2017 Check Point Software Technologies Ltd. 
The following diagram and steps outline how a packet travels through a Unicast Load Sharing cluster.
When the router sends a packet through the cluster, the following occurs:
The router sends an ARP request for the cluster IP address.
The Pivot returns an ARP reply with its own Unicast MAC address, to the router.
The router sends the packet to the Pivot. The Pivot decides which cluster member should handle the packet.
The Pivot forwards the packet to the designated cluster member without changing the packet. The destination IP address of the packet remains unchanged and neither decryption nor NAT functionality is performed on the forwarded packet. When sending the packet, the Pivot uses the virtual MAC address of the designated cluster member. The packet is forwarded through the original interface.
The receiving cluster member performs inspection and sends the packet to its destination. 
The return packet first reaches the Pivot. The return packet then goes through the sameprocess although it may not necessarily be forwarded by the Pivot to the same cluster member.
The Pivot assigns the cluster member to handle the packet. 
The receiving cluster member performs inspection and sends the packet to its destination.
<número>
 [Internal Use] for Check Point employees​
Address Resolution Protocol (ARP) is used to map an IP address to a MAC address.
ARP cache tables maintain a correlation between each MAC address and its corresponding IP address.
Proxy ARP enables a host or router to reply to ARP requests.
Proxy ARP recognizes the destination of the traffic and provides its MAC address as the final destination.
Proxy ARP
1
©2017 Check Point Software Technologies Ltd. 
Proxy ARP
Address Resolution Protocol (ARP) is a communications protocol used to map an IP address to a physical machine address (MAC address) that is recognized by the local network. When a packet arrives at a gateway, the gateway will ask ARP to find a physical host or MAC address. ARP will try to locate the address and provide it so that the packet can be converted and sent to the host machine. An ARP cache table is used to maintain a correlation between each MAC address and its corresponding IP address. If ARP does not find an entry for the IP address, it will broadcast a request packet for the MAC address. 
By design, in ClusterXL High Availability mode or Load Sharing Unicast/Multicast mode, Gratuitous ARP request packets for specified hosts, will be sent with the Source IP addresses of the specified hosts. These requests update the ARP cache tables and do not expect a reply. Cluster synchronization does not rely on ARP.
Proxy ARP enables a host or router to reply to any ARP requests with its own MAC address. In many cases the network will configure a gateway to act in proxy as the host. The gateway will accept the ARP requests and reply with its own MAC address. The Proxy ARP recognizes the destination of the network traffic and provides its MAC address as the final destination. The traffic is then routed to the intended destination using another interface or via tunnel. Proxy ARP is also useful for environments that have NAT’d Firewalls.
<número>
 [Internal Use] for Check Point employees​
Proxy ARP must be configured manually if using VMAC mode or different subnets for the cluster IP.
Configuration for Proxy ARP entails:
Configuring Layer 2 to Layer 3 matching on each cluster member.
Creating Manual NAT rules. The policy must be installed.
Proxy ARP
1
©2017 Check Point Software Technologies Ltd. 
When using static NAT, a cluster can be configured to automatically recognize the hosts hidden behind it and issue ARP replies with the cluster MAC address, on their behalf. This process is referred to as Automatic Proxy ARP. If using ClusterXL VMAC mode or different subnets for the cluster IP, the Proxy ARP must be configured manually. 
Configuration for Proxy ARP entails:
Configuring Data Link layer to Network layer matching on each cluster member, thus matching the IP addresses of the relevant hosts on the network where they are located to the MAC address of the Security Gateway on the network where the IP addresses of these hosts should be published.
Creating relevant Manual NAT rules. The policy must be installed. 
Proxy ARP can create denial-of-service (DoS) attacks on a network if mis-configured.
<número>
 [Internal Use] for Check Point employees​
A variation of HA and Load Sharing Unicast mode.
Configuring the cluster to use VMAC mode allows all members to use the same virtual MAC address and minimizes possible traffic outages during failover.
VMAC advertised by members through G-ARP requests, keeps the real MAC address of each member and adds another VMAC address on top of it.
VMAC failover time is shorter than failovers that involve a physical MAC address.
VMAC
1
©2017 Check Point Software Technologies Ltd. 
VMAC
Cluster Virtual MAC (VMAC) is a variation of the High Availability (HA) and Load Sharing Unicast mode for ClusterXL. Upon failover in High Availability/Load Sharing Unicast mode, a new Active/Pivot member will send Gratuitous-ARP requests (G-ARPs) for the virtual IP with the physical MAC address of the new Active/Pivot. When this occurs, a member with a large number of Static NAT entries can transmit too many G-ARPs and network components may start to ignore them or refrain from updating them fast enough in their ARP cache table. As a result, traffic outages may occur. Configuring the cluster to use VMAC mode allows all cluster members to use the same Virtual MAC address and minimizes possible traffic outages during a failover. In addition, G-ARPs for NAT’d IP addresses are no longer needed. 
VMAC that is advertised by the cluster members through G-ARP requests, keeps the real MAC address of each member and adds another VMAC address on top of it. Keeping the real MAC address of each member is necessary in that connectivity to the IP address of the member itself is required. VMAC failover time is shorter than a failover that involves a physical MAC address.
<número>
 [Internal Use] for Check Point employees​
Configuring VMAC
Via SmartConsole:
Select the cluster object and navigate to Gateway Cluster Properties.
Select ClusterXL and VRRP.
Enable Use Virtual MAC option.
Via Command Line:
Set the value of the global kernel parameter to 1.
Ensure that VMAC mode is enabled on all members. Run this command:
fw ctl get int fwha_vmac_global_param_enabled
1
©2017 Check Point Software Technologies Ltd. 
Configuring VMAC
VMAC can be configured via SmartConsole or CLI. To configure VMAC via SmartConsole, select the cluster object and navigate to the Gateway Cluster Properties window. Select the ClusterXL and VRRP menu option, and then enable the Use Virtual MAC option located under the Advanced Settings section.
To configure VMAC using the command line, you must first set the value of the global kernel parameter, fwha_vmac_global_param_enabled to 1. (The default value is 0. The default value means that VMAC is disabled). 
To ensure that VMAC mode is enabled, run the following command on all members:
fw ctl get int fwha_vmac_global_param_enabled
If the value returned is 1, the feature is enabled. If not enabled, use the following command:
fw ctl set int fwha_vmac_global_param_enabled
To view the VMAC address of each virtual cluster interface, run the following command:
cphaprob -a if
<número>
 [Internal Use] for Check Point employees​
State synchronization allows status information about connections to be shared between members.
To secure synchronization interfaces:
Use a dedicated synchronization network.
Connect the physical network interface directly using a cross-cable. In clusters with 3 or more members, use a dedicated hub or switch.
State synchronization modes:
Full Synchronization
Delta Synchronization
To monitor synchronization, run: fw ctl pstat
Cluster Synchronization
1
©2017 Check Point Software Technologies Ltd. 
Cluster Synchronization
To make sure each Gateway cluster member is aware of the connections going through the other members, a mechanism called State Synchronization exists, which allows status information about connections on the Security Gateways to be shared between the members.
State Synchronization enables all machines in the cluster to be aware of the connections passing through each of the other machines. It ensures that if there is a failure in a cluster member, connections that were handled by the failed machine will be maintained by the other machines. Since the synchronization network carries the most sensitive Security Policy information in the organization, it is critical that system engineers protect it against malicious and unintentional threats. Check Point recommends using one of the following strategies to secure the synchronization interfaces:
Use a dedicated synchronization network.
Connect the physical network interfaces of the cluster members directly using a cross-cable. In a cluster with three or more members, use adedicated hub or switch.
Every IP-based service, including TCP and UDP, recognized by the Security Gateway is synchronized. State Synchronization is used both by ClusterXL and by third-party OPSEC Certified clustering products. State Synchronization works in the following two modes:
Full Synchronization — Transfers all Firewall kernel table information from one cluster member to another. Full synchronization is used for initial transfers of state information for thousands of connections. If a cluster member is brought up after failing, it will perform full sync. Once all members are synchronized, only updates are transferred via delta sync. Full synchronization between cluster members is handled by the Firewall kernel using TCP port 256.
Delta Synchronization — Transfers changes in the kernel tables between cluster members. Delta sync is much quicker than full sync. It is handled by the Firewall kernel, using UDP Multicast or Broadcast on port 8116.
Running cphastart on a cluster member activates ClusterXL on the member is the recommended way to start a cluster member. It does not initiate full synchronization. cphamcset turns off the cluster process. State Synchronization also stops. It is still possible to open connections directly to the cluster member. These commands should only be run by the Security Gateway, not directly by the user.
To monitor the synchronization mechanism on ClusterXL or third-party OPSEC Certified clustering products, run the following command:
fw ctl pstat
<número>
 [Internal Use] for Check Point employees​
Only cluster members running on the same platform can be synchronized.
Cluster members must be of the same software version.
With CoreXL enabled, the number of cores must be the same.
A user-authenticated connection through a cluster member will be lost if the cluster member fails. 
The state of connections using system resources cannot be synchronized for the same reason that user-authenticated connections cannot be synchronized.
In case of a failover, accounting information that was accumulated on the failed member but not yet reported to the Security Management Server is lost. 
Synchronization Cluster Restrictions
1
©2017 Check Point Software Technologies Ltd. 
The following restrictions apply to synchronizing cluster members:
Only cluster members running on the same platform can be synchronized.
The cluster members must be of the same software version.
With CoreXL enabled, the number of cores must be the same.
A user-authenticated connection through a cluster member will be lost if the cluster member fails. This is because the user-authentication state is maintained by a process on the Security Gateway and it cannot be synchronized on members the same way that kernel data is synchronized. All other synchronized cluster members will be unable to resume the connection. However, a client-authenticated or session-authenticated connection will be maintained, because the states of these authentications are saved in kernel tables and can be synchronized.
The state of connections using system resources cannot be synchronized for the same reason that user-authenticated connections cannot be synchronized.
Accounting information is accumulated on each cluster member and sent to the Security Management Server, where the information is aggregated. In case of a failover, accounting information that was accumulated on the failed member but not yet reported to the Security Management Server is lost. To minimize the risk, reduce the period in which accounting information is sent. Navigate to the cluster object’s Logs > Additional Logging window, and edit the number of seconds to update the Account Log. 
<número>
 [Internal Use] for Check Point employees​
System engineers may choose not to synchronize certain types of connections for reasons, such as:
A significant load on the network is caused by the use of a particular service.
A service may open many short connections, whose loss may not be very important, or even noticed. For example, DNS over UDP or HTTP.
Bi-directional stickiness is employed for all connections. For example, any cluster in High Availability mode or ClusterXL in a Load Sharing mode with no VPN or static NAT. Sticky connections are discussed later in this chapter.
To Synchronize or Not to Synchronize
1
©2017 Check Point Software Technologies Ltd. 
To Synchronize or Not to Synchronize
In general, all connections on a cluster are synchronized between members. There are a few exceptions. System engineers may choose not to synchronize certain types of connections for a variety of reasons, such as:
A significant load on the network is caused by the use of a particular service.
A service may open many short connections, whose loss may not be very important, or even noticed. For example, DNS over UDP or HTTP.
Bi-directional stickiness is employed for all connections. For example, any cluster in High Availability mode or ClusterXL in a Load Sharing mode with no VPN or static NAT. Sticky connections are discussed later in this chapter.
For all TCP services whose protocol type is HTTP or None, you can configure the Security Gateway to delay a connection so that it will only be synchronized if it still exists after the connection is initiated for x seconds. This capability is only available if a SecureXL-enabled device is installed on the gateway. SecureXL is discussed in greater detail in a later chapter.
<número>
 [Internal Use] for Check Point employees​
Synchronizes existing connections to maintain connectivity and eliminate downtime during cluster upgrades.
There is always one active member that handles traffic.
Connection failover is guaranteed.
Supports Dynamic Routing synchronization when upgrading to R80.10.
When using CU, several features do not survive after failover to an upgraded cluster member.
Software Blade information is not synchronized during failover.
Cluster Connectivity Upgrade
1
©2017 Check Point Software Technologies Ltd. 
Cluster Connectivity Upgrade
There are several methods available for upgrading ClusterXL deployments. The simplest method is to upgrade each cluster member as an independent gateway, but this will cause system downtime. Other methods involve at least one Active member or two cluster members handling traffic during the upgrade. With these methods, connections that are initiated during or after the upgrade process could possibly be dropped.
The Connectivity Upgrade (CU) method synchronizes existing connections to maintain connectivity and eliminate downtime during cluster upgrades. In a Cluster Connectivity Upgrade, there is always at least one Active cluster member that handles the traffic, and connection failover is guaranteed. Connections are even synchronized between cluster members running different Check Point software versions. Using CU, cluster members can be upgraded to Check Point software versions R77.20 and above. For more detailed information regarding software versions that support CU, refer to the Check Point Connectivity Upgrade Administration Guide.
Note: Cluster CU supports Dynamic Routing synchronization when upgrading to R80.10.	
Before upgrading with CU, it is important to make sure that the cluster has 2 or more members, with one member Active and all other members in Standby mode. The state of a cluster member can be checked by running the cphaprob state command. When the upgrade is complete, a message will display the upgrade status as ready for failover. At this point, the CCP will work in broadcast mode. To return it to multicast mode, on all cluster members, run the cphaconf set_ccp multicast command.
If error messages are displayed in the connectivity upgrade script, discontinue the upgrade and contact Check Point Support.
There are several features that do not survive after failover to an upgraded cluster member when using CU. These features include, but are not limited to the following:
General failover limitations such as Security servers, and connections handled by servicesmarked as non-synced
Connections initiated by individual cluster members
TCP connections that are TCP streamed
VPN connections for Mobile Access, Remote Access, and Traditional VPN mode
FTP control connections with NAT
Sessions authenticated with Identity Awareness
DLP connections
In addition, Software Blade information is not synchronized during failover to an upgraded cluster member. If the blade is configured to maintain connectivity over security, the connection will be accepted without inspection and forwarded to the destination member. However if the destination member is not available, the connection will be dropped. For additional limitations related to a general failover, refer to the Check Point ClusterXL Administration Guide.
<número>
 [Internal Use] for Check Point employees​
ClusterXL can support up to eight cluster members. To add a member to an existing cluster:
Run cpconfig to enable ClusterXL on the cluster member.
Change the IP address of the new cluster member to reflect the correct topology.
Ensure that all Check Point products are installed on the new cluster member. 
In the Cluster Members page of the cluster object, create a new cluster member.
Ensure that the proper interfaces on the new cluster member are configured as cluster interfaces if the cluster mode is Load Sharing or New High Availability.
Install the Security Policy on the cluster. The new member is now part of the cluster.
Add a Member to an Existing Cluster
1
©2017 Check Point Software Technologies Ltd. 
ClusterXL can support up to eight cluster members. To add a member to an existing cluster:
Run cpconfig to enable ClusterXL on the cluster member.
Change the IP address of the new cluster member to reflect the correct topology.
Ensure that all Check Point products are installed on the new cluster member. All Check Point software components must be identical on each member of the cluster.
In the Cluster Members page of the cluster object, create a new cluster member with the appropriate properties if the Security Gateway is new, or convert an existing gateway to a cluster member. If the member is a new Security Gateway, ensure that SIC is initialized and the topology is correctly defined.
Ensure that the proper interfaces on the new cluster member are configured as cluster interfaces if the cluster mode is Load Sharing or New High Availability.
Install the Security Policy on the cluster. The new member is now part of the cluster.
<número>
 [Internal Use] for Check Point employees​
A connection is sticky when all of its packets are handled by a single cluster member.
In Load Sharing mode, certain connections can be made sticky by enabling the Sticky Decision Function (SDF).
The SDF is required in cases of Asymmetric Routing.
Services and connection types supported by enabling SDF include:
VPN deployments with third-party VPN peers
Endpoint Connect/SSL Network Extender encrypted connections
SDF disables SecureXL and CoreXL.
Sticky Connections
1
©2017 Check Point Software Technologies Ltd. 
Sticky Connections
A connection is sticky when all of its packets are handled, in either direction, by a single cluster member. This is the case in High Availability mode, where all connections are routed through the same cluster member.
In Load Sharing mode, there are cases where it is necessary to ensure that a connection that starts on a specific cluster member will continue to be processed by the same cluster member in both directions. To that end, certain connections can be made sticky by enabling the Sticky Decision Function (SDF).
In a non-sticky connection, the reply packet returns via a different Security Gateway than the original packet. The synchronization mechanism knows how to properly handle these connections. In a non-sticky connection, a cluster member can receive an out-of-state packet, which the Security Gateway normally drops because it poses a security risk. In Load Sharing cluster configurations, Static NAT and encrypted connections may be non-sticky when the source and destination IP addresses change. Non-sticky connections will also occur if the System Administrator has configured asymmetric routing, where a reply packet returns through a different Security Gateway than the original packet. Asymmetric routing occurs when a packet is NAT’d or encrypted.
The Sticky Decision Function
The SDF is required in cases of Asymmetric Routing. In these cases, the packet is modified by the cluster member, and since the packet entering the Firewall is not the same as the one leaving, the regular decision function will not be able to make sure that the packet will go back through the original member. The SDF will try to match each packet to numerous kernel tables in an attempt to decide which member should handle the packet. 
The SDF enables certain services to operate in a Load Sharing deployment. For example, it is required for Layer 2 Tunneling Protocol (L2TP) traffic, or when the cluster is a participant in a Site-to-Site VPN tunnel with a third-party peer. 
The following services and connection types are supported by enabling the SDF:
VPN deployments with third-party VPN peers
Endpoint Connect/SSL Network Extender encrypted connections
The SDF is not supported when employing either acceleration technologies, such as SecureXL and CoreXL, or a hardware-based accelerator card. Enabling the SDF disables these acceleration products.
<número>
 [Internal Use] for Check Point employees​
Installing a secondary Security Management Server and deploying Management HA provides Security Management Server redundancy.
When the secondary Security Management Server is installed and synchronized, both the Primary and Secondary are prepared to function as the Active server.
Standby servers are synchronized to the Active server to keep up-to-date with all changes in the databases and Security Policy.
Management High Availability
1
©2017 Check Point Software Technologies Ltd. 
Management High Availability
The Security Management Server consists of several databases with information on different aspects of the system, such as objects, users, and policy information. This data changes each time the System Administrator makes modifications to the system. It is important to maintain a copy of this data so that crucial information is not permanently lost in the event of an Security Management Server failure.
Moreover, if the management server fails or is down for administrative purposes, a secondary server must be in place to take over its activities. In the absence of the Security Management Server, essential operations performed by the gateways, such as the fetching of the Security Policy and the retrieval of the Certificate Retrieval List (CRL), cannot take place. Installing a secondary Security Management Server and deploying Management High Availability (HA) provides Security Management Server redundancy.
In a Management High Availability environment, the Active Security Management Server, which is specified as the Primary, always has one or more standby management servers ready to take over in the event of a failure. The Standby Security Management Servers must all be of the same operating system and version. The existence of the Standby Security Management Server allows for crucial backups to be in place. When a Standby Security Management Server is installed, configure and specify it as Secondary. Initially, the Primary and Secondary Security Management Servers must be manually synchronized. If additional Standby servers are installed, configure automatic synchronization in the Global Properties.
Once the Secondary Security Management Server has been installed and manually synchronized, the Primary and Secondary are both prepared to function as the Active Security Management Server.
 
Secondary and Standby Security Management Servers
The Secondary Security Management Server is created with empty databases that are filled with information that it receives from the Active Security Management Server. The SecondarySecurity Management Server is ready when:
It is represented on the Primary Security Management Server as a network object.
SIC has been initialized between it and the Primary Security Management Server.
Synchronization has been completed with the Primary Security Management Server for the first time.
In a situation where the Primary Security Management Server becomes permanently unavailable, it is not sufficient to do the failover procedure and change the Standby server to Active. The Secondary server must be promoted to Primary, or a new Primary must be established. The database can only be exported from a Primary server. 
All management operations, such as editing and installing the Security Policy and modifying users and objects, are done by the Active Security Management Server. If the Active server is down and any of these operations need to be performed, the Secondary or one of the Standby Security Management Servers should be made active by the System Administrator. This transition from Standby to Active must be initiated manually.
The Standby servers are synchronized to the Active server so they are kept up-to-date with all changes in the databases and Security Policy. Security Gateways can fetch the Security Policy and retrieve a CRL from both the Active and the Standby servers.
<número>
 [Internal Use] for Check Point employees​
Failover is a manual procedure.
If the Active server is responsive:
Manually synchronize the Active and Standby servers.
Change the Active server to Standby.
Change the Standby to Active.
If the Active server has failed and is unresponsive:
Manually change the Standby to Active. Make sure that no peer server is Active before making the change.
Security Management Server Failover
1
©2017 Check Point Software Technologies Ltd. 
Security Management Server Failover
Security Management Server failover is a manual procedure. If the Active Security Management Server fails or it is necessary to change the Active to Standby, the following steps must be taken to prevent data loss.
If the Active Security Management Server is responsive:
Manually synchronize the Active and Standby Security Management Servers.
Change the Active Security Management Server to Standby.
Change the Standby Security Management Server to Active.
If the Active Security Management Server has failed and is unresponsive to changes, manually change the Standby Security Management Server to Active. Make sure that no peer server is Active before making the change.
Note: If two Security Management Servers are set to Active at the same time, unexpected behavior can occur.	
Before making changes to the High Availability environment, make sure that the status of each Security Management Server is known.
<número>
 [Internal Use] for Check Point employees​
Synchronization can be performed manually or automatically.
All databases are locked and a snapshot of the databases are saved to a local disk when synchronization is in progress.
Standby servers will overwrite their databases with the snapshot.
The following data is backed up and synchronized:
Network Security Management databases
Configuration and ICA data
Endpoint Security databases, if applicable
Synchronizing Management HA Active and Standby Servers
1
©2017 Check Point Software Technologies Ltd. 
Synchronizing Management HA Active and Standby Servers
Synchronization can be performed manually or automatically. Manual synchronization is a process initialized by the System Administrator. It can be set to synchronize databases and the installed Security Policy. After Standby servers are installed, the first synchronization must be performed manually even if the system is configured for automatic synchronization.
Automatic synchronization is configured by the System Administrator to allow the Standby Security Management Server to be synchronized with the Active Security Management Server at set intervals. This is the standard mode of synchronization because it keeps the Standby Security Management Server updated. The synchronization schedule is based on when the Security Policy is installed, which can be set to every time the policy is saved or on a set scheduled time, such as daily at 2:00 AM. It is always possible to synchronize manually, even when automatic synchronization has been selected. 
When synchronization is in progress, all databases are locked, and a snapshot of the databases are saved to a local disk. The system then compresses the snapshot data and copies the snapshot from the Active Security Management Server to all Standby management servers. The Standby servers will overwrite their databases with the snapshot and send a Restore status notification to the Active Security Management Server.
For Management HA to function properly, the following data is backed up and synchronized:
Network Security Management Databases (such as the Network Objects, policy settings, and the Security Policy itself)
Configuration and Internal Certificate Authority (ICA) data (such as Objects and Users databases, certificate information, and the CRL, which is available to be fetched by the Check Point Security Gateways)
Endpoint Security databases, if applicable
<número>
 [Internal Use] for Check Point employees​
Never been synchronized
Synchronized
Lagging
Advanced
Collision
Synchronization Status
1
©2017 Check Point Software Technologies Ltd. 
Synchronization Status
The synchronization status indicates the status of the peer Security Management Server in relation to that of the selected Security Management Server. This status can be viewed in the Management High Availability window or in SmartView Monitor, depending on whether you are connected to the Active or Standby Security Management Server. The following statuses may be displayed:
Never been synchronized — Immediately after the Secondary Security Management Server has been installed, it has not yet undergone the first manual synchronization that brings it up-to-date with the Primary Security Management Server.
Synchronized — The peer is properly synchronized and has the same database information and installed Security Policy.
Lagging — The peer Security Management Server has not been synchronized since the Active Security Management Server had changes applied to it.
Advanced — The peer Security Management Server is more up-to-date. 
Collision — The Active Security Management Server and its peer have different installed policies and/or databases. The System Administrator must perform manual synchronization and decide which of the servers to overwrite. For example, when Security Management Server-A fails before a synchronization takes place, the changes made to databases or to the Security Policy cannot be synchronized with Security Management Server-B. When Security Management Server-B takes over from Security Management Server-A, the System Administrator may decide to modify the Security Policy.
<número>
 [Internal Use] for Check Point employees​
To resolve technical issues, perform one of these actions:
Manually synchronize.
Re-install policy on the Active server, if automatic synchronization is configured.
If a collision occurs:
Manually synchronize the servers and choose which database is dominant.
Synchronization Troubleshooting
1
©2017 Check Point Software Technologies Ltd. 
Synchronization Troubleshooting
Synchronization can fail for technical reasons, such as when the Active Security Management Server does not connect with the Standby Security Management Server. To resolve issues such as this, perform one of the following actions:
Manually synchronize the Standby Security Management Server.
Install the Security Policy on the Active Security Management Server again. Use this option if automatic synchronization is configured. Once the policy is re-installed, the synchronization should occur automatically.
Synchronization can also fail if a collision occurs. In this case the System Administrator should manually synchronize the servers and choose which database is thedominant database. The CA is merged to prevent security issues. If a collision occurs between the servers, and one of the Security Management Servers is overwritten, use the Audit Logs to better understand the situation. Review the management operations which were recently performed on the overwritten server and perform them again, on the dominant server, if necessary. 
<número>
 [Internal Use] for Check Point employees​
Install and configure Management High Availability.
Lab 3.1: Deploying a Secondary Security Management Server
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
OPSEC Certified HA and Load Sharing products each:
Decide which cluster member will deal with each connection.
Perform health checks
Perform failover
OPSEC clustering products use Check Point State Synchronization.
OPSEC Certified Clustering Products
1
©2017 Check Point Software Technologies Ltd. 
OPSEC Certified Clustering Products
Products that carry the OPSEC Certified seal have been tested to guarantee integration and interoperability with Check Point software and hardware platforms. There are a number of OPSEC Certified High Availability and Load Sharing products which are used to configure HA Security Gateway clusters and to distribute traffic evenly among the clustered gateways. These clustering applications vary in monitoring, management, and performance capabilities. Their role however, is the same in that they each:
Decide which cluster member will deal with each connection.
Perform health checks, which involves checking cluster member status (Active, Standby or Down) and member interface status.
Perform failover.
As with ClusterXL, OPSEC Certified clustering products use Check Point State Synchronization to exchange and update connection data and other Security Gateway states between cluster members.
<número>
 [Internal Use] for Check Point employees​
VRRP is a network management protocol used to increase the availability of default gateway servicing hosts on the same subnet.
As a cluster solution, VRRP makes a group of routers appear as a single virtual router and allows a host to configure the virtual router as their default gateway.
VRRP cluster can be configured for High Availability. 
VRRP Clusters
1
©2017 Check Point Software Technologies Ltd. 
VRRP Clusters
Virtual Routing Redundancy Protocol (VRRP) and ClusterXL are mutually exclusive. VRRP is a network management protocol that is used to increase the availability of default gateway servicing hosts on the same subnet. It improves the reliability and performance of the host network by enabling a virtual router to act as the default gateway for that network. 
VRRP enables you to set up a group of routers as a default gateway router for backup or redundancy. As a cluster solution, it makes the group of physical routers appear as a single virtual router, allowing hosts to configure the virtual router as their default gateway. The VRRP routing platforms share the IP address corresponding to the default route configured on the hosts. Similarly to ClusterXL, one of the VRRP routing platforms is the Master (active) and the others are backups (standby). If the Master fails, one of the backup routers becomes the new Master router, providing a virtual default gateway and enabling traffic to be routed without relying on the failed router. A priority algorithm is used to determine if failover to a backup is necessary, when the Master or its interfaces fails. VRRP increases redundancy, making it significantly beneficial in situations where the availability of the default path for network hosts is critical. It can be implemented in Ethernet, multi-protocol label switching, and token ring networks.
As with ClusterXL, VRRP clusters can be configured for High Availability. Each VRRP cluster, known as a virtual router, has a unique Virtual Router Identifier (VRID).The VRID is a number used to group the routers. A virtual router can have one or more virtual IP (VIP) addresses to which other network nodes connect as a final destination or the next hop in a route. Only the Master is assigned a VIP. The backup is assigned a VIP upon failover when it becomes the Master. Check Point’s implementation of VRRP includes additional functionality called Monitored Circuit VRRP. Monitored Circuit VRRP prevents black holes caused by asymmetric routes created when only one interface on the Master router fails, as opposed to the Master itself. Gaia releases priority over all interfaces on a virtual router to let failover occur.
Note: You cannot have a standalone deployment in a Gaia VRRP cluster.	
VRRP Features
VRRP is specifically designed to enable data routing, forwarding, and switching among a pool of virtual routers. When using VRRP, a higher availability default path is gained without requiring the configuration of dynamic routing or router discovery protocols on every host. While there are methods such as Proxy ARP that can help clients find their default router, many security engineers simply configure a static route to a single router on each client because it is easier. However, if the single router goes down, the client will be unable to reach other networks. 
VRRP features include:
Minimized failover time and bandwidth overhead when a primary router becomes unavailable
Support of up to 255 virtual routers on a router physical interface, subject to the platform supporting multiple MAC addresses
Minimized service disruptions during failover
Provision for election of multiple virtual routers on a network for Load Sharing
No need to make configuration changes in the end nodes if a gateway router fails
Router discovery protocols to support failover operations is no longer required
Failover problems are addressed at the router level instead of on the network edge
Functionality over a wide variety of multi-access LAN technologies capable of supporting IP traffic
<número>
VRRP Types
Contains all the basic parameters and is applicable for most environments.
Each virtual router is configured as one unit.
Simple Monitored Circuit VRRP
Requires users to manually configure a virtual router for each monitored interface.
Use if working with:
A system on which VRRP has already been configured using this method.
An environment where each interface must be monitored individually.
The preempt VMAC mode.
Advanced VRRP
The two types cannot be used together on the same Security Gateway. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
VRRP Types
VRRP can be configured using one of these types:
	Simple Monitored Circuit VRRP — This configuration contains all of the basic parameters and is applicable for most environments. Each virtual router is configured as one unit.
Advanced VRRP — This procedure requires users to manually configure a virtual router for each monitored interface. Use Advanced VRRP if you are working with:
A system on which VRRP has already been configured using this method.
An environment where it is necessary to monitor each interface individually.
The preempt VMAC mode.
Simple Monitored Circuit VRRP and Advanced VRRP cannot be used together on the same Security Gateway.
<número>
 [Internal Use] for Check Point employees​
Functionality included in the Check Point VRRP implementation.
Eliminates connection issues caused by asymmetric routes when only one interface on the Master fails.
Monitors all VRRP interfaces on the Security Gateway.
To release priority, Gaia subtracts the Priority Delta from the Priority Value to calculate an Effective Priority. 
Monitored Circuit VRRP 
1
©2017 Check Point Software Technologies Ltd. 
Monitored Circuit VRRP
Monitored Circuit VRRP is a functionality included in the Check Point VRRP implementation. It eliminates connection issues caused by asymmetric routes when only one interface on the Master fails, as opposed to the entire platform. This problem occurs in environments where a gateway isa member of two or more virtual routers, typically one with internal interfaces and the other with external interfaces. For example, when an external interface fails or becomes unreachable, the Master fails over to the backup for the external virtual router while the internal virtual router stays on the Master. This can cause connectivity issues when the internal virtual router accepts traffic and is unable to connect to the new external Master.
Simple Monitored Circuit VRRP monitors all VRRP interfaces on the Security Gateways. When using Advanced VRRP, each interface in a virtual router can be configured separately. If one interface fails, the Master releases its priority over all of its VRRP interfaces. This allows the Master to fail over on all virtual routers that include the failed Master.
To release priority, Gaia subtracts the Priority Delta, a Check Point proprietary parameter which is defined when the virtual router is configured, from the Priority Value to calculate an Effective Priority. If configured properly, the Effective Priority will be lower than that of the backup routers in the other virtual routers and the VRRP election protocol is triggered to select a new Master. If the Effective Priority for the current Master and backup are the same, the gateway with the highest IP address becomes the Master. 
Security Policies
Security policies must be configured to accept VRRP packets on the Gaia platform if it is a Firewall blade-enabled Security Gateway. The Multicast destination assigned by the Internet Assigned Numbers Authority (IANA) for VRRP is 224.0.0.18. If the policy does not accept packets to 224.0.0.18, Firewall platforms in one Virtual Router take on Master state. If your Security Gateways use dynamic routing protocols such as OSPRF or RIP, create new rules for each multicast destination IP address.
<número>
 [Internal Use] for Check Point employees​
Every virtual router must be configured to monitor every VRRP interface.
Can be changed to Simple Monitored Circuit VRRP.
To delete and add new interfaces:
Cause a failover to the backup.
Reduce the priority or disconnect an interface.
Delete the virtual router on the interface.
Create a new virtual router using the new IP address.
Configure the virtual router.
Can be configured via WebUI or CLI.
Advanced VRRP
1
©2017 Check Point Software Technologies Ltd. 
Advanced VRRP
Advanced VRRP allows virtual routers to be configured at the interface level. Every virtual router must be configured to monitor every VRRP interface. Advanced VRRP can be changed to Simple Monitored Circuit VRRP by deleting all existing virtual routers and creating new ones. When changing, it is important to understand that a backup address cannot be moved from one interface to another while a Security Gateway is a Master. The following steps are performed to delete and add new interfaces with the necessary IP addresses:
Cause a failover to the backup.
Reduce the priority or disconnect an interface.
Delete the virtual router on the interface.
Create a new virtual router using the new IP address.
Configure the virtual router.
Advanced VRRP can be configured via WebUI or CLI. Use set and show commands to configure global and advanced VRRP settings via CLI, such as:
set vrrp interface VALUE
show vrrp interface VALUE
<número>
 [Internal Use] for Check Point employees​
VRRP Configuration Parameters
1
©2017 Check Point Software Technologies Ltd. 
VRRP Configuration Parameters
Regardless of the type of VRRP method used, VRRP configuration parameters must be defined and configured on each node. The values for each parameter are described in the table below.
Parameter		Description	
VRID		Range is 1- 255. Choose a numbering scheme for the virtual routers that will make sense to your organization. 	
Priority		Range is 1 - 254. The default value is 100. The priority value determines which router takes over in the event of a failure. The router with the higher 		priority becomes the new master. To provide a faster transition is the event of a failure, set the priority to 254 for at least one platform in each VRID, and 		choose values on the higher end of the scale for the backups. Effective Priority = Priority - the Priority Delta.	
Priority Delta		This parameter applies only to Monitored Circuit VRRP. Check Point recommends using a standard priority delta, such as 10, to simplify configuration. 		Choose a value that will ensure that when an interface fails, the priority delta subtracted from the priority results in an effective priority that is lower than 		that of all of the backup routers. 	
Hello Interval		Range is 1 - 255 seconds. The default setting is 1 second. The Hello Interval is the time interval in seconds at which the master sends VRRP 			advertisements. Set the same value for all nodes in the VRID.	
Authentication	Choose to require no authentication for VRRP advertisements or to require a simple password before a VRRP advertisement is accepted by the interface. 		Select the same authentication method for all nodes in the VRID.	
Backup Address (Virtual IP Address)	This parameter applies only to Monitored Circuit VRRP. The backup address must be in the same network as the interface used for the 				VRID. When entered, the system will use the interface that is in that subnet for the VRID.	
	
<número>
Chapter 3 Review Questions
What happens when the Sticky Decision Function (SDF) is enabled?
A connection is sticky when all of its packets are handled, in either direction, by a single cluster member. The SDF enables certain services to operate in a Load Sharing deployment. VPN deployments with 3rd party VPN peers and Endpoint Connect/SSL Network Extender encrypted connections are both supported when SDF is enabled. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 3 Review Questions
Describe what a cluster VMAC is and how it works.
Cluster Virtual MAC (VMAC) is a virtual MAC address assigned to a Virtual Router. It is a variation of the High Availability New mode and Load Sharing Unicast mode. Configuring the cluster to use VMAC mode allows all cluster members to use the same Virtual MAC address and minimizes possible traffic outages during a failover. In addition, G-ARPs for NAT’d addresses are no longer needed. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Demonstrate how to configure VRRP as the failover method for a Security Gateway cluster.
Lab 3.2: Enabling Check Point VRRP
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
Acceleration
04
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Understand how SecureXL acceleration technology enhances and optimizes Security Gateway performance.
Understand how CoreXL acceleration technology enhances and improves Security Gateway performance.
Acceleration
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Check Point provides two software-based acceleration features to optimize performance: SecureXL and CoreXL. SecureXL is a software acceleration product installed on Security Gateways, to create a SecureXL device layer. The Check Point Security Gateway enables security decisions to be made at this lower application level to remove performance bottlenecks. CoreXL is a performance-enhancing technology for Security Gateways on multi-CPU-core processing platforms. When enabled, CoreXL empowers the processing CPU cores to simultaneously perform multiple tasks, which enhances Security Gateway performance without requiring changes to management or to network topology. This chapter also introduces Multi-Queue, which allows each network interface to use more than one CPU for acceleration.
<número>
 [Internal Use] for Check Point employees​
SecureXL:Security Acceleration
Accelerates multiple, intensive security operations. 
Using SecureXL, the Firewall can inspect and process connections more efficiently by offloading operations to performance-optimized software or hardware devices.
1
©2017 Check Point Software Technologies Ltd. 
SecureXL: Security Acceleration
SecureXL is a patented Check Point security acceleration technology that accelerates multiple, intensive security operations, including operations carried out by Check Point’s Stateful Inspection Firewall. When enabled on a Security Gateway, some CPU-intensive operations are processed by virtualized software instead of the Firewall kernel. Using SecureXL, the Firewall can inspect and process connections more efficiently by offloading operations to performance-optimized software or hardware devices, dramatically increasing throughput without compromising security. SecureXL is included in Gaia and does not require an additional license.
<número>
 [Internal Use] for Check Point employees​
Paths of traffic flow:
Firewall Path – Packets and connections inspected by the Firewall.
Accelerated Path – Packets and connections offloaded to SecureXL.
Medium Path 
Using SecureXL
1
©2017 Check Point Software Technologies Ltd. 
Using SecureXL
SecureXL accelerates packet processing performance by remembering certain attributes of packets and packet flows that have already been validated by the blades. Validation of related packets and connections is then delegated to the SecureXL API, which enables offloading of security processing to optimized processing units. This validation is done at the hardware interrupt level on x86 hardware, or supervises execution of further optimized code in IP security appliances that support them. Both of these approaches involve substantially less computing overhead than is required by the Security Gateway. 
From SecureXL’s perspective, there are three paths of traffic flow:
Firewall Path — Packets and connections that are inspected by the Firewall. These packets and connections are not processed by SecureXL. This path is also referred to as the Slow Path.
Accelerated Path — Packets and connections that are offloaded from the Firewall to SecureXL. These packets and connections are quickly processed.
Medium Path — Packets that cannot use the accelerated path because they require deeper inspection. Although it is not necessary for the Firewall to inspect these packets, they can be offloaded by another feature. For example, packets that are examined by IPS cannot use the accelerated path and can be offloaded to the IPS Passive Streaming Library (PSL), which provides stream reassembly for TCP connections. As a result, SecureXL processes these packets quicker than packets on the slow path.
SecureXL’s purpose is to minimize connections that are processed on a slow path and accelerate the connection rate. As a connection is being established, if a packet is examined using traditional security methods and is determined to be safe, the SecureXL device layer takes over responsibility for examining any remaining packets to reduce latency. SecureXL can be implemented at both a hardware layer, such Gaia-based appliances or at a virtual software layer on open servers.
<número>
 [Internal Use] for Check Point employees​
Identifies connections by five attributes:
Source address
Destination address
Source port
Destination port
Protocol
When packets match all 5 attributes, the traffic can be processed on the accelerated path.
Packet Acceleration
1
©2017 Check Point Software Technologies Ltd. 
Packet Acceleration
Packet acceleration, which is also referred to as throughput acceleration, identifies connections by five attributes: 
Source address 
Destination address 
Source port 
Destination port
Protocol 
When the packets in a connection match all five attributes, the traffic flow can be processed on the accelerated path. However, only packets during the specific TCP/UDP connection can be accelerated. 
Packets attempting to establish a new TCP connection, or a comparable UDP connection table entry in the Firewall, are handled in the slow path because they require more processing. Once the first packet is seen by the Firewall and suitable connection information is offloaded to an appliance operating system, further packets are handled at the operating system's interrupt-level code. 
SecureXL improves non-encrypted Firewall traffic throughput and encrypted (VPN) traffic throughput by a significant amount, particularly for small packets flowing in long duration connections.
<número>
 [Internal Use] for Check Point employees​
Packet Acceleration
Factors that preclude a packet from being accelerated include:
The ClusterXL SDF feature is enabled
The first packet of any new TCP or UDP session, unless a template exists
Connections destined to or originating from the Security Gateway
Connections that require Security servers
Connections that have a Handler
Some IPS features
 
1
©2017 Check Point Software Technologies Ltd. 
There are several factors that preclude a packet from being accelerated, such as:
The ClusterXL Sticky Decision Function (SDF) feature is enabled
The first packet of any new TCP or UDP session, unless a template exists
Connections destined to or originating from the Security Gateway
Connections that require Security servers (Authentication, Antivirus, URL Filtering, Anti-Spam, DNS protocol enforcement)
Connections that have a Handler (ICMP, FTP, H.323, etc.)
Some IPS features (IP, ID, TTL)
Multicast packets
<número>
 [Internal Use] for Check Point employees​
SecureXL improves:
new connection rates (connections per second)
connection setup/tear-down rates (sessions per second)
throughput in certain high-connection rate traffic environments
One-time validation of a Firewall flow is extended.
To accelerate the rate of new connections, connections that do not match a specified 5-attributes are still processed by SecureXL.
SecureXL creates and saves templates once a flow is validated and established.
Session Rate Acceleration
1
©2017 Check Point Software Technologies Ltd. 
Session Rate Acceleration
SecureXL also reduces the overhead in establishing certain kinds of new connections, improving new connection rate (connections per second), connection setup/tear-down rate (sessions per second), and throughput in certain high-connection rate traffic environments.
The principle involved is a simple extension of SecureXL’s approach to one-time validation of a Firewall flow. The one-time validation is extended from a particular 5-attributes to a range, or block, of one or more of these attributes. This means that to accelerate the rate of new connections, connections that do not match a specified 5-attributes are still processed by SecureXL.
As an example, the source port of a packet flow may be masked off, effectively providing a global match for source port. Once a flow is validated and established, SecureXL creates and saves a template of that flow with the source port masked off. Any new connection setup packet that matches the other 4 attributes is processed on the accelerated path, thus avoiding Firewall inspection and additional computing overhead. Security is not impacted because the operating system continues to track the state of the new connection using Stateful Inspection. 
<número>
 [Internal Use] for Check Point employees​
Masking the Source Port
1
©2017 Check Point Software Technologies Ltd. 
Masking the Source Port
To examine how ports are used in establishing TCP connections, consider the following scenario. A client requesting a connection to a server initiates the TCP three-way handshake. The client addresses the server, typically at a well-known port number depending on the service provided by the server, such as port 23 for Telnet or port 80 for HTTP. Together the server’s IP address and the well-known port number form a socket address. The client assigns and pairs an OS-selected port number with the client’s IP address to createa socket address for the reverse direction.
<número>
 [Internal Use] for Check Point employees​
HTTP generates most of the new connection requests.
TCP connection establishment is initiated by the web client which sends an HTTP request ().
The web server responds by sending the HTTP component ().
Once the connection is approved, a template is created and stored.
Subsequent connection setups can share the template approval.
Application Layer Protocol – An HTTP Example
1
©2017 Check Point Software Technologies Ltd. 
Application Layer Protocol - An HTTP Example
Consider higher-level application protocols that involve numerous TCP connections between the client and server, either simultaneously (in parallel), sequentially, or both. HTTP, which accounts for most Internet traffic, is one of these protocols. HTTP generates most of the new connection requests in enterprise and Internet traffic.
Web pages consist of multiple HTTP components, text, and perhaps dozens of graphic elements. Using HTTP, each component is downloaded from server to client using a separate TCP connection. This action involves substantial overhead in connection setup and tear-down and in protective-Firewall connection tracking (Firewalls at both ends).
In all cases between a web client and a web server, TCP connection establishment is initiated by the web client, which then sends an HTTP request. The web server responds by sending the HTTP component:
HTTP Request (->) — Each of the packets from the web client that requests an HTTP component from the web server has the same source address, destination address, destination port (80), and protocol (HTTP). Only the source port, assigned (one per connection) by the web client's operation system, differs to create unique socket addresses at the client for each HTTP request/component (via separate TCP connections for each component).
 HTTP Component (<-) — Going the other direction, each of the packets from the web server that build the web page components on the web client has the same source address, destination address, source port (80), and protocol (HTTP). Only the destination port differs (it's been assigned by the client operating system to that connection).
Once a connection involving a flow to port 80 is approved by the Firewall for the web client (resulting from the first HTTP request), a template is created and stored. All subsequent connection setups carrying those additional requests can share that same template approval, because it’s okay that the source ports differ. Establishing those subsequent connections does not involve a round trip to the Firewall, resulting in faster processing through the server Firewall.
Similarly, at the client Firewall, once a connection involving a flow to port 80 is approved by the Firewall (as above), all subsequent connections carrying these additional requests can share that same approval. Establishing those subsequent connections does not involve a round-trip to the Firewall. SecureXL accelerates subsequent connections through both Firewalls when multiple connections share the same source address, destination address, destination port, and protocol. 
<número>
 [Internal Use] for Check Point employees​
SecureXL Connection Templates
Accept Templates
Drop Templates
 
Factors that preclude templating include:
Source port ranges
IPS features not supported in Acceleration
NAT’d traffic, unless NAT templates are enabled
 
1
©2017 Check Point Software Technologies Ltd. 
SecureXL Connection Templates
SecureXL connection templates create the opportunity to generate extremely impressive connection rate performance. Given the benefit of connection templates in heavy HTTP environments, the significant performance increase can be reflected in real-world traffic settings, such as in web server farms and enterprises where there is a great deal of web traffic to a small, concentrated set of servers. 
To accelerate the rate of connection establishment, SecureXL groups all connections that match a particular service and whose sole differentiating element is the source port. This type of grouping enables even the very first packets of a TCP handshake to be accelerated. The first packets of the first connection on the same service will be forwarded to the Firewall kernel, which will then create a template of the connection. SecureXL has three different templates:
Accept Templates — Created when a connection is established by matching a new connection to a particular set of tuple attributes. Subsequent connections are established without performing a rule match and are therefore accelerated. Accept templates are enabled by default and generated from active connections according to policy rules. Accept template acceleration is only on connections with the same destination port. 
Drop Templates — Generated by policy rules to accelerate the speed at which a connection is dropped by matching a new connection to a set of tuple attributes. Subsequent connections are dropped without performing a rule match and are therefore accelerated. Drop template acceleration is also performed only on connections with the same destination port. These templates are disabled by default. Drop templates are discussed in greater detail in the CCSM course.
NAT Templates — Generated to achieve high session rate for NAT. These templates are supported in cluster HA/VRRP and Load Sharing modes. NAT templates are controlled by global kernel parameters and disabled by default. NAT templates are discussed in greater detail in the CCSM course.
Factors that Preclude Templating
There are factors that can preclude templating if all other parameters are met for packet acceleration, such as:
Source port ranges
IPS features not supported in Acceleration
NAT’d traffic, unless NAT templates are enabled
Encrypted connections
Once templating is disabled in the Rule Base, all connections matching rules lower in the Rule Base cannot be templated. Use fwaccel stat to determine at which rule templating is disabled and move the most used rules above that rule to take advantage of session acceleration.
<número>
 [Internal Use] for Check Point employees​
Packet Flow
1
©2017 Check Point Software Technologies Ltd. 
Packet Flow
The figure shows the decision logic for packets flowing through SecureXL accelerated IP security appliances.
A new packet arrives at the Inbound interface. The packet is checked against the Connections table, which mirrors the Firewall’s Connections table. If there is a 5-tuple match, the new packet is part of an existing flow and is forwarded to the Outbound interface for handling (forward, drop, or reject). This path involves the least amount of forwarding overhead and accelerates throughput for packets that are part of an existing flow. 
If the new packet does not match an entry in the Connections table, it represents a new flow and requires a new Connections table entry. However, if the packet matches an existing connection template, then the new Connections table entry can be created (based on information in the connection template table entry) without a round trip to the Firewall application. The packet is then forwarded to the Outbound interface for handling. This path reduces the overhead involved in creating a new connection table entry and accelerates the connection rate for new connections that match existing connection templates.
If the new packet does not match an existing connection template, then a round trip to the Firewall application is required in order to apply the Security Policy. This path involves the greatest overhead.
<número>
 [Internal Use] for Check Point employees​
VPN Link Selection – allows multiple external interfaces to be configured for tunneling the VPN packets.
Dynamic VPN Routing – allow the VPN domain to be determined dynamically instead of configuring a static VPN domain.
Wire Mode Connections – allows trusted traffic to pass through without Stateful Inspection.
VPN Capabilities
1
©2017 Check Point Software TechnologiesLtd. 
VPN Capabilities
SecureXL adds VPN routing capabilities and enhances connectivity to support VPN in dynamic routing environments.
VPN Link Selection
VPN Link Selection allows multiple external interfaces to be configured for tunneling the VPN packets. It allows the Firewall to create, maintain, and update a table of Link Selection entries. The Firewall can specify which link needs to be used for a given Security Association. If that link goes down, the Firewall can update the Link Selection entries to start using a different link for the same tunnel.
Dynamic VPN Routing
Dynamic VPN routing allows the VPN domain to be determined dynamically instead of configuring a static VPN domain. With Dynamic VPN routing enabled, connections can transition from clear text to encrypted or from encrypted to clear text, based on the route taken by the connection. The connection properties adapt to the route changes between an external interface (untrusted) and an internal (trusted) interface by communicating in encrypted or clear text respectively.
Wire Mode Connections
Wire Mode Connections allow trusted traffic to pass through without Stateful Inspection. If an internal interface and the VPN Community are configured as wired (trusted), then the traffic passing through the internal interface and getting encrypted using the VPN Community will skip any Stateful Inspection. This increases the connectivity speed at lower security for traffic between wired interfaces and a wired VPN Community.
<número>
 [Internal Use] for Check Point employees​
Demonstrate how fwaccel affects traffic flow.
Review the status of traffic acceleration on a Check Point Security Gateway.
Lab 4.1: Working with SecureXL
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Advanced, core-level load balancing that increases throughput.
CoreXL: Multicore Acceleration
1
©2017 Check Point Software Technologies Ltd. 
CoreXL: Multicore Acceleration
As the first security technology to fully leverage general purpose multi-core processors, CoreXL introduces advanced, core-level load balancing that increases throughput for the deep inspection required to achieve intrusion prevention and high throughput. With CoreXL, high performance and high security can be achieved simultaneously. Like SecureXL, CoreXL is also included with the Gaia operating system and does not require additional licensing.
Using CoreXL
Multi-core CPU support enables Check Point Security Gateways to share traffic among cores of a single system, providing superior performance on a single server. The combination of multi-core CPUs and multi-threaded SecureXL security application technology is the foundation for the next generation of security acceleration: Application layer security. By joining a multi-core CPU with SecureXL security acceleration, Security Gateways can deliver more than 10 Gbps of Intrusion Prevention throughput.
Using CoreXL, the Firewall kernel is replicated multiple times. Each replicated copy, or instance, of the Firewall kernel runs on one processing core. The instances handle traffic concurrently, and each instance is a complete and independent inspection kernel. Regarding network topology, management configuration, and Security Policies, a CoreXL gateway functions as a regular Security Gateway. All of the kernel instances of a gateway handle traffic going through the same interfaces and apply the same Security Policy. Traffic entering Network Interface Cards (NIC) is directed to a processing CPU core running the Secure Network Distributor (SND), which will distribute non-accelerated packets among the Firewall kernel instances and securely accelerate packets authorized to be processed using SecureXL. 
CoreXL acts as a load balancer and improves Security Gateway performance in situations where much of the traffic cannot be accelerated by SecureXL or when the gateway has many IPS features enabled, which disables SecureXL functionality. It also improves performance for gateways with a large Rule Base and NAT rules. CoreXL does not benefit the gateway when the traffic consists mostly of VPN or VoIP traffic.
CoreXL is not supported when one of the following features is enabled:
VPN Traditional mode
Overlapping NAT
<número>
 [Internal Use] for Check Point employees​
Configuring CoreXL
CoreXL is enabled or disabled using cpconfig and requires a reboot to take effect.
The default number of kernel instances is derived from the total number of cores in the system.
1
©2017 Check Point Software Technologies Ltd. 
Configuring CoreXL
CoreXL is enabled or disabled using cpconfig and requires a reboot to take effect. When enabled, enter the number of Firewall kernel instances for the gateway. The default number of kernel instances is derived from the total number of cores in the system, as described in the following table:
Number of Cores	Number of Kernel Instances	
1		CoreXL is disabled	
2		2	
4		3	
6 - 20		(Number of CPU cores) - 2	
More than 20		(Number of CPU cores) - 4
		No more than 40 total.	
<número>
 [Internal Use] for Check Point employees​
If using CoreXL with ClusterXL, the number of kernel instances must be identical on all members of the cluster.
Configuring CoreXL
1
©2017 Check Point Software Technologies Ltd. 
If using CoreXL with ClusterXL, the number of kernel instances must be identical on all members of the cluster. This is because State Synchronization between cluster members is performed per CoreXL Firewall kernel instance. For example, Instance #2 on cluster member A can only synchronize with Instance #2 on cluster member B.
<número>
 [Internal Use] for Check Point employees​
The Secure Network Distributor (SND) is responsible for:
Processing incoming traffic from the network interfaces.
Accelerating authorized packets (if SecureXL is running).
Distributing non accelerated packets among kernel instances.
Affinity settings for all interfaces are set automatically by default.
To see affinity distribution use the sim affinity -1 command.
Adding processing cores to the hardware does not automatically increase the number of kernel instances.
An additional core can be allocated to the SND.
Processing Core Allocation
1
©2017 Check Point Software Technologies Ltd. 
Processing Core Allocation
The CoreXL software architecture includes the Secure Network Distributor. The SND is responsible for processing incoming traffic from the network interfaces, securely accelerating authorized packets (if SecureXL is running), and distributing non-accelerated packets among kernel instances. In other words, the SND is essentially a CPU core running both SecureXL and CoreXL.
Traffic entering the NIC is directed to a processing core running the SND. The association of a particular interface with a processing core is called the interface's affinity with that core. Affinity is a general term used to describe binding NIC interrupts to processors. Affinity settings for all interfaces are set automatically by default when the CoreXL architecture includes processing incoming traffic from NICs. This affinity causes the interface's traffic to be directed to that core and the SND to run on that core. Setting a kernel instance or a process to run on a particular core is called the instance's, or process's, affinity with that core. Traffic from all NICs is directed to the core running the SND.
The default affinity setting for all interfaces is automatic. If SecureXL is running, the affinity for each interface is automatically reset every 60 seconds and balanced between available cores. If SecureXL is not running, the default affinities of all interfaces are with one available core. In both cases, any processing core running a kernel instance, or defined as the affinity for another process, is considered unavailable and will not be set as the affinity for any interface.
In some cases, SND cores can be overloaded due to high traffic on multiple interfaces assigned tothe same SND core. Manual sim affinity can alleviate this symptom. Use the sim affinity -l command to see affinity distribution. Each busy interface should be assigned its own Interrupt ReQuest (IRQ) value and distributed among SND cores. The assignment of interfaces to IRQs can be verified in the /proc/interrupts file.
In some cases, it may be advisable to change the distribution of kernel instances, the SND, and other processes among the processing cores. This is done by changing the affinities of different NICs and/or processes. However, to ensure CoreXL’s efficiency, all interface traffic must be directed to cores not running kernel instances. Therefore, changing affinities of interfaces or other processes will require resetting the number of kernel instances and ensuring that the instances run on other processing cores.
Under normal circumstances, it is not recommended for the SND and an instance to share a core. However, it is necessary for the SND and an instance to share a core when using a machine with exactly two cores.
Adding Processing Cores to the Hardware
Increasing the number of processing cores on the hardware platform does not automatically increase the number of kernel instances. If the number of kernel instances is not increased, CoreXL does not utilize some of the processing cores. After upgrading the hardware, increase the number of kernel instances using cpconfig.
Reinstalling the Security Gateway will change the number of kernel instances if you have upgraded the hardware to an increased number of processing cores, or if the number of processing cores stays the same but the number of kernel instances was manually changed from the default.
In a clustered deployment, changing the number of kernel instances, such as by reinstalling CoreXL, should be treated as a version upgrade. Follow the instructions in the Upgrade Guide and perform either a Minimal Effort Upgrade using network downtime or a Zero Downtime Upgrade, substituting the instance number change for the version upgrade in the procedure. A Full Connectivity Upgrade cannot be performed when changing the number of kernel instances in a clustered environment.
Allocating an Additional Core to the SND
In some cases, the default configuration of instances and the SND will not be optimal. If the SND is slowing the traffic and your platform contains enough cores that you can afford to reduce the number of kernel instances, you may want to allocate an additional core to the SND. This is likely to occur, especially if much of the traffic is accelerated by SecureXL, in a ClusterXL Load Sharing deployment or if IPS features are disabled. In any of these cases, the task load of the SND may be disproportionate to that of the kernel instances.
Note: Check Point recommends that your platform have at least 8 CPU cores to allocate an additional core to the SND.	
Allocating a Core for Heavy Logging
If the Security Gateway is performing heavy logging, it may be advisable to allocate a processing core to the fwd daemon, which performs the logging. Like adding a core for the SND, this too will reduce the number of cores available for kernel instances.
<número>
 [Internal Use] for Check Point employees​
Helps to improve load distribution and mitigates connectivity issues during traffic peaks.
When enabled, connections to CoreXL instances are dynamically assigned based on utilization of the CPU cores.
Most beneficial in environments with a large number of CPU cores and when the CPU load is not properly balanced.
Dynamic Dispatcher
1
©2017 Check Point Software Technologies Ltd. 
Dynamic Dispatcher
Dynamic Dispatcher is a CoreXL feature which helps to improve load distribution and mitigates connectivity issues during traffic peaks. Without Dynamic Dispatcher, new connections to a CoreXL Firewall instance are fixed or statically assigned, based on packet IP addresses and IP protocol type. This static assignment may result in situations where one or more instances would handle more connections or perform more processing on the packets forwarded to them than the others, which may cause the load to become unbalanced across the CPU cores. In addition, during peak times and policy installation, an overloaded core may cause traffic to be delayed or dropped.
When Dynamic Dispatcher is enabled, connections to CoreXL instances are dynamically assigned, based on utilization of the CPU cores. Dynamic Dispatcher will distribute the load equally between the CPU cores. Connections opened at a higher rate that would have been assigned to the same instance by a static decision are now distributed to several instances. 
The Dynamic Dispatcher feature is enabled by default in R80.10. When enabled, the dynamic assignment decision is made for the first packets of connections by assigning a rank to each of the instances and selecting the instance with the lowest rank. The ranking of each instance is calculated according to the CPU utilization of the instance. If the CPU utilization of an instance is high, the ranking for that instance will be high as well. Higher ranked instances are less likely to be selected by the SND. 
<número>
 [Internal Use] for Check Point employees​
Enable Dynamic Dispatcher if the following thresholds or situations occur:
An instance consumes its CPU core at ≥ 85%, even for one second.
Other instances consume their CPU cores at 75% and below.
Traffic is dropped or delayed due to an overloaded core during peaks or during policy installation.
When to Enable Dynamic Dispatcher
Use fw ctl multik stat to check the distribution of connections across all CoreXL Firewall instances.
1
©2017 Check Point Software Technologies Ltd. 
When to Enable Dynamic Dispatcher
Dynamic Dispatcher is most beneficial in environments with a large number of CPU cores and when the CPU load is not properly balanced. Enable Dynamic Dispatcher if the following thresholds or situations occur:
A CoreXL instance consumes its CPU core at ≥ 85%, even for one second.
Other CoreXL instances consume their CPU cores at 75% and below. The difference in CPU consumption between overloaded and normally loaded instances is 10% or more.
Traffic is dropped or delayed due to an overloaded core during traffic peaks or during policy installation.
When Dynamic Dispatcher is enabled, connections are always assigned dynamically, even in cases where there is no significant differences in CPU load, with the exception of VoIP and VPN encrypted packets. These two types of traffic will always be handled by the same Firewall instance. The distribution of connections across all CoreXL Firewall instances can be checked using the fw ctl multik stat command. Checking the connections will allow you to monitor the current connections and ultimately decide whether or not to enable the Dynamic Dispatcher feature. To fully enable Dynamic Dispatcher on a Security Gateway, run the following command in Expert mode and then reboot:
fw ctl multik dynamic_dispatching on
<número>
 [Internal Use] for Check Point employees​
Prioritizes traffic when the CPU cores are 100% utilized and packets need to be dropped.
Priorities packets based on the connection type.
Firewall Priority Queues
1
©2017 Check Point Software Technologies Ltd. 
Firewall Priority Queues
Firewall Priority Queues prioritize traffic when the CPU cores on the Firewall are 100% utilized and packets need to be dropped. This feature is disabled by default in R80.10. When enabled, the priority queues are only active when the CPU is overloaded. When the Firewall is fully utilized, packet loss can occur regardless of the connection’s type (for example, SSH and DHCP connections).
 
Priority Queues prioritize the packets based on the type of connection, and each connection of the same priority will get an equal share of the CPU resources. There are 8 priority queues by default, and up to 8 additional queues can be manually configured. When a new packet arrives, the connection is classified in order to know which queue it is assignedto. For example, packets of a SSH connection will go to the Control queue.
Default Priority Queues table.
Some connection types can be migrated between priority queues to be assigned a lower or higher priority with respect to other connections. For example, a new connection begins its life in the Default Data queue (Queue #5). If this connection gets lighter, it will migrate to a higher priority queue, such as the Light Data queue (Queue #4). If the connection becomes heavier, it can migrate to a lower priority queue, such as the Heavy Data queue (Queue #7). The Firewall will decide whether or not the connection should be migrated, based on the load time of an average connection of that type. It knows to how many possible queues the connection was assigned to and the CPU load caused by this connection. 
To enable Dynamic Dispatcher on a Security Gateway without the Firewall Priority Queues, run the following command in Expert mode and reboot:
fw ctl multik prioq 2
<número>
 [Internal Use] for Check Point employees​
Packet Flow with CoreXL and SecureXL Enabled
1
©2017 Check Point Software Technologies Ltd. 
Packet Flow with CoreXL and SecureXL Enabled
The following image depicts packet flow through the Security Gateway with CoreXL and SecureXL is enabled:
Acceleration Path
The packet is completely handled by the SecureXL device. It is processed and sent back to the network.
Medium Path
The packet is handled by the SecureXL device, except for IPS, Application Control, Antivirus, and Anti-Bot processing. The CoreXL layer passes the packet to one of the Firewall instances to perform processing. This path is only available when CoreXL is enabled.
Firewall Path
The SecureXL device is unable to process the packet. It is passed to the CoreXL layer and then to one of the instances for full processing on the slow path. 
<número>
 [Internal Use] for Check Point employees​
Multi-Queue allows you to configure more than one traffic queue for each NIC, to use more CPU cores for acceleration.
Helps balance the load efficiently between SND CPUs and CoreXL instance CPUs.
Configure Multi-Queue when these conditions are presented:
SND CPU load is high (idle is < 20%).
CoreXL instance CPU load is low (idle is > 50%%).
No CPU cores are left to be assigned to the SND by changing interface affinity.
Multiple Traffic Queues
1
©2017 Check Point Software Technologies Ltd. 
Multiple Traffic Queues
As mentioned before, the SND is a processing core which accelerates traffic from network interfaces using SecureXL and distributes non-accelerated packets among instances using CoreXL. The number of CPUs allocated to the SND is limited by the number of network interfaces handling the traffic. By default, each NIC has one traffic queue that is handled by one CPU. Therefore, users cannot use more CPU cores for acceleration than the number of interfaces handling traffic. Multi-Queue is an acceleration feature that will allow you to configure more than one traffic queue for each NIC, to use more CPU cores for acceleration.
Using Multi-Queue
When most network traffic is being accelerated, the CPU load for SND can be very high, while the CPU load for CoreXL Firewall instances are very low. This results in an inefficient utilization of CPU capacity. Using Multi-Queue to configure more than one traffic queue for each supported network interface helps balance the load efficiently between SND CPUs and CoreXL instance CPUs. 
Check Point does not recommend assigning both a SND and a CoreXL instance to the same CPU core. Multi-Queue does not enhance Firewall performance in situations such as when all Firewall instances are highly loaded and most of the traffic is being processed in CoreXL’s slow or medium paths, or in cases where all CPU cores that are used by SecureXL are congested. In addition, Multi-Queue does not help when IPS, or other deep inspection Software Blades are heavily used.
Configuring Multi-Queue
Check Point recommends configuring Multi-Queue when the following conditions are presented:
The CPU load for SND is high (idle is < 20%).
The CPU load for CoreXL instances is low (idle is > 50%).
There are no CPU cores left to be assigned to the SND by changing interface affinity
Note: The Interrupt ReQuest (IRQ) affinity of the queues is set automatically when the operating system boots. Manually changing the IRQ affinity of the queues can adversely affect performance.
	
.
<número>
 [Internal Use] for Check Point employees​
Guidelines to help determine if your network can benefit from configuring Multi-Queues:
Make sure that both SecureXL and CoreXL are enabled.
Make sure that the network interfaces support Multi-Queue.
Examine the CPU affinity to see how the CPU roles are allocated for interfaces (SND) and for CoreXL instances.
Examine the CPU utilization for usage and idle percentages.
Determine if more CPU cores can be allocated to the SND.
Multiple Traffic Queues
To configure Multi-Queue on supported interfaces, run: cpmq set
1
©2017 Check Point Software Technologies Ltd. 
Use the following guidelines to help determine if your network can benefit from configuring Multi-Queues:
Make sure that both SecureXL and CoreXL are enabled.
Make sure that the network interfaces support Multi-Queue. 
Examine the CPU affinity to see how the CPU roles are allocated for interfaces (SND) and for CoreXL instances. 
	To see the CPU roles allocation, run the following command: fw ctl affinity –l
Examine the CPU utilization for usage and idle percentages. On the Security Gateway run top and then press 1 to toggle to the SMP view.
Determine if more CPU cores can be allocated to the SND. If there are more network interfaces handling traffic than CPUs assigned to the SND, more CPUs can be allocated for SND.
Use the following command to configure Multi-Queue on supported interfaces:
cpmq set
The command will display all supported interfaces that are active and allow changes to be made to the Multi-Queue configuration for each interface. It is important to reboot the gateway after changing the Multi-Queue configuration. A maximum of five interfaces can be configured.
The following command shows the Multi-Queue status of supported interfaces:
cpmq get
<número>
Chapter 4 Review Questions
Describe the three paths of traffic flow for SecureXL.
Firewall path — Packets and connections that are inspected by the Firewall. These packets and connections are not processed by SecureXL.
Accelerated path — Packets and connections that are offloaded from the Firewall to SecureXL. These packets and connections are quickly processed.
Medium path — Packets that cannot use the accelerated path because they require deeper inspection. Although it is not necessary for the Firewall to inspect these packets, they can be offloaded by another feature. For example, packets that are examined by IPS cannot use the accelerated path and can be offloaded to the IPS Passive Streaming Library (PSL), which provides stream reassembly for TCP connections. As a result, SecureXL processes these packets quicker than packets on the slow path.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 4 Review Questions
How does CoreXL improve network performance?
CoreXL acts as a load balancer and improves Security Gateway performance in situations where much of the traffic cannot be accelerated by SecureXL or when the gateway has many IPS features enabled, which disables SecureXL functionality. It also improves performance for gateways with a large Rule Base and/or NAT rules. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 4 Review Questions
When should you consider using Multi-Queue?
Check Point recommends configuring Multi-Queue when the following conditions are presented:
The CPU load for SND is high (idle is < 20%).
The CPU load for CoreXL Firewall instances is low (idle is > 50%).
There are no CPU cores left to be assigned to the SND by changing interfaceaffinity.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Demonstrate how multiple system cores can be used by CoreXL to accelerate traffic.
Identify how to review the status of CoreXL on a Security Gateway.
Lab 4.2: Working with CoreXL
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
smartevent
05
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Identify SmartEvent components used to store network activity logs and identify events.
Discuss the SmartEvent process that determines which network activities may lead to critical security issues.
Understand how SmartEvent can assist in detecting, remediating, and preventing security threats targeting organizations.
SmartEvent
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Check Point’s SmartEvent Software Blade turns log entries into meaningful security information. It correlates log events, aggregates data, and identifies potential attack patterns from various devices. It prioritizes security events among a multitude of logging activities in the network, making it easy for Cyber Security Administrators to remediate and prevent critical events. With its customizable graphical reports and intuitive GUI, administrators can readily monitor patterns and events as they unfold and provide reporting to key stakeholders in the organization. 
<número>
A unified security event management and analysis solution that delivers graphical threat management information. 
SmartEvent provides a high-level view and detailed forensic analysis of incidents to aid in monitoring, fixing, and remediating security incidents. 
SmartEvent
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
The SmartEvent Solution
Check Point SmartEvent Software Blade is a unified security event management and analysis solution that delivers graphical threat management information. It allows Security Administrators to view real-time network activities in customized views or reports. Customized views allow you to monitor activities relevant to protecting your organization. Personalized reports enable you to report on security activities to key stakeholders in your organization. 
SmartEvent provides both a high level view and detailed forensic analysis of incidents to aid in monitoring, fixing, and remediating security incidents. It also helps you efficiently run data analysis and identify critical security events from the vast number of logs in the network. With SmartEvent, you can collect, process, and search from billions of log entries in seconds. 
<número>
 [Internal Use] for Check Point employees​
A log is a record of an action performed by a Software Blade.
An event is a record of a security or network incident that is based on one or more logs and a set of rules defined in the Event policy.
The Event policy is a set of rules that define the behavior of SmartEvent.
Firewall, VPN, and HTTPS Inspection logs are not automatically defined as events.
Logs and Events
1
©2017 Check Point Software Technologies Ltd. 
Logs and Events
A log is a record of an action performed by a Software Blade. Log entries show the traffic patterns that are relevant to the overall security of the organization. An event is a record of a security or network incident that is based on one or more logs and on a customizable set of rules that are defined in the Event policy.
The Event policy is a set of rules that define the behavior of SmartEvent. A log entry (or multiple log entries) becomes an event when it matches any rules defined in the Event policy. An example of a single log entry becoming an event is a High Severity Anti-Bot event, because of the rules defined in the Event policy. Multiple log entries can also become an event, such as in the case of a Certificate Sharing event, wherein two logins were found with the same certificate but different users. 
SmartEvent automatically defines logs that are not Firewall, VPN, or HTTPS Inspection logs, as events. These events are created by the Correlation Unit when there is a suspicious pattern of two or more logs. Correlated events are defined in the Policy tab of the SmartEvent GUI.
Since most logs are Firewall, VPN, and HTTPS logs, SmartEvent will not automatically define them as events. This is to avoid performance issues with the SmartEvent Server. However, enabling consolidated events for Firewall saves disk space and makes it possible to keep a longer event history. To create events for Firewall, navigate to the SmartEvent Policy tab and enable Consolidated Sessions > Firewall Session.
<número>
 [Internal Use] for Check Point employees​
SmartEvent Server
Correlation Unit
Log Server
SmartEvent Components
Responsible for storing logs.
Uses port 18184 to connect to the Correlation Unit.
Evaluates logs from the Log Server to identify events.
Performs one of these actions:
Marks logs that individually are not events.
Generates an event based on the Event policy.
Adds a new log entry to an ongoing event.
Discards logs that do not meet event criteria.
Houses the Events database.
Determines the severity of an event and what action to take.
1
©2017 Check Point Software Technologies Ltd. 
SmartEvent Components
SmartEvent utilizes several key components to aggregate logs, identify critical security events, and provide efficient event query. The three main components are the Log Server, the Correlation Unit, and the SmartEvent Server.
Log Server
The Log Server is responsible for storing logs collected from Check Point Security Gateways and Third-Party devices. The Correlation Unit connects to the Log Server to read the logs using the LEA (Log Export API) protocol. The Log Server uses port 18184 for this connection by default.
Note: When configuring the Log Server to use a different LEA port, you must manually configure the new port on the SmartEvent Server and on the Correlation Unit. 	
Correlation Unit
The Correlation Unit evaluates logs from the Log Server to identify events. Each log consists of data from Check Point products and third-party devices. It looks for threat patterns in this data that match the installed Event policy. When analyzing a log, the Correlation Unit performs one of the following actions:
Marks logs that individually are not events, but may be part of a larger pattern to be identified later
Generates an event based on the Event policy
Takes a new log entry that is part of a group of items that together make up an event, and adds it to an ongoing event
Discards logs that do not meet event criteria
Once a threat pattern is detected, the Correlation Unit forwards the event to the SmartEvent Server.
SmartEvent Correlation Units can analyze logs for more than one Log Server. Check Point recommends installing a Correlation Unit on each Log Server if your organization produces high volume log activity. With a small network, it is best practice to store a Correlation Unit on the SmartEvent Server. 
SmartEvent Server
The SmartEvent server houses the Events database. It receives all logs identified as events by the Correlation Unit. The SmartEvent server performs another analysis to determine the severity of the event and what action to take. The event is then stored in the Events Database. This database runs on Apache Solr, an open source search platform written in Java. The main advantage of Solr is that it manages the logs with their indexes, which in turn allows for a more efficient way to generate search results. 
<número>
 [Internal Use] for Check Point employees​
SmartConsole
SmartEvent GUI
SmartView
SmartEvent Clients
1
©2017 Check Point Software Technologies Ltd. 
SmartEvent Clients
SmartEvent clients manage the SmartEvent server and provide an overview of security informationfor an organization’s environment. They consolidate billions of logs and display them as prioritized security events. Administrators can use the information displayed to monitor network activity, identify and investigate critical events, and immediately respond to security incidents to prevent further attacks. 
SmartEvent clients are: 
SmartConsole — installed as an external application 
SmartEvent GUI — requires client installation
SmartView Web application — does not require client installation. It has the same real-time event monitoring and analysis views as SmartConsole. To log in to SmartEvent using SmartView Web application, browse to https://<Security Management Server IP Address>/smartview/ or https://<Security Management Server host name>/smartview/
Note: The SmartView Web application URL is case sensitive. The “/” at the end is required. SmartEvent must be enabled to view Smartview.	
<número>
 [Internal Use] for Check Point employees​
SmartEvent Workflow
1
©2017 Check Point Software Technologies Ltd. 
SmartEvent Workflow
The workflow below provides a high-level view on how the different SmartEvent components interact: 
Check Point products and other supported third-party devices forward logs to the Log Server for storage. The Correlation Unit reads all logs from the Log Server and makes the correlation analysis based on the SmartEvent policy. The Events policy resides on the Correlation Unit.
Once the Correlation Unit identifies a threat pattern, it identifies the associated log entries as an event and sends it to the SmartEvent Server. The SmartEvent server assigns a severity level to the event, invokes any defined automatic reactions, and adds the event to the Events Database that resides on the server. The severity levels and automatic reactions are defined in the Events Policy. An automatic reaction is the defined immediate course of action to a detected event. For example, an automatic email notice is sent to System Administrators once an event has occurred. This will be discussed further in the Remediating Security Event section of this chapter.
The SmartEvent client displays the received events. It presents all of the information needed for real-time monitoring of security events, event investigations, and remediation. Administrators can also utilize the SmartEvent client to generate reports, fine-tune and install the Events Policy. 
<número>
 [Internal Use] for Check Point employees​
Components can be installed as a standalone or distributed deployment.
Enable SmartEvent on the Security Management Server or deploy it on a dedicated server.
More than one Correlation Unit and Log Server can be installed.
Dedicated SmartEvent appliances are available.
Perform these actions before installation:
Use a dedicated server for SmartEvent that is connected to a management server.
Uninstall the old SmartEvent client before installing the new client.
Connect to a management server version R77.xx or higher.
SmartEvent Deployment
1
©2017 Check Point Software Technologies Ltd. 
SmartEvent Deployment 
SmartEvent components can be installed on a single machine (a standalone deployment), or spread out over multiple machines and sites (a distributed deployment). Implementing a distributed deployment is highly recommended if your organization anticipates a high volume of logging activity. 
Enable SmartEvent on the Security Management Server or deploy it on a dedicated server. You can also install more than one SmartEvent Correlation Unit. Each SmartEvent Correlation Unit can analyze logs from multiple Log Servers or Domain Log servers. Dedicated SmartEvent appliances from Check Point are also available as an option when deploying SmartEvent in your organization. A valid license or contract is required to deploy SmartEvent.
Before installation, make sure to perform the following actions: 
Use a dedicated server for SmartEvent that is connected to a management server. 
Do a clean installation. 
Uninstall the old SmartEvent client installed on computers, before installing the new client. 
Connect to a management server (Security Management Server or Multi-Domain Server), version R77.xx or higher. 
Note: Check Point recommends configuring Disk Space Management parameters to delete old log entries when available disk space is 45% or less. This configuration only applies to the raw log files and has no effect on the events database since it uses an internal disk space management policy.	
<número>
 [Internal Use] for Check Point employees​
The internal network must be defined.
Calculate the traffic direction using these options:
Incoming
Outgoing
Internal
Other
Certain objects from the Management server are added during the initial sync with the SmartEvent server.
Additional network and host objects may be added.
Defining the Internal Network
1
©2017 Check Point Software Technologies Ltd. 
Defining the Internal Network
To help SmartEvent determine whether events originated internally or externally, the internal network must be defined in the initial settings. There are four options to calculate the traffic direction:
Incoming — All the sources are outside the network and all destinations are inside.
Outgoing — All sources are inside the network and all destinations are outside.
Internal — Sources and destinations are all inside the network.
Other — A mixture of and internal and external values makes the result indeterminate
Note: It is recommended to add all internal network objects, not host objects.	
.
Adding Network and Host Objects
Certain objects from the Management server are added during the initial sync with the SmartEvent server and updated at a set interval. However, it may be necessary or useful to add other network or host objects to the internal network, such as:
If there are devices or networks not represented on the management server that are important for defining the internal network
When adding sources or destinations to exclusions or exceptions in event definitions
When selecting sources or destinations in a filter
<número>
 [Internal Use] for Check Point employees​
SmartEvent uses the following procedures to identify events:
Matching a log against global exclusions
Matching a log against each event definition
Creating an event candidate
Updating an event
Identifying an Event
1
©2017 Check Point Software Technologies Ltd. 
Identifying an Event
One of SmartEvent’s key features is its ability to identify a potential security incident or event from the multitude of logs that can be generated in an organization. As previously mentioned, events are detected by the Correlation Unit. SmartEvent is constantly retrieving logs from Log servers and searching for patterns. The Correlation Unit scans logs for criteria that match an event definition. SmartEvent uses the following procedures to identify events: 
Matching a log against global exclusions
Matching a log against each event definition
Creating an event candidate
Updating an event
<número>
 [Internal Use] for Check Point employees​
The Correlation Unit checks to see if the log matches any defined Global Exclusions.
Defined Global Exclusions direct SmartEvent to ignore logs that are not expected to contribute to an event.
Matching a Log Against Global Exclusions
1
©2017 Check Point Software Technologies Ltd. 
Matching a Log Against Global Exclusions 
When the Correlation Unit reads a log, it first checks whether the log matches any defined Global Exclusions. When Global Exclusions are defined, they direct SmartEvent to ignore logs that are not expected to contribute to an event. If a log matches a Global Exclusion, it is discarded by the system. If it does not match, the Correlation Unit begins matching the log against each event definition.
<número>
 [Internal Use] for Check Point employees​
An event definition may include different products.
Each product has its own criteria (set of values) for matching.
Matching a Log Against Each Event Definition
Matching Log
Matching Other Product Criteria1
©2017 Check Point Software Technologies Ltd. 
Matching a Log Against Each Event Definition
Each event definition contains a filter which is comprised of multiple criteria that must be found in any matching log. In turn, the criteria are divided by product. This means an event definition may include a number of different products, but each product has its own criteria (set of values).
For example, for a log from URL Filtering to match Event Definition A, it must match the Action, Event Type, Port, and Protocol values listed in the URL Filtering category. A log from a Security Gateway must match the values listed in its respective column. SmartEvent divides this process into two steps: 
The Correlation Unit first checks whether or not the product value in the log matches one of the acceptable product values of an Event Definition. For example, in the figure below, if Log 1 did not contain an acceptable product value, the Correlation Unit would then compare the log against the next Event Definition, and so on. If the log does not match any Event Definition, it is discarded.
Next, the Correlation Unit checks whether the log matches the product-specific criteria in an event definition. For instance, URL Filtering generates logs that involve the Firewall, spyware, malicious code protection, and others, which is populated in the Event Type field. If an event matches URL Filtering logs involving the Firewall, then the URL Filtering log involving spyware will fail against the Event Definition. Other criteria may be specific to the Product as well, such as action, port, and protocol.
Returning to the example, the Correlation Unit now examines whether the log contains the necessary criteria for a URL Filtering log to match. If the criteria did not match, the Correlation Unit would continue comparing the log criteria to other Event Definitions.
<número>
 [Internal Use] for Check Point employees​
Once a log matches the criteria, it is added to an Event Candidate.
Event Candidate allow SmartEvent to track logs until an event threshold is crossed and an event is generated.
Each event definition may have multiple event candidates.
Creating an Event Candidate
1
©2017 Check Point Software Technologies Ltd. 
Creating an Event Candidate
Once a log matches the criteria, it is added to an Event Candidate. Event Candidates allow SmartEvent to track logs until an event threshold is crossed, at which point an event is generated. An event threshold allows System Administrators to set the limits for logs to become an event. The limits typically are the number of connections, logs, or failures, and the period of time in which they occurred. An example of an event threshold would be: Detect the event when more than “x” (number value) connections/logs/failures were detected over a period of “y” (time value) seconds.
Note:
The Event Candidate can track logs from multiple Check Point and non-Check Point products.
Logs must originate from the same source IP address.
The Event Candidate tracks logs before all of the criteria have been matched.
Each event definition may have multiple Event Candidates existing simultaneously to keep track of logs grouped by similar properties, such as by host, service, destination, or any combination of these or others. In our example, the logs that form Event Candidate 10.1.1.5 all have a common source value and were dropped, blocked, or rejected by a Firewall. They are grouped together because the event definition is designed to detect activity originating from source address 10.1.1.5. 
<número>
 [Internal Use] for Check Point employees​
When a log matches an event definition but has properties which are different than the existing event candidates, a new event candidate is created and added to an event candidate pool.
Creating an Event Candidate
1
©2017 Check Point Software Technologies Ltd. 
Whenever a log matches the event definition but has properties different than those of the existing event candidates, a new Event Candidate is created and added to an Event Candidate Pool. SmartEvent creates a new Event Candidate for a log with a different source.
<número>
 [Internal Use] for Check Point employees​
The event candidate pool adds new logs and discards old logs when they have exceeded an event definition threshold.
Event candidates can be created by many event definitions.
Creating an Event Candidate
1
©2017 Check Point Software Technologies Ltd. 
The Event Candidate pool is a dynamic environment, with new logs being added and older logs being discarded when they have exceeded an event definition threshold. 
To illustrate further, consider the event defined to detect a high rate of blocked connections. SmartEvent tracks the number of blocked connections for each Firewall and the logs of the blocked traffic at each Firewall form an Event Candidate. When the threshold of blocked connection logs from any Firewall is surpassed, that Event Candidate becomes an event. 
While this event definition creates one Event Candidate for each Firewall monitored, other event definitions may create many more.
Updating an Event 
Discovering an event does not mean SmartEvent stops tracking logs related to the event. When a candidate becomes an event, the Correlation Unit forwards the event to the Event Database. The Correlation Unit will keep adding matching logs to the event as long as they continue to arrive, even if an event threshold has been reached. Keeping the event open condenses what might otherwise appear as many instances of the same event to one, and provides accurate, up-to-date information as to the start and end time of the event.
<número>
 [Internal Use] for Check Point employees​
When a candidate becomes an event, the Correlation Unit forwards it to the Event Database.
Matching logs are added to the event as long as they continue to arrive.
Updating an Event
1
©2017 Check Point Software Technologies Ltd. 
Updating an Event 
Discovering an event does not mean SmartEvent stops tracking logs related to the event. When a candidate becomes an event, the Correlation Unit forwards the event to the Event Database. The Correlation Unit will keep adding matching logs to the event as long as they continue to arrive, even if an event threshold has been reached. Keeping the event open condenses what might otherwise appear as many instances of the same event to one, and provides accurate, up-to-date information as to the start and end time of the event.
<número>
 [Internal Use] for Check Point employees​
Monitoring the Network
1
©2017 Check Point Software Technologies Ltd. 
Monitoring the Network
Administrators can use SmartConsole and SmartView Monitor to monitor network activity and identify, analyze, and manage security events.
Using SmartConsole Logs & Monitor 
SmartConsole includes a catalog of views and reports in the Logs & Monitor section of the GUI. Views and reports are customizable, allowing you to display and report the events and data that are most important to your network. For example, it may be important to monitor network traffic based on geography.
With a few clicks, you can easily move from a high-level view to a detailed forensic analysis of network activity. The free-text search option lets you quickly run data analysis and identify critical security events.
<número>
 [Internal Use] for Check Point employees​
Using SmartView Monitor
1
©2017 Check Point Software Technologies Ltd. 
Using SmartView Monitor
Use SmartView Monitor to respond quickly to changes in gateways, tunnels, remote users and traffic flow patterns and security activities. For example, remote employees of an organization report trouble connecting to the network. Using the SmartView Monitor Counter view, the administrator can assess that there are more failures to connect than successes. A report can be created to determine what is preventing the employees from connecting to the network. 
SmartView Monitor provides real-time and historical graphical views of:
Gateway statusRemote users 
System counters
VPN tunnels
Cooperative enforcement (for Endpoint Security Servers)
Traffic
<número>
 [Internal Use] for Check Point employees​
Event Queries
A view is an interactive dashboard made up of widgets.
Each widget is the output of a query.
Queries filter and organize the event data for display.
SmartConsole provides a predefined set of queries.
Event queries can be customized.
1
©2017 Check Point Software Technologies Ltd. 
Event Queries
A view is an interactive dashboard made up of widgets. A widget can display information in different formats such as a chart, or a table. Each widget is the output of a query. To review more about an event, double-click the widget to drill down to a more specific view or the raw log files.
Queries are used to define the events to see. These queries filter and organize the event data for display. SmartConsole provides a predefined set of queries which are organized by combinations of event properties. For example, a set of Threat Prevention queries will include Threat Prevention events as well as IPS events.
Event queries can be customized to display specific related events and treads as defined by the organization. Customized event queries can be created from scratch or based on an existing query.
Events are easily monitored using custom and predefined queries. To help identify suspicious patterns, use the following features to search and filter events:
Filters
Free-text search using Boolean operators, wildcards, fields, and ranges
Suggested and recent searches
Time Period
<número>
 [Internal Use] for Check Point employees​
Investigating Security Events
1
©2017 Check Point Software Technologies Ltd. 
Investigating Security Events
To further investigate an event, double-click the event to open the Log Details window. The Log Details window will provide important information regarding the event.
Packet Capture
When activated, packet capture files are sent from the Security Gateway to the log server, along with the log. Packet capture contents provide more insight into the traffic which generated the log. If any logs have related packet captures, open a packet viewer to see the contents of the captured packet.
Packet capture is activated by default. To see a packet capture, navigate to the Logs & Monitor view and open the log. Click the link in the packet capture field and the Packet Capture Viewer Output window will open. The packet capture may be saved to a file for further investigation.
<número>
 [Internal Use] for Check Point employees​
Default commands are: ping, whois, nslookup and Telnet.
Custom Commands
1
©2017 Check Point Software Technologies Ltd. 
Custom Commands
SmartEvent provides a convenient way to run common command line executables that can assist in investigating events. Right-clicking the IP address, source or destination, in an event provides a list of default and customized commands. They appear only on cells that refer to IP addresses, because the IP address of the active cell is used as the destination of the command when run. The default commands are ping, whois, nslookup, and Telnet. 
Importing Offline Log Files
System Administrators can import and examine logs from a previously generated log file. This makes it possible to review security threats and pattern anomalies that occurred before SmartEvent was installed. It enables the investigation of threats, such as unauthorized scans targeting vulnerable hosts, unauthorized legions, denial of service attacks, network anomalies, and other host-based activity.
The administrator can review logs from a specific time period and focus on deploying resources on threats that have been active for a period of time but may have been missed. For example, new events may have been dynamically updated and can now be processed over the previous period.
<número>
 [Internal Use] for Check Point employees​
Remediate security events by:
Configuring Event policy
Configuring IPS policy
Remediating Security Events
1
©2017 Check Point Software Technologies Ltd. 
Remediating Security Events
Once a security event is identified, investigated, and found to be a threat, remediate the issue by:
Configuring Event policy 
Configuring IPS policy
Configuring Event Policy
Use the Policy tab of the SmartEvent GUI client to configure and customize the events that define the Event policy. All events detectable by SmartEvent are organized by category under the Event Policy branch. 
Each event is enabled or disabled using the accompanying checkbox. Clearing the checkbox next to an event removes this event type from the Event policy the next time the Event policy is installed.
Depending on the thresholds defined in each Event, the number of events detected can be quite high. Yet, only a portion of those events may be meaningful. 
<número>
 [Internal Use] for Check Point employees​
It may be necessary to adjust or configure:
Threshold
Severity
Automatic reactions
Exceptions
Working hours
Remediating Security Events
1
©2017 Check Point Software Technologies Ltd. 
Selecting an event displays its configurable properties in the Detail pane and a description of the event in the Description pane. To remediate a security event, it may be necessary to adjust or configure:
Threshold
Severity
Automatic reactions
Exceptions
Working hours
Not all of these elements appear for every event. After installing and running SmartEvent for a short time, you will discover which of these elements needs to be fine-tuned per event.
Threshold
The Threshold setting sets the limits that, when exceeded, indicate an event has occurred. The limits typically consist of the number of connections, logs, or failures, and the period of time in which they occurred. 
Severity
An event severity determines in which queries, among those that filter for severity, this type of event will appear. The levels of severity are:
Informational
Low
Medium
High
Critical
Automatic Reactions
To jump start remediation, an event upon detection can trigger an automatic reaction. Multiple automatic reactions may be configured, depending on the needs of the system. For example, a single mail automatic reaction can be defined to inform the administrator of any event, or multiple mail automatic reactions can be configured to inform a different responsible party for each type of event. Automatic reactions may be created under General Settings.
There are five types of automatic reactions:
Mail — Alert a System Administrator by email that the event has occurred. 
Block Source — Instruct the Security Gateway to block the source IP address(es) from which this event was detected for a configurable period of time.
Block Event Activity — Instruct the Security Gateway to block a distributed attack that originates from multiple sources, or attacks multiple destinations for a configurable period of time.
External Script — Run a provided script.
SNMP Trap — Generate an SNMP Trap.
Exceptions
Exceptions allow an event to be independently configured for the sources or destinations that appear. For example, if the event Port Scan from Internal Network is set to detect an event when 30 connections have occurred within 60 seconds, define that two port scans detected from host A within 10 seconds of each other is also an event.
Working Hours
Working hours are used to detect unauthorized attempts to access protected systems and other forbidden operations after-hours. To set the Regular Working Hours for an event, select a Time object from the drop-down menu. Time objects are configured under General Settings.
<número>
 [Internal Use] for Check Point employees​
Go to the Check Point Advisory article.
Review a detailed IPS protection description.
Fine-tune the IPS protection.
Add an exception to the IPS protection.
Configuring IPS Policy
1
©2017 Check Point Software Technologies Ltd. 
Configuring IPS Policy
IPS protections and profiles should be reviewed to understand why an event was generated. Administrators may also review the eventsto investigate how traffic is handled by IPS. Any event generated by the IPS Software Blade is easily investigated and remediated through the Event Details window. From the Event Details window, you can:
Go to the Check Point Advisory article which provides background information about the IPS protection.
Review a detailed IPS protection description.
Fine-tune the IPS protection.
Add an exception to the IPS protection.
<número>
 [Internal Use] for Check Point employees​
To report Security Events: 
use predefined reports, or
define custom reports.
Reporting Security Events
1
©2017 Check Point Software Technologies Ltd. 
Reporting Security Events
Reports make it easy to quickly generate, review, and share security data using graphs and data tables. They provide more detailed information than a view. Predefined and customized reports can be generated to provide security information on a schedule (daily, weekly, or monthly), or as needed. For example, an executive may request a monthly security brief on the most recent security trends to evaluate company policy and procedure, such as allowing employees to access particular sites and applications during work hours.
Using Predefined Reports 
Use predefined graphical report templates for the most frequently seen security issues. To open the catalog of predefined and customized reports, click the [+] tab. Double-click a report to open it. SmartEvent automatically downloads new predefined reports, and updates existing reports.
Importing and Exporting Reports
 The Export to PDF and Export to Excel options allow you to save the current report as a PDF or Excel file, based on the defined filters and time period. Report layout and widget definition templates can also be exported. Similarly, the Import Template option allows you to import these template files from another server, or from another administrator.
Adding a Logo to Reports 
By default, the Check Point logo shows on the cover pages of the report. System Administrators can configure reports to show their company logo instead. Save the image file of the logo as a PNG file with the name cover-company-logo.png then copy the image to the $RTDIR/smartview/conf directory on the SmartEvent server. 
Defining Custom Reports 
Because each company is different, SmartEvent helps System Administrators to create custom-made reports that fit their respective organization. To customize a report, select a predefined or custom report, then click Edit to define the new report. 
Defining the Report Outline and Filters 
The workspace shows Views on the left when you edit a report. A view is an interactive dashboard made up of widgets. It is also a section of the report shown in one page or multiple pages, if it includes a table. The Views pane has management controls that help you add, remove, change the sequence of views, and even add filters for the data included in the report. Changes to views is only applied to the custom report that you are working on. 
Defining Views 
When you click a particular View thumbnail, it shows the widgets included in that view. A widget is a representation of the collected data. Each widget is contained in a panel with management options that allow you to add, remove, move, or resize a widget. Note that moving or resizing the widget out of the page borders is not possible. For table layouts that expand to multiple pages, select Show all table rows from the Split table across multiple pages window on the View Settings option. 
Note: The desired graphical view of your organization’s security posture can be quickly customized by adding a widget to a view. Before adding a widget, make sure that the view has enough space; otherwise an error message will appear.
Filtering Reports by User Groups 
System Administrators may need to generate several reports for different key stakeholders. A report meant for a C-level executive may contain information not relevant to a department head. Reports, views and widgets can be filtered for one or more Active Directory user groups.
Prior to enabling this feature, an Access Role object that includes the AD groups to use in the query for the report must be defined. To filter reports for specific user groups, look at the Identity Awareness login logs, and copy the names of the relevant groups. Add a filter for the User Group field and enter the name of the group to be included in the filter. For multiple groups, use a comma-separated list.
<número>
 [Internal Use] for Check Point employees​
Take preventative actions by creating a new event definition.
Use the Event Definition Wizard to configure the new event definition from scratch or based on an existing event.
Preventative Measures
1
©2017 Check Point Software Technologies Ltd. 
Preventative Measures
After remediating security events, preventative measures can be put in place to ensure the event is addressed as soon as possible and prevented from repeat occurrence. 
Creating a New Event Definition
Once a new threat is discovered and remediated, take preventative action by creating a new event definition. The next time this threat pattern is detected, it will create an event in the Events database, allowing it to be addressed and remediated more quickly. The Event Definition Wizard makes it easy to configure a new event definition from scratch or based on an existing event. 
When creating a new definition, the Event Definition Wizard allows you to choose if an event will be generated when an event definition is matched by a single log or multiple logs. It also gives you options to choose which of the product(s) can trigger an event. All user defined event definitions are automatically saved in the User Defined Events folder in the Selector Tree. 
<número>
 [Internal Use] for Check Point employees​
Helps to improve the IPS technology.
Sent over a secure SSL connection.
Data is kept confidential.
Reporting an Event to Check Point
1
©2017 Check Point Software Technologies Ltd. 
Reporting an Event to Check Point
Reporting event data to Check Point can help Check Point improve the IPS technology to detect new threats. Only the event information will be sent to Check Point over a secure SSL connection. The data is kept confidential and Check Point only uses the information to improve IPS.
<número>
 [Internal Use] for Check Point employees​
Services and protocols that could potentially generate events:
Software that performs a routine scan of the network.
High connection rate on a web server.
To eliminate false positives, change the thresholds and other criteria of an event.
Eliminating False Positives
1
©2017 Check Point Software Technologies Ltd. 
Eliminating False Positives
To eliminate false positives, it is important to understand how a false positive might be generated. Certain types of services are characterized by a high amount of traffic that could be misidentified as events. The following are examples of services and protocols that could potentially generate events.
Software that performs a routine scan of the network to make sure that everything is running properly. 
A high connection rate on a web server. SmartEvent should be set to allow a higher connection rate per minute on a busy web server, or to exclude this source from a scan event.
Refer to the Check Point Logging and Monitoring Administration Guide for a list of server types where high activity is common. Modify the Event policy by adjusting event thresholds and adding Exclusions for servers and services, to further reduce the amount of false positives detected.
To eliminate false positives, change the thresholds and other criteria of an event. For example, increase the number of connections, logs, or failures and/or the period of time for them to occur.
<número>
 [Internal Use] for Check Point employees​
Issue: The network is flooded with connections on a specific interface.
Steps taken:
Activate all port scan events in the Event policy to generate logs and investigate the source and destinationof events coming into the interface.
Remediate by creating a new rule that blocks traffic from the illegitimate sources found during the investigation.
Create an automatic reaction to notify the team.
SmartEvent Example
1
©2017 Check Point Software Technologies Ltd. 
SmartEvent Example
While monitoring the network, you notice the network is flooded with connections. This merits an investigation. Using the filters, queries, and search bar features, you browse the event database and determine that the gateway is stable. However, it is the interface that has received lots of connections. 
To start the investigation process, navigate to the Policy tab and activate all port scan events in the Event policy to generate logs. After installing Event policy and additional traffic flowing into the interface, many port scan events are created. Upon reviewing the details of multiple events, it is evident that there is only one source and one destination. This is unusual as legitimate port scans will have multiple source or destination IP addresses. One source and one destination IP address indicates that this may be a targeted attack. After investigating the source IP addresses and narrowing down the type of device they are originating from, the conclusion is that the traffic is not legitimate. 
To begin remediation, in SmartConsole, create a new rule that blocks traffic from the illegitimate sources. If the traffic was legitimate, navigate to the Policy tab to configure the settings for the Port scan from external network event. Add the IP address as an exception to prevent port scans from this IP address from generating an event. Another option is to edit threshold settings to increase the number of connections, or expand the time period in which the connections occur.
The next step is prevention. Navigate to the Port scan from external network event. Create an automatic reaction that will email the entire IT team when at least 20 connections are detected within sixty seconds (one minute). By doing this, the next time there is a flood of traffic on an interface, the entire IT team is notified and can quickly address and remediate the event. 
With SmartEvent, it was easy to quickly search and filter through events to discover the problem, enable the appropriate event policy, review specific threat information, and institute preventative measures. By creating automated alerts and rules, you will ensure that the network is able to perform without being bogged down by unnecessary traffic.
<número>
 [Internal Use] for Check Point employees​
dbsync allows SmartEvent to work independently from different management versions and management servers in an HA environment.
A gateway, upon failure, can be configured to send its logs to a secondary Log server.
Multiple Correlation Units can read logs from the same Log servers, and provide redundancy if one of them fails.
High Availability Environment
1
©2017 Check Point Software Technologies Ltd. 
High Availability Environment
The SmartEvent database maintains a synchronized copy of management objects locally on the SmartEvent server. This process, also known as dbsync, allows SmartEvent to work independently from different management versions and different management servers in a High Availability environment.
Management High Availability exists for Security Management Servers and in a Multi-Domain Security Management environment. The dbsync process supports High Availability for the Multi-Domain servers and the Domain servers.
The dbsync process initially connects to the management server with which SIC is established. It retrieves all the objects and, after the initial synchronization, it gets updates whenever an object is saved. At this point, dbsync registers all the High Availability management machines and periodically tests the connectivity with the current management server. If connectivity is lost, it attempts to connect to the other High Availability management servers until it finds an active one and connects to it.
If two management servers are active concurrently, dbsync will remain connected to one and it will not receive any changes made on the other management server until a synchronization operation is performed.
Log Server High Availability
In SmartConsole, it is possible to configure a Security Gateway such that when it fails to send its logs to one Log server, it will send its logs to a secondary Log server. To support this configuration, it is possible to add both Log servers to a single Correlation Unit. In this way, the Correlation Unit will get an uninterrupted stream of logs from both servers and will continue to correlate all Firewall logs.
SmartEvent Correlation Unit High Availability
Multiple Correlation Units can read logs from the same Log servers, providing redundancy if one of them fails. The events detected by the Correlation Units will be duplicated in the SmartEvent database. These events can be ascertained by filtering with the Detected By field in the Event Query definition. The Detected By field specifies which Correlation Unit detected the event. The SmartEvent server becomes unavailable, the Correlation Units retain the events until they can reconnect with the SmartEvent server and forward the events.
<número>
 [Internal Use] for Check Point employees​
Security CheckUp
1
©2017 Check Point Software Technologies Ltd. 
Security CheckUp
With Check Point Security Checkup tools, administrators can generate a comprehensive security analysis report that summarizes security events, their risks, and remediation. These reports are mainly used for Proof of Concept (PoC) purposes. The Security CheckUp Advanced and Anonymizer Reports are threat analysis reports that generate charts and organize security data to display key findings on malware, attacks, data loss, and high risk web access. SmartEvent must be activated before running the Security CheckUp reports and the tool is installed as a supplement. The difference between SmartEvent reports and the Security CheckUp reports is that the Anonymizer report does not use IP addresses or usernames.
Each report can be localized into any language and customized to display information from a specific time period or filter preferences. Like other reports, Security CheckUp reports can be generated on a schedule or as-needed basis and saved as a PDF or Excel file for the purpose of information sharing and security event investigation.
<número>
Chapter 5 Review Questions
What are the main components of the SmartEvent Architecture?
Check Point Security Gateway
Log server
Correlation unit
SmartEvent server
Events database
SmartEvent client
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 5 Review Questions
Explain how SmartEvent identifies an event.
SmartEvent retrieves logs from Log servers and searches for patterns. The Correlation Unit scans logs for criteria that match an event definition. SmartEvent uses the following procedures to identify events: 
Match a log against global exclusions
Match a log against each event definition
Create an event candidate
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 5 Review Questions
How would a System Administrator reduce the number of false positives?
To eliminate false positives, change the thresholds and other criteria of an event. For example, increase the number of connections, logs, or failures and/or the period of time for them to occur.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Configure a SmartEvent server to monitor relevant patterns and events.
Demonstrate how to configure event Alerts in SmartEvent.
Demonstrate how to run specific SmartEvent reports.
Lab 5.1: Evaluating Threats with SmartEvent
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
Remote and mobile access
06
[Restricted] ONLYfor designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Recognize Check Point Remote Access solutions and how they differ.
Discuss Check Point Capsule components and how they work to protect mobile devices and business documents.
Discuss the Mobile Access Software Blade and how it secures communication and data exchange during remote connections.
 
Remote and Mobile Access
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
In today’s business environment, employees need to connect to company applications and data from offsite locations. Remotely connecting to corporate resources has security issues that System Administrators need to address. This chapter discusses Check Point Remote and Mobile Access solutions that protect an organization’s confidential communications and data in the age of workforce mobility. 
<número>
 [Internal Use] for Check Point employees​
Client-Based or Clientless?
Secure Connectivity or Endpoint Security?
SSL VPN versus IPSec
Choosing Remote Access Solutions
1
©2017 Check Point Software Technologies Ltd. 
Choosing Remote Access Solutions
All Check Point Remote Access solutions provide secure connectivity to corporate resources. Strong user authentication methods and granular access control reinforce network security. Check Point Remote Access solutions use IPSec and Secure Socket Layer (SSL) encryption protocols to create secure connections. All Check Point clients can work through NAT devices, hotspots, and proxies in situations with complex topologies, such as airports or hotels. 
There are a few factors to consider when choosing remote access solutions for your organization:
Client-Based or Clientless: Does the solution require a Check Point client to be installed on the endpoint computer or is it clientless, for which only a web browser is required? Multiple solutions may be required within your organization to meet different needs.
Secure Connectivity or Endpoint Security: Does the solution just require secure connectivity, whereas traffic is encrypted between the client and the VPN gateway, or endpoint security that provides protection even when there is no connectivity to the network?
SSL VPN versus IPSec VPN: Does your organization need a full VPN tunnel to protect the access from any installed application to the business or does it need a simpler business portal for secure access?
<número>
 [Internal Use] for Check Point employees​
Cloud-based – Client application installed on endpoint computers and devices.
Clientless – Users connect through an web browser.
On Demand Client – Users connect with a web browser and installs a client when necessary. 
Installation Types
1
©2017 Check Point Software Technologies Ltd. 
Installation Types
There are three types of installations for remote access solutions:
Client-based — In this solution, the client application is installed on endpoint computers and devices. Clients are usually installed on a managed device, such as a company-owned computer or device. The client supplies access to most types of corporate resources according to the access privileges of the user.
Clientless — In this solution, users connect through a web browser and use HTTPS connections instead of connecting through a managed device. Clientless solutions usually supply access to web-based corporate resources.
On Demand Client — This remote access solution blends the first two options. A user connects with a web browser and installs a client when necessary. The client supplies access privileges to most types of corporate resources according to the access privileges of the user.
<número>
 [Internal Use] for Check Point employees​
With secure connectivity, traffic is encrypted between the client and VPN gateway. Users can access resources after they authenticate.
Endpoint security ensures that devices connecting to the gateway meet security requirements. The devices are protected at all times.
Secure Connectivity and Endpoint Security
1
©2017 Check Point Software Technologies Ltd. 
Secure Connectivity and Endpoint Security
Secure connectivity can be combined with additional features to protect the network or endpoint computers. With secure connectivity, traffic is encrypted between the client and VPN gateway and strong user authentication is supported. After users authenticate, they can access the corporate resources that are permitted to them in the access policy. All Check Point remote access solutions supply secure connectivity and require licenses.
Security verification for endpoint computers makes sure that devices connecting to the gateway meet security requirements. Endpoint machines that are not compliant with the Security Policy have limited or no connectivity to corporate resources. Some Check Point solutions supply this.
In terms of Endpoint Security, endpoint computers are protected at all times, even when there is no connectivity to the corporate network. An integrated desktop Firewall protects endpoint computers at all times with a centrally-managed Security Policy. This is important because remote clients are not in the protected network and traffic to clients is only inspected if a desktop Firewall is present. Some Check Point solutions supply this. These solutions require licenses based on the number of clients installed.
Note: Check Point solutions can include more Endpoint Security capabilities, such as Anti-Malware and disk encryption.	
<número>
 [Internal Use] for Check Point employees​
SSL VPN versus IPSec (Layer 3) VPN
1
©2017 Check Point Software Technologies Ltd. 
SSL VPN versus IPSec (Layer 3) VPN
Check Point solutions provide enterprise-grade access via both Layer 3 (IPSec) and SSL VPN. There is a fundamental difference in how an SSL VPN Portal and a Layer 3 VPN tunnel connect to the corporate network. In a Layer 3 VPN solution, a resident VPN client is needed, which creates the Layer 3 virtual interface that any application can use. SSL VPN solutions only require a browser on the client side and allow mobile devices with a dedicated application to access corporate resources without establishing a VPN tunnel. 
In an SSL VPN solution, users can connect securely to business web-based applications through a web portal. This solution does not require users to install a VPN client. SSL VPN is the recommended solution for unmanaged and personal devices used for business purposes. 
Layer 3 VPN solutions require remote workers to install a VPN client before gaining access to corporate resources. Once a user installs the client, the Layer 3 VPN tunnel provides a secured connection to both web-based and native business applications. This is recommended for corporations with employees using managed or unmanaged devices. 
Both solutions can be configured to enforce two-factor authentication. 
<número>
 [Internal Use] for Check Point employees​
A clientless SSL VPN solution.
Does not require users to install a VPN agent or client.
Provides secure connectivity and security verification.
Requires a Mobile Access Software Blade license.
Clients - Mobile Access Portal
1
©2017 Check Point Software Technologies Ltd. 
Clients 
All Check Point Remote Access options provide secure remote access to corporate resources. Each has different features and meets different organizational requirements.
Mobile Access Portal 
The Mobile Access Portal, a clientless SSL VPN solution, is recommended for users who want to access corporate resources from any unmanaged computer or device. This solution does not require users to install a VPN agent or client. The Mobile Access Portal provides secure connectivity and security verification. It requires a Mobile Access Software Blade license on the Security Gateway. Remote users log in to the portal using an authentication scheme configured for that Security Gateway. The Mobile Access policy applies to the Mobile Access Portal. The portalcan also be used with managed devices.
The Mobile Access Portal supplies access to web-based corporate resources. The on-demand client, SSL Network Extender, can be used to access all types of corporate resources. 
Note: Each Security Gateway enabled with Mobile Access leads to its own Mobile Access User Portal. Set up the URL in the Mobile Access First Time Wizard. For portal customization, System Administrators can go to Portal Customization under Mobile Access in the SmartConsole. 	
<número>
 [Internal Use] for Check Point employees​
A thin SSL VPN on-demand client automatically installed on the remote user’s machine through a web browser.
Requires Mobile Access and IPSec VPN Software Blade licenses.
Two modes:
Network
Application
Clients - SSL Network Extender
1
©2017 Check Point Software Technologies Ltd. 
SSL Network Extender
SSL Network Extender (SNX) is a thin SSL VPN on-demand client that is automatically installed on the remote user's machine through a web browser. This VPN client is installed as a browser plug-in. Once installed, it enables a secured connection using the SSL VPN tunnel to link users to the corporate resources. SSL Network Extender requires Mobile Access and IPSec VPN Software Blade licenses on the Security Gateway.
SSL Network Extender has two modes:
Network — Users can access all native IP-based and web-based applications in the internal network. For users to gain access to these applications, System Administrators must first define these as native applications in Mobile Access. The user can access the resources by launching the client either from the desktop or the Mobile Access portal. To work in Network mode, users must have installation privileges.
Application — Users can access most native IP-based and web-based application types in the internal network, including most TCP applications. Users can only launch the client in the Mobile Access portal. Once installed, users can access internal resources defined as native applications in Mobile Access. Working in Application mode does not require installation privileges.
<número>
 [Internal Use] for Check Point employees​
Offers remote access options for:
Check Point Mobile for Windows
An IPSec VPN client.
Requires IPSec VPN and Mobile Access Software Blade licenses.
Check Point Mobile for iPhone and iPad 
An SSL VPN client.
Requires a Mobile Access Software Blade license.
Check Point Mobile for Android
An SSL VPN client.
Requires a Mobile Access Software Blade license.
Clients - Check Point Mobile
1
©2017 Check Point Software Technologies Ltd. 
Check Point Mobile
Check Point Mobile offers an remote access option for several different platforms. 
Check Point Mobile for Windows — An IPSec VPN client solution for medium to large enterprises that do not require an Endpoint Security Policy. It provides both secure connectivity and security verification. This option requires both IPSec VPN and Mobile Access Software Blade licenses.
Check Point Mobile for iPhone and iPad — An SSL VPN client which supplies secure connectivity and access to web-based corporate resources and Exchange ActiveSync. This option is best used for mobile workers who have iOS mobile devices. A Mobile Access Software Blade license is required for this option.
Check Point Mobile for Android — An SSL VPN client for Android device users. It supplies secure connectivity and access to web-based corporate resources and Exchange ActiveSync. A Mobile Access Software Blade license is required for this option. 
<número>
 [Internal Use] for Check Point employees​
Check Point Capsule Workspace
An SSL VPN client for mobile devices.
A Check Point Capsule license is required on the Security Gateway.
SecuRemote
A limited function IPSec VPN client that only provides secure connectivity.
An IPSec VPN Software Blade license is required.
Additional Client Options**
**Refer to sk67820 for more detail information regarding Remote Access solutions and options.
1
©2017 Check Point Software Technologies Ltd. 
Check Point Capsule Workspace
Capsule Workspace is an SSL VPN client for mobile devices that provides remote users seamless access to a separate, secure business environment. A Check Point Capsule license is required on the Security Gateway. This solution is further discussed in the Check Point Capsule Solution section. 
SecuRemote
SecuRemote is a limited-function IPsec VPN client that only provides secure connectivity. SecuRemote is a free client and only requires an IPSec VPN Software Blade license on the Security Gateway.
Additional Remote Access Options
Check Point offers additional Remote Access options, including options specifically for Endpoint Security. For more detail information regarding Remote Access solutions and options, refer to sk67820.
<número>
 [Internal Use] for Check Point employees​
Addresses mobile access needs.
Securely protects devices from threats.
Protects business documents wherever they go.
Uses three components:
Capsule Workspace
Capsule Docs
Capsule Cloud
Check Point Capsule
1
©2017 Check Point Software Technologies Ltd. 
Check Point Capsule 
Check Point Capsule addresses mobile access needs by securely protecting devices from threats and protecting business documents wherever they go, all while providing a secure business environment for mobile devices. Mobile Threat Prevention is further discussed in the Threat Prevention chapter.
Check Point Capsule secures remote communication and data exchange using three components: Capsule Workspace, Capsule Docs and Capsule Cloud. 
<número>
 [Internal Use] for Check Point employees​
Provides a secure login.
Easy access to business applications and documents, including corporate email, contacts, and calendars.
Use and store business data and documents within a secure container.
Allows employees to use their personal devices.
Only business data is under corporate IT control.
 
Capsule Workspace
1
©2017 Check Point Software Technologies Ltd. 
Capsule Workspace
Using Capsule Workspace, mobile users are provided a secure login with easy access to business applications, exchange applications, and documents. This solution allows employees working remotely to securely connect to the network and easily use and store business data and documents within the application’s security container. Users have access to corporate email, files, directories, corporate contacts, and calendars. Capsule Workspace allows company employees to use their personal devices for work-related tasks yet place only business data under control of the corporate IT team. With Capsule Docs integration and an application-level passcode, business data is protected everywhere. Capsule Workspace also features offline data encryption, policy and remote wipe, and sharing control. With Capsule Workspace, organizations can enhance the productivity of employees while securing the use of personal devices and protecting business data.
Key benefits include:
One application is used to access business information, providing segregation between personal and professional on the device.
Provides a great end-user experience with push notifications, document editor, HTML5, and more. 
Provides an end-to-end solution with no compromise on security, from Microsoft Exchange to the mobile device.
Capsule Workspace also has a remote data wiping feature, to delete the stored offline data after each session. This may be useful when a user certification has been revoked, when a device is lost, or an employee leaves the company.
<número>
 [Internal Use] for Check Point employees​
Works with Capsule Workspace to provide access to native applications.
Key features include:
Full Layer 3 VPN client
Works in the background
On Demand (iOS)/ Always On (Android)
Supports all VPN authentication methods
Infrastructure for Capsule Cloud
Capsule Connect
1
©2017 Check Point Software Technologies Ltd. 
Capsule Connect 
Capsule Connect complements Capsule Workspace to provide access to native applications.
Key features include:
Full Layer3 VPN client
Works in the background
On Demand (iOS / Always On (Android)
Supports all VPN authentication methods
Infrastructure for Capsule Cloud
Typical user case scenarios include:
Corporate applications using native applications
Non HTML5 Remote Desktop Solutions
Corporate mail using Native Clients
<número>
 [Internal Use] for Check Point employees​
		Connect	Workspace
	VPN Type	IPSec VPN (Layer 3)	SSL VPN
	Applications	Any application	Secure browser, including remote terminal viewing
ActiveSync provisioning
Exchange applications and push notifications
Document viewing and editing
Roadmap: Chat, SharePoint
Roadmap: Third-party applications
	Operating system	iOS, Android, WP8	iOS, Android
	Business data isolation	None	Application-level passcode
In-app encryption
Remote wipe
Offline data policy
Document sharing control (allow/block/encrypt on-the-fly)
	Credential protection	One-Time Password (OTP) login support
No SSO support	OTP login support
SSO for Workspace apps
	Compliance/host checking	MDM cooperative enforcement	Jailbreak/root detection
MDM cooperative enforcement
How Capsule Connect and Capsule Workspace Differ
1
©2017 Check Point Software Technologies Ltd. 
How Capsule Connect and Capsule Workspace Differ
Capsule Connect and Capsule Workspace both offer secured connection for remote users who are using their mobile devices. However, there are differences between the two.
<número>
 [Internal Use] for Check Point employees​
Secures documents with these capabilities:
Classify – define a set of permissions.
Share – decide with whom to share the document.
Encrypt – apply encryption so that it is protected and only accessed by authorized users and groups.
Content is encrypted with a symmetric key.
The Content Encryption Key can be accessed with one of the following:
The Master Key (RSA 2048)
The Classification Key (RSA 2048) and the User/Group Key (RSA 2048)
Capsule Docs
1
©2017 Check Point Software Technologies Ltd. 
Capsule Docs
The rise of user collaboration and file sharing platforms may lead to security issues, such as information theft and data leakage. Capsule Docs avoids these issues by securing the actual document with the following capabilities:
Classify — Define a set of permissions, which may include markings such as headers, footers, and watermarks.
Share — Decide with whom to share the document.
Encrypt — Apply encryption (AES256 + RSA2048) to the document so that it is protected and accessed only by the authorized users and groups.
Once files are protected, users can store the document anywhere and share them on different platforms. Capsule Docs secures the document contents regardless of where it is kept or with whom it is shared. In the event an attacker obtains the document, the content of the document is encrypted and not accessible to unauthorized users. 
Capsule Docs does not require users to have an additional password because it uses Active Directory credentials for authentication.
Users and System Administrators can share a document with an external user by adding the recipient’s email address to the list of authorized users. On the first attempt to access the document, the external user will be asked to install either a viewer or editor client and register in the system. This registration is fast and required only once. 
Capsule Docs also logs any action performed by end users, such as when they add a new user to the authorized list or when they remove the document’s protection. This can be helpful for you when auditing and monitoring proprietary documents. 
Content Encryption
Document content is encrypted with a symmetric key. AES 256 is used for an On-Premise deployment, and AES 128 is used for a Cloud deployment. The Content Encryption Key is generated by the client and encrypted with asymmetric keys generated by the management server. The Content Encryption Key can be accessed with one of the following:
The Master Key (RSA 2048)
The Classification Key (RSA 2048) and the User / Group Key (RSA 2048)
<número>
 [Internal Use] for Check Point employees​
The Cloud stores community encryption keys, users, policy settings, and audit logs.
Cloud Deployment
1
©2017 Check Point Software Technologies Ltd. 
Cloud Deployment 
Capsule Docs in the Cloud is the best option for organizations that prefer not to deploy an additional server. In this setup, the Cloud stores community encryption keys, users, policy settings, and audit logs. LDAP is used to manage users in a Cloud deployment. User registration is done through the Capsule Web Portal and authentication is done against LDAP.
<número>
 [Internal Use] for Check Point employees​
Cloud-based service that helps an enterprise to protect employees using laptops and mobile devices when outside of the secured office environment.
Enforces the organization’s Security policy to devices, both on- and off-premises.
Network traffic coming from and going to remote devices are directed to Capsule Cloud through a secure tunnel.
Capsule Cloud
1
©2017 Check Point Software Technologies Ltd. 
Capsule Cloud
Capsule Cloud utilizes Check Point Software Blade solutions as a cloud-based service. Capsule Cloud enforces the organization’s in-network Security Policy to both on- and off-premise devices. It helps the enterprise to protect employees using laptops and mobile device when they are outside the secured office environment. This is the best option for organizations with multiple satellite offices and remote branches. For smaller companies and individual users, the Capsule Connect client can be installed on their devices to connect to Capsule Cloud for security.
To protect communication between locations, any network traffic coming from and going to remote devices are directed to the Capsule Cloud through a secure tunnel. Capsule Cloud then inspects the traffic based on the Security Policies implemented by the corporate office. Capsule Cloud employs Check Point Security solutions, such as Anti-Bot, Antivirus, Application Control, IPS, and URL Filter. 
Connecting a gateway to Capsule Cloud is more efficient compared to installing the policies locally, as this set up requires lower machine resources. Security Gateways with limited capabilities can also access and employ more software blades in Check Point Capsule Cloud. 
<número>
 [Internal Use] for Check Point employees​
Set up policies for URL Filtering, Threat Prevention, and HTTPS Inspection.
View user traffic and audit logs.
Manage users and offices.
Download Capsule Cloud applications and utilities.
Change client and device settings.
Determine location of roaming clients
Cloud Portal
1
©2017 Check Point Software Technologies Ltd. 
Cloud Portal
Administrators can manage and apply policies for both on-premise or off-premise devices using SmartConsole or the Capsule Cloud web user interface. Cloud Portal is the Capsule Cloud WebUI. Use Cloud Portal to:
Set up policies for URL Filtering, Threat Prevention, and HTTPS Inspection 
View user traffic and audit logs
Manage users and offices
Download Capsule Cloud applications and utilities
Change client and device settings
Access Capsule Cloud utilities 
Determine location of roaming clients (via the Location Awareness feature)
Network administrators with access to the Cloud Portal can have either Administrator or Help Desk access privileges. Administrators with Administrator privileges can view all tabs and perform all operations in the Cloud Portal, while those with Help Desk rights are only allowed to manage users and devices. Offices are corporate gateways that connect to Capsule Cloud through a VPN. The gateway forwards traffic to Capsule Cloud where traffic is inspected based on the Security Policies enforced. 
To connect a device to Capsule Cloud, you must create a VPN Site-to-Site community between the two. The New Office Wizard will help you to set up this community in the Cloud Portal and the local gateway management. 
<número>
 [Internal Use] for Check Point employees​
Location Awareness
1©2017 Check Point Software Technologies Ltd. 
The Location Awareness feature gives administrators the option to limit access to Capsule Cloud to external users. In this option, users with IP addresses or domains and ports within the internal network will not be allowed to connect to Capsule Cloud. 
<número>
 [Internal Use] for Check Point employees​
A comprehensive remote access solution.
Integrates into an existing Check Point gateway.
Provides user authentication and the ability to check the security posture of the remote device.
Mobile Access Software Blade
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Software Blade
Today’s business environment may require employees, contractors, and other knowledge workers to access corporate resources from remote locations. Without the proper security measures, you risk credential loss, unauthorized access, data loss and leakage, malware break-in and propagation, and more.
The Check Point Mobile Access Software Blade is a comprehensive remote access solution that allows mobile and remote workers to easily and securely connect to the corporate network from any location, with any supported device, while protecting the network, remote users and mobile devices, from threats. 
This Software Blade integrates into an existing Check Point gateway, enabling a more secure and operationally efficient remote access for your users. The data transmitted by remote access is decrypted, filtered, and inspected in real-time by Check Point’s gateway security services. It applies Secure Socket Layer (SSL) and IPSec (also known as Layer 3) VPN protocols to remote connections to ensure that the communication and data are encrypted. 
The Mobile Access Software Blade also provides user authentication and the ability to check the security posture of the remote device. This further strengthens the security for remote access. The Mobile Access solution also guarantees authenticity by using standard authentication methods such as Certificates, RADIUS, SecurID, and Dynamic ID to transfer information and data. 
<número>
 [Internal Use] for Check Point employees​
Guides you through the different configuration settings.
Helps to configure:
Mobile Access methods
The Mobile Access portal
Applications
Mobile Access Wizard
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Wizard
When enabling the Mobile Access Software Blade on a gateway, the Mobile Access Wizard will guide you through the different configuration settings. It also quickly allows authorized remote users to access internal web or mail applications through a web browser, mobile device, or remote access client. The Mobile Access Wizard helps to configure such settings as the mobile access methods, the primary URL for the Mobile Access Portal, and the applications that will be available to web or mobile device users.
Note: Once Mobile Access is enabled, it uses HTTPS 443. This is the same SSL port as the Gaia Web portal. To prevent conflict, change the Gaia Web portal port to a different port, for example TCP port 4434, and add an access rule to the Firewall policy to allow the new port. 	
<número>
 [Internal Use] for Check Point employees​
Web – through a browser on any computer
Mobile Devices – through an iOS or Android mobile device
Desktops/Laptops 
Mobile Access Methods
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Methods
The Mobile Access Methods section of the wizard allows you to select from where users can access the Mobile Access applications:
Web — Through a browser on any computer. SSL Network Extender can be downloaded by users when necessary to access native applications.
Mobile Devices — Through an iOS or Android Mobile device. Devices must have a Check Point application installed.
Capsule Workspace — Through a secure container on the mobile device to give users access to internal websites, file shares, and Exchange servers.
Capsule Connect/VPN — Through a full Layer 3 tunnel application that gives users network access to all mobile applications.
Desktops/Laptops — Check Point clients for PCs and Macs that use a Layer 3 tunnel to provide access to internal network resources.
Web Portal
The primary URL for the Mobile Access Portal will need to be specified. The default is https://<IP address of the gateway>/sslvpn. It is possible to use the same IP address for all portals on the gateway with a variation in the path. A PFX (.p12) file can be imported to obtain a trusted certificate. A PFX file is the combined format that holds the private key and certificate. All portals on the same IP address will use the same certificate.
<número>
 [Internal Use] for Check Point employees​
Web applications
Demo Web Application (World Clock)
Custom Web Application
Mail/Calendar/Contacts
File Shares
Citrix Services
Native Apps
Applications
1
©2017 Check Point Software Technologies Ltd. 
Applications
Mobile Access provides the remote user with access to various corporate applications. The wizard allows you to select the applications that will be available to web or mobile device users:
Web Applications — Select the web applications that users can access. The applications will show on the Mobile Access portal. Web application options include:
Demo Web Application (World Clock) — While testing Mobile Access, select this option to have a web application show as it will when in production.
Custom Web Application — Specify a custom URL as the landing page for users when they connect with Mobile Access. For example, the URL can be the home page of your company’s intranet site.
Mail/Calendar/Contacts — Specify the details of your Exchange Server and existing mail/calendar/contacts applications that your mobile users can access. Options include Capsule Workspace Mail, ActiveSync applications and Outlook Web applications.
File Shares — Create and configure file sharing applications using Windows Common Internet File System (CIFS) protocol.
Citrix Services — Select to include native applications supported by Citrix Services. Mobile Access supports Citrix client connectivity to internal XenApp servers.
Native Apps — Native applications are IP-based applications that are hosted on servers within the organization. Select to specify the path to an existing executable, such as MS Remote Desktop, Telnet, and FTP.
Active Directory Integration 
If choosing to use Active Directory (AD) when you enable the Mobile Access Software Blade, select the AD domain, enter your credentials, and test connectivity. Otherwise, select I don't want to use active directory now.
<número>
 [Internal Use] for Check Point employees​
Mobile Access Workflow
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Workflow
Mobile Access allows users to securely connect to company applications and data. Below is an example of a high-level workflow to configure access to internal applications.
Enable the Mobile Access Software Blade on the Security Gateway using SmartConsole. 
Follow the steps in the Mobile Access Wizard to configure settings.
Add Firewall rules to allow mobile device connections. 
Create and distribute certificates for mobile user authentication using the Certificate Creation and Distribution Wizard. You can skip this step if you are not using certificates as an authentication method. 
End user downloads an endpoint solution, such as the Capsule Workspace application.
User opens the application (in this example, Capsule Workspace) and enters the Mobile Access site name and the required user authentication.
<número>
 [Internal Use] for Check Point employees​
Certificate (Internal or External CA)
RADIUS server
SecurID
Username and password (internal, LDAP)
Dynamic ID OTP
User Authentication
1
©2017 Check Point Software Technologies Ltd. 
User Authentication
The following authentication methods are used for Mobile Access:
Certificate (Internal or External Certificate Authority)
RADIUS server
SecurID
Username and password (internal, LDAP)
Dynamic ID One-Time Password(OTP)
Note: A certificate can only be used as a first time authentication method. Dynamic ID cannot be used as a first authentication method.
Authentication can be configured for pre-R80 Security Gateways in one of two places:
In the Gateway Properties window of a gateway in Mobile Access > Authentication: Select the method that all users must use to authenticate to Mobile Access. The default authentication method is Username and Password. Settings for Two-Factor Authentication with a DynamicID OTP can be configured here as well.
In the Gateway Properties window of a gateway in Legacy Authentication: The default authentication method is Certificates from the ICA. 
With R80.10 and higher Security Gateways, administrators can configure multiple login options. The log in options can be different for each gateway and each Software Blade with a supported client. For more information regarding which Mobile Access clients support multiple log in options, refer to sk111583.
<número>
Gateway Security Features
 [Internal Use] for Check Point employees​
Mobile Access uses IPS Web Intelligence to protect the network from threats and attacks.
Server Side
Mobile Access can scan endpoint devices to verify security compliance and protections.
Client Side
1
©2017 Check Point Software Technologies Ltd. 
Gateway Security Features 
Once activated on the Security Gateway, the Mobile Access Software Blade offers a secured connection by providing security measures on both the server and client side. 
Server Side
Mobile Access uses IPS Web Intelligence to protect the network from web-related threats and attacks, including malicious codes hiding in web-based applications and suspicious SQL injection. It also scans files, such as documents and executables, using the Antivirus Software Blade.
With Mobile Access enabled, administrators select the web-based and native applications that can be accessed by remote users and define the actions that users can perform within the applications. Mobile Access encrypts all traffic using HTTPS for web-based applications and 3DES or RC4 algorithm for native applications. For end users to access the native applications, they need to install the SSL Network Extender. 
Client Side 
On the client side of the connection, Mobile Access can scan endpoint devices to verify their security compliance and make sure that their protections are up-to-date. Mobile Access can be configured to refuse a connection if the device is found to be non-compliant. 
Mobile Access will only allow connections to devices that were able to authenticate, using one of the supported authentication methods, including Dynamic ID, which is Check Point’s two-factor authentication method for machines. In addition, security can be enhanced by preventing browsers from caching certain content, such as a PDF, that attackers may steal. 
Organizations can also require remote users to utilize Capsule Workspace, Check Point’s proprietary virtual desktop. This virtual workspace provides a secured environment, in which files are encrypted and gives users the option to wipe all the data after each session. 
<número>
 [Internal Use] for Check Point employees​
Mobile Access Deployment
Simple Deployment
Cluster Deployment
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Deployment 
Mobile Access can be deployed in several ways, depending on which is appropriate for the organization’s needs:
Simple Deployment
Cluster Deployment
Simple Deployment
This deployment is the easiest to configure. In this deployment, a single Security Gateway enabled with the Mobile Access Software Blade inspects all network traffic, including those coming from endpoint devices. Your existing gateway acts as your Mobile Access gateway.
Cluster Deployment 
A Cluster deployment works best for organizations with a large number of concurrent remote access users. Each cluster can be deployed in either of the deployments mentioned above. In this deployment, however, it is recommended that each cluster member has three interfaces: one interface leading to the organization, a second leading to the Internet, and a third for synchronization. Each interface is on a different subnet.
<número>
 [Internal Use] for Check Point employees​
Defines how remote users can securely access internal company applications and resources using mobile devices.
Rules that define this policy are unified in the Access Control policy.
In the Access Control policy, rules can be configured to apply to all Mobile Access gateways, or just selected gateways.
Rules can be configured to apply to one or more clients.
Rules for pre-R80 gateways can only be configured via SmartDashboard
Mobile Access Policy
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Policy
Check Point Mobile Access extends the functionality of a Firewall for remote users. The Mobile Access Policy defines how remote users can securely access internal company applications and resources using mobile devices. Mobile Access Policy rules are defined and unified in the Access Control policy. This includes all rules related to the Mobile Access Portal, Capsule Workspace, and on-demand clients.
In the Access Control Rule Base, rules can be configured to apply to all Mobile Access gateways, or just selected gateways. Rules can also be configured to apply to one or more clients, such as the Mobile Access Portal or Capsule Workspace.
<número>
 [Internal Use] for Check Point employees​
Mobile Access Rule Base
To configure an R80.10 gateway to use the unified Access Control Policy:
Navigate to the Gateways & Servers tab, and open a Mobile Access object.
Select Mobile Access.
In the Policy Source section, select Unified Access Policy.
Install policy.
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Rule Base
Mobile Access rules for R80.10 and above Security Gateways can be configured as a part of the unified Access Control Policy in SmartConsole or in the legacy shared Mobile Access policy in SmartDashboard. Rules for pre-R80 gateways can only be configured via SmartDashboard. Mobile Access rules for both policy options must include users and user groups, the applications to be accessed, and the gateways that the rule applies to.
All Mobile Access gateways in an environment must use the same source for the Mobile Access policy. You cannot configure the environment to have some gateways that use the unified Access Policy and some that use the legacy policy option.
Note: When using the Unified Access Policy, some Mobile Access features and settings are still configured in SmartDashboard.	
To configure an R80.10 gateway to use the unified Access Control Policy:
In SmartConsole, navigate to the Gateways & Servers tab, and open a Mobile Access gateway object.
Select Mobile Access.
In the Policy Source section, select Unified Access Policy.
Install policy.
<número>
 [Internal Use] for Check Point employees​
The Mobile Access Software Blade must be enabled.
Security Gateways with Mobile Access enabled, are automatically added to the Remote Access VPN Community.
Mobile Access applications must be defined.
Other application objects cannot be used for Mobile Access.
Create access roles to give access to resources through specified remote access clients.
Mobile Access in the Access Control Policy
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access in the Access Control Policy
To configure mobile access authorization in the Access Control policy, the Mobile Access Software Blade must be enabled. The Mobile Access blade only understands rules with a Mobile Access Blade application defined, and with or without an access role defined in the Source column. 
Security Gateways with Mobile Access enabled, are automatically added to the Remote Access VPN Community. To configure rules for the Mobile Access portal or client, include the community or a Remote Access community that includes the Mobile Access gateway in the VPN column. By default, the Remote Access VPN communitycontains a user group that contains all users. 
To use a Mobile Access application in the Access Control policy, it must be defined as a Mobile Application in SmartConsole or SmartDashboard. Other application objects, such as Content Awareness and URL Filtering objects, cannot be used in rules with Mobile Access. For example, a URL Filtering Facebook application cannot be used for Mobile Access. A new Facebook web application must be created and authorized as a web application for Mobile Access. Mobile application objects can be created in the Services & Applications column of a rule. 
To give access to resources through specified remote access clients, create access roles for the clients and include them in the Source column of a rule. If an access role is defined in the Source column of a rule, the Identity Awareness Software Blade must be enabled on all installation targets that the rule applies to. Access roles for remote access will apply to Mobile Access and IPSec VPN clients. When an access role for a client is in the Source column of a rule, the rule will apply to traffic that originates from that client.
<número>
Mobile Access Policy Layers and Inline Layers
 [Internal Use] for Check Point employees​
The order of rules is important because the first rule that matches the traffic is enforced. 
Matching is continued in each subsequent layer until the Mobile Access traffic is matched with a Drop rule or accepted in all layers. 
The matched application for Mobile Access is taken from the last rule matched with a Mobile Access application.
Ordered Policy Layers
Mobile Access is matched on the parent rule and then on the inline layer rule. 
The matched application for Mobile Access is taken from the last rule matched with a Mobile Access application.
If the matched rule does not contain a Mobile Access application, the policy will look for a Mobile Access application in the parent rule.
Inline (Sub-Policy) Layers
1
©2017 Check Point Software Technologies Ltd. 
Mobile Access Policy Layers and Inline Layers
Mobile Access rules can be included in policy layers and inline layers. Mobile Access must be enabled for each layer that contains rules with Mobile Access applications. In a policy with Ordered policy layers, the order of rules in the Rule Base is important because the first rule that matches the traffic is enforced. Matching is continued in each subsequent layer until the Mobile Access traffic is matched with a Drop rule or accepted in all layers. In this case, the matched application for Mobile Access is taken from the last rule matched with a Mobile Access application.
A Mobile Access inline layer can be configured in any Ordered layer. A bypass rule to accept Mobile Access traffic must be created in all layers that are placed above the Mobile Access layer. The bypass rule will match the Mobile Access traffic in the layer and allow the traffic to move to the next layer until it reaches the Mobile Access Inline layer. Use the access role for all Mobile Access users in the Source column and Accept in the Action column to create the bypass rule.
As an inline or sub-policy layer, Mobile Access is matched on the parent rule and then on the inline layer rule. The matched application for Mobile Access is taken from the last rule matched with a Mobile Access application. If the matched rule in the inline layer does not contain a Mobile Access application, the policy will look for a Mobile Access application in the inline layer’s parent rule. 
<número>
 [Internal Use] for Check Point employees​
Place Mobile Access rules that authorize applications above rules that contain a related service.
Create an inline layer for Mobile Access rules.
When creating rules, do not use a Security Gateway as the destination.
Best Practices
1
©2017 Check Point Software Technologies Ltd. 
Best Practices 
It is best practice to place Mobile Access rules that authorize applications above rules that contain a related service. For example, a rule that allows access to a Mobile Access web application, such as Outlook Web Access (OWA) on HTTPS, should be placed above a rule that allows or blocks HTTPS. If the HTTPS rule is first, the web application will match that rule and the policy will not reach the rule that contains the Mobile Access application.
Check Point recommends creating an inline layer for Mobile Access rules. To use the inline layer effectively, define a parent rule in the main policy layer. The parent rule will match all Mobile Access traffic and send the traffic to the inline layer. An access role that includes all Mobile Access users in the Source column is required.
When creating rules, do not use a Security Gateway as the destination. Use Any or the internal hosts of relevant applications in the Destination column. This is because Mobile Access applications are defined in the Services & Applications column. In turn, do not use Any in the Services & Applications column. To make an application show in the Mobile Access Portal or Capsule Workspace, it must be a Mobile Access application object that is used explicitly in the Rule Base.
<número>
Chapter 6 Review Questions
What is the difference between an SSL VPN and an IPSec VPN?
In the SSL VPN solution, users can connect securely to business web-based applications through a web portal, which can be accessed using a web browser. This solution does not require users to install a VPN agent or client and can be configured to enforce two-factor authentication. 
IPSec, Layer 3 VPN requires remote workers to install a VPN client before gaining access to corporate resources. Once a user installs the client, the Layer 3 VPN provides a secured connection to both web-based and native business applications. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 6 Review Questions
How do Capsule Docs and Capsule Workspace work together?
As business documents are edited and viewed on personal devices using Capsule Workspace, Capsule Docs protects business data and documents no matter where it is transmitted.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Demonstrate how to enable Mobile Access for remote users.
Configure LDAP integration for remote user authentication of Mobile applications.
Lab 6.1: Managing Mobile Access
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
Threat prevention
07
[Restricted] ONLY for designated groups and individuals
1
©2017 Check Point Software Technologies Ltd. 
 
©2017 Check Point Software Technologies Ltd. 
Learning Objectives:
Discuss different Check Point Threat Prevention solutions for dangerous attacks such as zero-day and Advanced Persistent Threats.
Understand how SandBlast, Threat Emulation, and Threat Extraction helps to prevent security incidents.
Identify how Check Point SandBlast Mobile helps protect an organization from threats targeting company-issued smartphones and tablets.
Threat Prevention
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Protecting an organization from security threats such as zero-day or Advanced Persistent Threats (APT) is an important aspect of cyber security administration. The ability to prevent these and other threats help organizations avoid serious and costly damages. This chapter provides an overview of Check Point Threat Prevention solutions that protect an organization from malware and threats targeting company-issued devices, including smartphones and tablets.
<número>
 [Internal Use] for Check Point employees​
Continues to evolve at a rapid pace.
Evasion techniques are used to undermine an organization’s defenses.
Zero-day attacks target unknown software flaws or vulnerabilities to deliver new variants of existing malware.
 
The Threat Landscape
1
©2017 Check Point Software Technologies Ltd. 
The Threat Landscape
Today’s Threat Landscapecontinues to evolve at a rapid pace. As a result, Threat Prevention has become more complex than ever before. Many organizations are challenged to keep up with the dynamically expanding landscape of threats as well as new trends, such as consumerization, regulatory compliance, and cloud-based services. Organizations and individuals alike continue to be victimized and beleaguered by sophisticated cyber attacks at an increasing rate. Businesses not only need to be concerned about network attacks, but also attacks directed at end user’s computers, such as viruses and bots. In addition, new malware is created nearly every second. 
Zero-day attacks and Advanced Persistent Threats (APTs) are different kinds of threats that attackers employ to target businesses. Both use evasion techniques that undermine an organization’s defenses. Thus, it is important for organizations to implement a multi-faceted security strategy to expose and combat these and other threats. 
Zero-Day Attacks
 
Zero-day attacks target unknown software flaws or vulnerabilities to deliver new variants of existing malware. They are known to elude the most up-to-date Anti-Malware and Antivirus solutions. Because there is no security patch yet available for these vulnerabilities, zero-day attacks give attackers an opportunity to perform their malicious activities within the targeted company’s network. 
Advanced Persistent Threats
APTs are designed to infiltrate an organization’s systems over a period of time while evading detection. These attacks use multiple techniques in several stages and typically appear as small unrelated events, which, if taken individually, may seem harmless. In some cases, APTs may employ zero-day threats as an infection vector, but they also exploit existing vulnerabilities. 
APTs are known to be launched and funded by nation-states and certain organizations. They have targeted both large and small organizations. The damage of a successful APT can have a severe impact on affected companies. The impact can include data breaches, system downtime, damaged brand reputation, and various costly fees. 
<número>
 [Internal Use] for Check Point employees​
Protects users from malware on legitimate websites, controls network usage of selected applications, and more.
The IPS Software Blade features thousands of signatures, and behavioral and preemptive protections.
In R80.10, the blade is managed by the Threat Prevention policy.
IPS profiles can be imported and exported using the ips_export_import command.
Each profile contains a set of activated protections.
 
Intrusion Prevention System
1
©2017 Check Point Software Technologies Ltd. 
Intrusion Prevention System
The Intrusion Prevention System (IPS) is a component of the Threat Prevention solution. Whereas the Firewall blocks traffic based on source, destination, and port information, IPS adds another line of defense by analyzing traffic contents to check if it is a risk to the network. 
IPS protects users from malware on legitimate websites, controls network usage of selected applications, and more. 
IPS Profile Settings and Protections
The IPS Software Blade delivers complete and proactive intrusion prevention. It features thousands of signatures, and behavioral and preemptive protections to deliver complete intrusion prevention for clients, servers, operating system and other vulnerabilities. Its detection engine combines multiple defense layers to detect and prevent threats.
In R80.10, the IPS Software Blade is managed by the Threat Prevention policy. As part of the unified Threat Prevention policy, IPS allows more granularity with multiple protection profiles per gateway. IPS protections are immediately enforced on network traffic when a Threat Prevention policy is installed on the Security Gateways. Threat Prevention profiles determine which protections are activated. 
IPS profiles can be imported and exported using the ips_export_import command from the CLI. Using this command, profile configurations can be copied between management servers of the same version.
Each IPS profile contains a set of activated protections and instructions for what IPS will do when traffic inspection matches an activated protection. The IPS library of protections is constantly updated to stay ahead of emerging threats. Security Gateways with IPS enabled will get the updates when the policy is installed. To view the latest protections, navigate to the Threat Tools sections and select IPS Protections.
All IPS protections have dynamic tags which will allow Threat Prevention profiles to automatically activate or deactivate protections tagged by relevant aspects such as protocols, affected software, and file types.
Security Gateways from previous software versions that have IPS and other Threat Prevention Software Blades enabled, will have their Threat Prevention policy split into two different layers. In turn, the IPS layer will include the ThreatCloud IPS protections and all other core IPS protections will remain a part of the Access Control policy installation.
Note: Settings for protocol violations, such as “aggressive aging” and “non-compliant HTTP” are accessed from the Inspection Settings section. To view this section, navigate to Manage & Settings > Blades.	
<número>
 [Internal Use] for Check Point employees​
 Verify that there are enough CPU resources to enable IPS.
Update the IPS package, to ensure that the Security Gateway is updated with the latest protection signatures.
Set the default IPS action to Prevent, to enable maximum network protection.
Set the default IPS action for newly downloaded protections to Prevent.
Clone the Recommended Profile to create a backup copy. 
During the initial process, enable Troubleshooting mode. In this mode, IPS inspects but does not block a network's unique traffic. 
Use the Follow Up option to help the analysis and tuning of new protections in the future.
Assign the active profile to applicable gateways and set the gateway to bypass IPS inspection when it is under heavy load.
IPS Tuning and Maintenance
1
©2017 Check Point Software Technologies Ltd. 
IPS Tuning and Maintenance
IPS is not a static solution and requires regular tuning and maintenance to make it effective against evolving threats. Below is an overview on how to properly maintain IPS: 
Verify that there are enough CPU resources to enable IPS.
Update the IPS package, to ensure that the Security Gateway is updated with the latest protection signatures.
Set the default IPS action to Prevent, to enable maximum network protection.
Set the default IPS action for newly downloaded protections to Prevent.
Clone the Recommended Profile to create a backup copy. Make sure all changes are done on the cloned profile. Security requirements for different segments in the network often depend on the specified traffic types and network objects for each segment. For deployments with a Multi-Domain Server or several gateways, consider creating separate IPS policies and perform these steps for each segment.
During the initial process, enable Troubleshooting mode. In this mode, IPS inspects but does not block a network's unique traffic. Even if all protections are set to Prevent, the gateway only detects possible threats and generates logs for the traffic.
Use the Follow Up option to help the analysis and tuning of new protections in the future.
Assign the active profile to applicable gateways and set the gateway to bypass IPS inspection when it is under heavy load. This is to ensure that IPS analysis does not affect on-network traffic. 
<número>
 [Internal Use] for Check Point employees​
Install policy on the gateways, because policies are not automatically deployed. 
After installing the policy, IPS will begin inspecting the traffic and generating logs. Collect logs for at least a week or two and then review the logs to decide which protections to run in Protect or Detect mode, and which ones require further fine-tuning and analysis.
Disable Troubleshooting mode for IPS SoftwareBlade to protect the network.
Change the settings for Updates policy. Configure updates for Newly downloaded protections and then set to Detect. When new IPS protections are deployed, they are set to Detect mode.
Clear the follow up and newly downloaded flags for all protections that are reviewed during the tuning process.
Tune the new IPS protections that are downloaded twice a month and look for changes in the behavior of the ones already tuned. 
Monitor Security Gateway performance and configure the applicable settings to provide the best network security and performance.
IPS Tuning and Maintenance (Cont.)
1
©2017 Check Point Software Technologies Ltd. 
Install policy on the gateways because, policies are not automatically deployed. 
After installing the policy, IPS will begin inspecting the traffic and generating logs. Collect logs for at least a week or two and then review the logs to decide which protections to run in Protect or Detect mode, and which ones require further fine-tuning and analysis.
Disable Troubleshooting mode for IPS Software Blade to protect the network.
Change the settings for Updates policy. Configure updates for Newly downloaded protections and then set to Detect. When new IPS protections are deployed, they are set to Detect mode.
Clear the follow up and newly downloaded flags for all protections that are reviewed during the tuning process.
Tune the new IPS protections that are downloaded twice a month and look for changes in the behavior of the ones already tuned. 
Monitor Security Gateway performance and configure the applicable settings to provide the best network security and performance.
Note: If a specific IPS profile is in Detect Only Mode for troubleshooting, it will not block malicious traffic.
<número>
 [Internal Use] for Check Point employees​
Demonstrate how Threat Prevention profiles affect IPS inspection on a Check Point Security Gateway.
Demonstrate how to modify IPS protections to customize IPS enforcement profiles.
Lab 7.1: Understanding IPS Protections
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Enforces or monitors traffic based on the source or destination country.
A valid IPS contract and an IPS Software Blade license is required.
The IP-To-Country database is downloaded to the gateway from a Check Point data center.
Geo-Protection logs are aggregated by default.
Geo-Protection
1
©2017 Check Point Software Technologies Ltd. 
Geo-Protection
Geo-Protection enforces or monitors traffic based on the source or destination country. Country information is determined by comparing the IP address in the packet against the IP-to-country database. Private IP addresses are always allowed unless explicitly specified as blocked on the other side of the connection. Check Point control connections, for example those between Security Gateways and Security Management Server, are always allowed regardless of the Geo-Protection policy. 
You must have a valid IPS contract and a Software Blade license for each Security Gateway that enforces Geo-Protection. 
The IP Address to Country Database
The IP-To-Country database is downloaded to the Security Gateway from a Check Point data center. To make sure that the database is up-to-date, the Security Gateway should be connected to the Internet. If the Security Gateway requires a proxy to access the Internet, the proxy must be defined in SmartDashboard. 
Log Aggregation by Country
By default, Geo-Protection logs are aggregated, which means that a single log entry is generated per aggregation interval, for every country that is part of the Policy for Specific Countries. Logs related to other countries are aggregated to a single log entry.
It is possible to turn off log aggregation by country. In that case, a log is created for every connection tracked. Turning off log aggregation by country may significantly increase the number of generated logs and increase CPU usage on the Security Gateway.
You can create a Geo Protection policy with exceptions to allow legitimate traffic through while blocking or monitoring traffic from untrusted sources or by country. Users can monitor activity using SmartEvent. 
<número>
 [Internal Use] for Check Point employees​
Demonstrate how geographic location can be used to define a security posture.
Lab 7.2: Deploying IPS Geo Policy
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Protects the network from malware attacks.
Uses threat intelligence from ThreatCloud.
Scans incoming files for malicious signatures.
Updates ThreatCloud with any newly detected malware.
 
Antivirus
1
©2017 Check Point Software Technologies Ltd. 
Antivirus 
The Check Point Antivirus Software Blade protects the network from malware attacks, such as worms, backdoors, viruses, and trojans. Using threat intelligence from ThreatCloud, Antivirus generally deals with threats coming into the organization’s network. It scans incoming files like PowerPoint, Word, or Excel files for malicious signatures. It then updates the ThreatCloud repository for any newly detected malware found in the system. 
Aside from monitoring and classifying files, Antivirus also blocks access to websites with known connection to malware. The Security Gateway uses its caching mechanisms to verify URLs. If the Security Gateway is unable to verify the URL, the Antivirus blade sends the URL to ThreatCloud for verification. If found malicious, Antivirus blocks access to the URL before any damage can take place. 
<número>
 [Internal Use] for Check Point employees​
A bot is malware which uses stealth mechanisms to infect computer systems. It connects to a C&C server to execute attacks.
An Anti-bot tries to prevent damages by blocking communications from the C&C server.
Check Point’s Anti-Bot Software Blade identifies bot-infected machines using the ThreatSpect engine to analyze network traffic. The engine:
Performs a reputation check.
Reviews network signatures.
Searches for suspicious activity.
Anti-Bot
1
©2017 Check Point Software Technologies Ltd. 
Anti-Bot 
A bot is malware which uses stealth mechanisms to remain hidden from Antivirus solutions. They can arrive into a computer as an infected email attachment or as the result of a drive-by download from a malicious website. 
Once infection occurs, the bot takes control of the computer by connecting to a Command & Control (C&C) server and awaits instructions from attackers who can remotely execute routines. These routines include data theft, spam distribution, and other activities that consume significant computer resource and bandwidth. Attackers also use the bot-controlled computer to target and infect other computers, in effect creating a botnet. An anti-bot tries to prevent damages by blocking communications from the C&C server.
The Anti-Bot Software Blade identifies bot-infected machines using the multi-tier ThreatSpect engine to analyze network traffic. ThreatSpect is a discovery technology that has up-to-minute update feeds from ThreatCloud. The engine is installed on the gateway and performs three important tasks: 
Performs a reputation check to verify the IP addresses and drop zones of known C&C sites with real-time updates of an address list. Security Gateways are constantly updated with the latest list. However, the ThreatSpect engine may query ThreatCloud to get more updates. ThreatSpect engine also caches this information to minimize time to deploy updates.
Reviews the network signatures of over 2,000 bot families that were detected previously. It matches the traffic’s behavior with known bot behavioral patterns and blocks communication to C&C sites. This ensures no sensitive information is stolen or leaked. 
Searches for suspicious activity by monitoring outgoing mail traffic and communication patterns. For example, it analyzes outgoing mail to identify spam sent from the organization. Italso monitors if a computer participates in Denial of Service (DoS) attacks.
Once a bot-infected machine is identified, the ThreatSpect engine blocks outbound communication to C&C sites to protect sensitive data. However, you will still need remediation to remove the bot from the network.
<número>
 [Internal Use] for Check Point employees​
Identify specific threat protections used by Check Point Threat Prevention.
Demonstrate the Anti-Bot and Antivirus features of R80.10.
Lab 7.3: Reviewing Threat Prevention Settings and Protections
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
 [Internal Use] for Check Point employees​
Used to catch zero-day attacks and APTs.
Files are hosted and executed in a secured environment and then observed for suspicious routines.
Types of sandboxing:
OS-Level 
 
Sandboxing
1
©2017 Check Point Software Technologies Ltd. 
Sandboxing
Sandboxing is a pre-eminent solution which is used to catch zero-day attacks and APTs. It allows a file to be hosted and executed in a secured environment, separate from the network. The file is then observed for suspicious routines. If the file displays any type of malicious behavior, it is prevented from being released into the network. If found safe, the file will be released to the network. There are currently two types of sandboxing: OS-level and CPU-level. 
<número>
 [Internal Use] for Check Point employees​
Traditional sandboxing.
Emulates a standard operating system in an isolated environment to execute and screen files.
Evasion techniques include:
Delaying launch of a payload.
Searching for virtual machine indicators.
Checking for human interaction activities that are difficult to replicate virtually.
OS fingerprinting.
OS-Level Sandboxing
1
©2017 Check Point Software Technologies Ltd. 
Operating System-Level Sandboxing
Also known as traditional sandboxing, OS-level sandboxing emulates a standard operating system in an isolated environment to execute and screen files. This ensures that suspicious files are safely isolated from the company’s production network. 
The sandbox simulates the files as if the actual user opened it and monitors it for malicious routines. If the file shows any suspicious behavior, the sandbox updates Threat Cloud for threat intelligence sharing and deleting the file. 
Traditional Sandboxing Evasion Methods
Attackers have created several tactics to avoid sandbox detection. Some of these known techniques include:
Delaying launch of a payload, wherein malicious code executes minutes, hours, days, or even years after the file has been opened. 
Searching for virtual machine indicators, such as scanning registry keys, running processes, or disk size to identify a sandbox environment.
Checking for human interaction activities that are difficult to replicate in a virtual environment, including page scrolling and mouse clicks.
Operating system fingerprinting to identify systems, services, and hardware and software configurations that may be available for exploitation.
<número>
 [Internal Use] for Check Point employees​
CPU-Level Sandboxing
Addresses the limitations of traditional sandboxing.
Monitors exploits executed in CPU instruction codes.
The 4 stages of a CPU-Level attack are:
Finding Vulnerability
Using an Exploit Method
Running a Shellcode
Running the Malware
1
©2017 Check Point Software Technologies Ltd. 
CPU-Level Sandboxing
CPU-level sandboxing addresses the limitations of traditional sandboxing by performing CPU-level inspection to monitor any indication of an exploit method executed in CPU instruction codes (sets). This solution takes advantage of the fact that although attackers have plenty of vulnerabilities and malware to choose from, they can only use a handful of exploit methods.
The image below shows a typical CPU-Level attack scenario.
Finding Vulnerability — One or more vulnerabilities are discovered in the operating system code or widely used applications like Internet browsers and PDF readers. Potentially, there can be thousands of software vulnerabilities in a system. By exploiting any of these vulnerabilities, attackers will inject their logic into the system and trigger an attack.
Using an Exploit Method — Exploits allow the injected logic to manipulate the target system and run the malicious code. This requires overcoming built-in security controls implemented by the operating system and the CPU, such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR). This is the stage where CPU-level sandboxing examines files for an exploit method and catches it before the shellcode is executed. 
Running a Shellcode — A shellcode is a small payload, typically embedded into a file or web page. After leveraging one or more exploit methods, the attacker then plants the shellcode into executable memory to trick the system to run it. Retrieving the actual malware, the shellcode then places it on the infected system. 
Running the Malware — Executing the malware completes the infection. This is the stage where traditional sandboxing discovers if a file shows any suspicious routines. However, it is at this stage where evasion techniques usually manifest, such as when a file delays execution of its routines in an attempt to hide from the sandbox.
<número>
 [Internal Use] for Check Point employees​
Check Point’s solution for zero-day attacks, APT, and similar threats.
Complemented with a suite of attack visibility tools.
Private network and public Cloud solutions.
Check Point SandBlast Zero-Day Protection
1
©2017 Check Point Software Technologies Ltd. 
Check Point SandBlast Zero-Day Protection
SandBlast Zero-Day Protection is Check Point’s solution for zero-day attacks, APT and similar threats. It is complemented with a suite of attack visibility tools, such as the Logging and Monitoring view of SmartConsole and SmartEvent. These tools aid in forensics and help to reveal how detected malware would have behaved, had it been allowed to run.
Check Point offers SandBlast technology solutions for private network and public cloud settings. To protect end user systems, Check Point expands SandBlast protection with the SandBlast Agent.
<número>
 [Internal Use] for Check Point employees​
Threat Emulation
Threat Extraction
Threat Cloud
 
SandBlast Components
THREAT EMULATION
THREAT EXTRACTION
THREAT CLOUD
MAIL TRANSFER AGENT
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Components
 
SandBlast has several functional components that work together to ensure that attacks are prevented in real-time. These components include:
Threat Emulation
Threat Extraction
Threat Cloud
Mail Transfer Agent
<número>
 [Internal Use] for Check Point employees​
Performs both CPU-Level and OS-Level inspection of files.
Stops the file from executing its routines.
SandBlast Threat Emulation
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Threat Emulation
The Threat Emulation engine is the sandbox component of SandBlast. It protects the network against advanced and zero-day attacks by performing both CPU-level and OS-level inspection of files. Threat Emulation hosts the file in a sandbox environment and examines it on a CPU-level for any indication of exploit activity. This inspection stops the file from executing any of its routines, particularly those that attempt to evade detection. 
<número>
 [Internal Use] for Check Point employees​
Examines document files and removes any active contents.
Provides a sanitized, reconstructed document using only safe elements.
Typically used for incoming emails.
Supports widely used document file types, such as PDF and MS Word documents.
SandBlast Threat Extraction
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Threat Extraction
The SandBlast Threat Extraction engine examines document files and removes any active contents from the document, while Threat Emulation runs the file in its secured environment. Active contents include objects such as JavaScript,macros, and links, which cyber criminals may use to insert their malicious code. 
While Threat Emulation runs and inspects files, Threat Extraction provides users with a sanitized, reconstructed document using only safe elements. This ensures business continuity and end-user productivity without compromising security. 
Threat Extraction is typically used for incoming emails only; however, it can be used for outgoing emails as well. It supports widely used document file types, such as PDF and MS Word documents.
<número>
 [Internal Use] for Check Point employees​
Threat Extraction and Threat Emulation
1
©2017 Check Point Software Technologies Ltd. 
This table details the differences between Threat Extraction and Threat Emulation.
<número>
 [Internal Use] for Check Point employees​
Intelligence sharing.
Consolidates information from sources, such as:
Signature and reputation data from different Check Point systems.
External intelligence sources.
Data and research from Check Point’s Vulnerability Research and Incident Response teams.
Ensures that SandBlast is up-to-date.
Threat Cloud
1
©2017 Check Point Software Technologies Ltd. 
Threat Cloud
Check Point Threat Cloud is the back-end platform for intelligence sharing for all Check Point products and services. This platform consolidates big data, external feeds, and shared learning from various sources, such as: 
Signature and reputation data from different Check Point systems
External intelligence sources, along with consumer and endpoint data SandBlast agents 
Data and research from Check Point’s Vulnerability Research and Incident Response teams 
Threat Cloud ensures that SandBlast is up-to-date with information to help protect an organization’s network against the latest threats. 
<número>
 [Internal Use] for Check Point employees​
Ensures that full emulation occurs without disruption.
Prevents email server timeout during emulation.
Manages the emulation of SMTP traffic.
Mail Transfer Agent
1
©2017 Check Point Software Technologies Ltd. 
Mail Transfer Agent
Mail Transfer Agent (MTA) functionality in Check Point Security Gateways ensures that full emulation occurs without any disruption to the business, particularly in the flow of email. Enabling MTA prevents the possibility of email server timeout during file emulation and manages the emulation of SMTP traffic. MTA completes and closes the connection with the source email server and then sends the file for emulation. 
<número>
 [Internal Use] for Check Point employees​
Mail Transfer Agent
MTA acts as an SMTP server by receiving email from the sender and closing the connection after the complete email and the attachment is received. 
MTA holds the email until Threat Extraction reconstructs a clean copy of the attachment. 
MTA then sends the attachment to the Threat Emulation sandbox environment for inspection. 
MTA stores the original attachment in the Security Gateway and modifies the email by attaching the clean copy of the attachment, along with a link to the original attachment.
MTA then forwards the modified email to the mail server, which then sends it to the intended recipient. 
If the attachment is found to be malicious after sandbox inspection, Threat Emulation deletes the file from the Security Gateway, logs the event, notifies the administrator, and updates Threat Cloud for threat intelligence. 
1
©2017 Check Point Software Technologies Ltd. 
With MTA enabled, the gateway manages SMTP traffic via port 25 and holds external emails with potentially malicious attachments. After emulation is complete, MTA sends the email to the server in the internal network. The detailed process is shown below:
MTA acts as an SMTP server by receiving email from the sender and closing the connection after the complete email and the attachment is received. 
MTA holds the email until Threat Extraction reconstructs a clean copy of the attachment. 
MTA then sends the attachment to the Threat Emulation sandbox environment for inspection. 
MTA stores the original attachment in the Security Gateway and modifies the email by attaching the clean copy of the attachment, along with a link to the original attachment.
MTA then forwards the modified email to the mail server, which then sends it to the intended recipient. 
If the attachment is found to be malicious after sandbox inspection, Threat Emulation deletes the file from the Security Gateway, logs the event, notifies the administrator, and updates Threat Cloud for threat intelligence. 
Note: To enable MTA functionality in the Security Gateway, activate the Threat Prevention Software Blade package which includes Antivirus, Anti-Bot, and either Threat Extraction or Threat Emulation.	
<número>
 [Internal Use] for Check Point employees​
Deploy in two modes:
Inline or Prevent
Detect Only
Includes the Anti-Bot, Antivirus, Threat Emulation and Threat Extraction Software Blades.
Solution architectures vary.
SandBlast Appliances
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Appliances
SandBlast appliances can be deployed in two modes: 
Inline or Prevent — As a Mail Transfer Agent (MTA) and as part of the web traffic flow. 
Detect Only — A SPAN port to receive a copy of traffic.
A SandBlast appliance includes the Anti-Bot, Antivirus, Threat Emulation and Threat Extraction Software Blades. However, it is recommended to use the appliance exclusively for OS-level sandboxing and CPU-level detection.
Organizations that prefer not to allow files to be sent outside of the corporate network or those that have a large centralized network architecture requiring high performance and low latency, may opt for deploying a SandBlast private cloud option. Solution architectures vary depending in cases such as:
Customers with Check Point Security Gateways running R77 and above, and with the Next Generation Threat Prevention (NGTP) package activated.
Customers with Check Point gateways below R77 or no NGTP package, or with third party gateways.
Customers that are evaluating SandBlast prior to installing it.
<número>
 [Internal Use] for Check Point employees​
Prevent Mode
The attacker sends an email with an attached file.
The Check Point Security Gateway with MTA enabled holds the email.
Threat Extraction reconstructs a safe copy of attachment, and forwards it to the mail server. The recipient receives the email and safe copy without any delay.
Threat Emulation forwards the attachment to OS-level sandboxing and CPU-level detection within the SandBlast Appliance. 
The SandBlast appliance inspects the file. If the file is found malicious, SandBlast updates ThreatCloud with the information. The file is marked infected and deleted from the MTA holding area of the Check Point Security Gateway. 
If the SandBlast appliance determines the file is harmless, the original file is released to mail server. 
1
©2017 Check Point Software Technologies Ltd. 
Prevent Mode 
When a SandBlast appliance is deployed in Prevent mode, traffic (or an attached file) is sent to the appliance before it is allowed to enter the internal network. This deployment requires that the MTA feature in the Security Gateway is enabled. 
Prevent mode is also recommended for Proof-of-Concept (POC) scenarios where the customer is using either a third-party Firewall or an older version of Check Point software. Customers with no Next Generation Threat Prevention (NGTP) package would also benefit from this type of deployment. 
The detailed workflow of the SandBlast appliance in Prevent mode architecture is:
The attacker sends an email with an attached file.
The Check Point Security Gateway with MTA enabled holds the email.
Threat Extraction reconstructs a safe copy of attachment, and forwards it to the mail server. The recipient receives the email and safe copy without any delay.
Threat Emulation forwards the attachment to OS-level sandboxing and CPU-level detection within the SandBlast Appliance. 
The SandBlast appliance inspects the file. If the file is found malicious, SandBlastupdates ThreatCloud with the information. The file is marked infected and deleted from the MTA holding area of the Check Point Security Gateway. 
If the SandBlast appliance determines the file is harmless, the original file is released to mail server. 
<número>
 [Internal Use] for Check Point employees​
Detect Mode
An attacker sends the email with an attachment.
The Check Point Security Gateway or a third-party gateway uses a mirror or TAP port to duplicate network traffic, sending it to the SandBlast appliance.
The gateway performs a traditional security inspection and permits traffic to enter the network.
The user receives the original email without any delay.
Threat Emulation forwards the attached file to the SandBlast appliance for OS-level sandboxing and CPU-level detection. If the file is found malicious, SandBlast updates ThreatCloud with the new malware and the system administrator is notified of the infection.
1
©2017 Check Point Software Technologies Ltd. 
Detect Only Mode
For users who want to perform an evaluation first, the SandBlast appliance can be configured to Detect Only mode or SPAN port deployment to monitor zero-day attacks. In this scenario, duplicate traffic is sent to the SandBlast appliance while real traffic enters the internal network, passing through the Security Gateway. Using the MTA feature is not required in this deployment. 
The SandBlast appliance Detect Only mode architecture works as follows: 
An attacker sends the email with an attachment.
The Check Point Security Gateway or a third-party gateway uses a mirror or TAP port to duplicate network traffic, sending it to the SandBlast appliance.
The gateway performs a traditional security inspection and permits traffic to enter the network.
The user receives the original email without any delay.
Threat Emulation forwards the attached file to the SandBlast appliance for OS-level sandboxing and CPU-level detection. If the file is found malicious, SandBlast updates ThreatCloud with the new malware and the system administrator is notified of the infection.
<número>
 [Internal Use] for Check Point employees​
SandBlast Cloud
An email is sent with a malicious attachment.
Check Point Security Gateway with enabled MTA holds the email.
Threat Extraction constructs a clean copy of the attachment in PDF format and forwards it to the mail server. The recipient receives the email with the PDF copy without delay.
Using the MTA service, Threat Emulation forwards the email to SandBlast Cloud for OS-level sandboxing and CPU-level detection.
If the file is identified as zero-day malware, SandBlast Cloud updates ThreatCloud with the new information. The file is marked as infected and deleted from the MTA holding area in the Security Gateway.
If SandBlast Cloud determines the file to be harmless, it is then released to the mail server.
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Cloud
SandBlast Cloud performs OS-level sandboxing and CPU-level detection in a Check Point controlled, public cloud infrastructure. This solution requires no new hardware and is ideal for users who want to use their existing gateways, have a globally distributed network, or have high usage of cloud-based or Software-as-a-Service (SaaS) applications. The detailed workflow of the SandBlast Cloud architecture is as follows:
An email is sent with a malicious attachment.
Check Point Security Gateway with enabled MTA holds the email.
Threat Extraction constructs a clean copy of the attachment in PDF format and forwards it to the mail server. The recipient receives the email with the PDF copy without delay.
Using the MTA service, Threat Emulation forwards the email to SandBlast Cloud for OS-level sandboxing and CPU-level detection.
If the file is identified as zero-day malware, SandBlast Cloud updates ThreatCloud with the new information. The file is marked as infected and deleted from the MTA holding area in the Security Gateway.
If SandBlast Cloud determines the file to be harmless, it is then released to the mail server.
<número>
 [Internal Use] for Check Point employees​
Detect Mode
Prevent Mode
Hybrid Deployment
Exchange mail
Microsoft Office 365
SandBlast Cloud Deployment Options
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Cloud Deployment Options
Check Point SandBlast Cloud provides zero-day protection for organizations transitioning to cloud-based applications. The SandBlast Cloud includes the following security elements:
Antivirus — Proactively leverages Antivirus signatures to protect against malware in attached files.
URL Reputation — Detects and blocks malicious URLs within email body.
Threat Extraction — Delivers safe, reconstructed copies of documents to users while inspecting the original files for potential threats.
Threat Emulation — Forwards inbound email file attachments, including files originating from URLs within emails, to the sandbox for emulation. It detects and blocks the file if verified to be malicious or a component of a zero-day attack. 
SandBlast Cloud in Detect Mode 
In Detect mode, incoming emails go straight to the inbox without interference, while attachments are sent to SandBlast Cloud for inspection. This is the ideal mode for introducing visibility into threats while gradually deploying solution. 
SandBlast Cloud in Prevent Mode
In Prevent mode, incoming emails are directed to a temporary quarantine folder within Office 365 to isolate incoming emails from the user inbox. This ensures emails containing malicious attachments, contents, and URLs will not reach end users. 
In the case of a false positive, in which a user determines that the email is from a trusted source, the email and content can be retrieved from the quarantine folder. 
Hybrid Deployment
Organizations with an on-premise Exchange server and Cloud Office 365 can use the following options for a hybrid deployment: 
Exchange mail – Use the Check Point Security Gateway with a Next Generation Threat Extraction Software Blade license, and use either SandBlast Cloud or appliance for Threat Emulation.
Microsoft Office 365 – Subscribe to Check Point SandBlast Cloud security as a service.
To consolidate logging and have both solutions send logs to the same on-premise SmartLog or SmartEvent server, users can configure the Log Transfer Agent (LTA) in the Check Point SandBlast Cloud dashboard.
Exchange Server as MTA Agent
Using an exchange server agent as an MTA agent is the best option for administrators who want to simplify the mail-holding design during SandBlast implementation. This allows them to use their existing Exchange agent to hold all corporate email, while Check Point SandBlast certifies it as safe.
<número>
 [Internal Use] for Check Point employees​
Extends SandBlast Protection to end-users.
Defends endpoint devices and web browsers.
Uses its local version of Anti-Bot to detect and contain malware.
Blocks C&C communications.
SandBlast Agent
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Agent
SandBlast Agent extends SandBlast protection to end-user systems, such as desktops and laptops. It is designed to defend endpoint devices and web browsers. 
If malware enters an end user’s system, the SandBlast Agent uses its local version of Anti-Bot to detect and contain these infections. It searches for any Command and Control (C&C) communication sent over the network. To prevent the malware from spreading within the network, SandBlast Agent blocks any communication from the affected computer and quarantines the infected files.
<número>
 [Internal Use] for Check Point employees​
Forensic Analysis
The SandBlast Agent collects forensics data continuously on the endpoint in a tamper-resistant area. 
An Incident report can be triggered by a number of events, including input from SandBlast Agent, Threat Emulation, Threat Extraction, and other enabled Software Blades. 
Raw forensic data are analyzed using advanced algorithms. The SandBlast Agent automatically requests logs from involved endpoints.
TheSandBlast Agent generates a complete view of attacks. The Incident report is sent to SmartEvent.
1
©2017 Check Point Software Technologies Ltd. 
Forensics Analysis
The SandBlast Agent features automated forensic analysis that generates extensive reporting and diagnostics of security events for faster response against attacks. It shows threat details, such as arrival method, attack flow, business impact, and infected hosts. 
To create this report, the SandBlast Agent performs the following:
The SandBlast Agent collects forensics data continuously on the endpoint in a tamper-resistant area. This provides full visibility into activity throughout the attack lifecycle, and requires minimal overhead. The data is stored for a 30-day window by default, but can be adjusted. Because the agent only records events, it requires less than 1% of CPU resources and 1 GB of storage. 
An Incident report can be triggered by a number of events, including input from SandBlast Agent, Threat Emulation, Threat Extraction, and other enabled Software Blades. 
Raw forensic data are analyzed using advanced algorithms. The SandBlast Agent automatically requests logs from involved endpoints.
Finally, the SandBlast Agent generates a complete view of attacks, including point of entry, business impact, and full attack flow. The Incident report is sent to SmartEvent.
<número>
 [Internal Use] for Check Point employees​
Forensic Analysis
1
©2017 Check Point Software Technologies Ltd. 
Aside from providing comprehensive threat reporting, the SandBlast agent recommends actionable information that can help in the implementation of remediation measures. 
Since forensic analysis happens automatically, security response teams do not need to spend hours building the information from the ground up. The SandBlast Agent enables these teams to work efficiently and address threats as they unfold.
<número>
 [Internal Use] for Check Point employees​
Hybrid Solution
Private Cloud
Public Cloud Service
SandBlast Deployment
OS-Level sandboxing and CPU-Level detection performed by SandBlast Cloud.
Choose which public cloud location the files are sent to for detection.
Use the tecli command to change the cloud location.
OS-Level sandboxing and CPU-Level detection using a SandBlast appliance and deployed in the customer’s private cloud network.
OS-Level sandboxing and CPU-Level detection work in both private and public cloud infrastructures.
Security Gateways perform traditional Threat Prevention duties and acts as an MTA.
Threat Extraction via the gateway or the SandBlast appliance.
Threat Emulation via the SandBlast appliance or SandBlast Cloud.
1
©2017 Check Point Software Technologies Ltd. 
Hybrid Solution (SandBlast Appliance and Cloud)
In a hybrid solution, OS-level sandboxing and CPU-level detection work together in both private and public cloud infrastructures. Administrators can choose which files to emulate locally in the SandBlast appliance or in the public SandBlast Cloud. 
This setup is ideal for companies with a distributed architecture, in which most of their employees work in a regional or global headquarters environment, while others work from various satellite offices. With a hybrid solution, the organization can deploy a SandBlast appliance at its headquarters, and support satellite offices using the SandBlast Cloud.
In a hybrid solution, the Threat Prevention tasks are distributed as follows: 
Check Point Security Gateways perform traditional Next Generation Threat Prevention duties (Anti-Bot, Antivirus, and Anti-Spam) and also act as an MTA to hold emails.
Threat Extraction can happen either at the Security Gateway or SandBlast appliance. 
Threat Emulation with OS-level sandboxing and CPU-level detection happens either with SandBlast appliance or SandBlast Cloud. 
A distributed architecture is an efficient way to utilize the Check Point SandBlast solution. However, it comes with the challenge of provisioning and managing multiple MTAs. Check Point User Center can help customers with these complex security architectures.
<número>
 [Internal Use] for Check Point employees​
Identifies threats in mobile devices.
Uses on-device, network, and cloud-based algorithms.
Analyzes behavior across several attack vectors:
OS-Level Exploits
Mobile Application Malware
Network Attacks
SMS Phishing
Capable of advanced code analysis.
 
SandBlast Mobile
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Mobile
SandBlast Mobile identifies threats in mobile devices by using on-device, network, and cloud-based algorithms. Once a threat is detected, it triggers an automatic response to keep mobile devices and data safe. 
SandBlast Mobile can analyze behavior across several attack vectors, namely: 
OS-Level Exploits — These are exploits that target mobile operating systems. SandBlast Mobile examines the device for any signs of weaknesses, such as vulnerable versions of Open SSL (for Android) or CA certificate, proxy, or VPN configuration (for Apple). 
Mobile Application Malware — This is malicious codes hidden in mobile applications. 
Network Attacks — These are attacks on network connections. SandBlast Mobile detects Man in the Middle (MiTM) attacks on public Wi-Fi hotspots by validating the integrity of an SSL connection. It also verifies connection security by using a cloud-based honeypot that detects if a malicious actor uses an MiTM attack to break a connection. 
SMS Phishing — Also known as Smishing, this attack vector uses Short Message Service (SMS) systems to send text messages with malicious links to coax mobile device users into divulging personal information such as passwords, social security numbers, and credit card details. The SandBlast Mobile solution can detect SMS phishing scams by scanning incoming SMS messages for malicious URLs.
Aside from securing these vectors, SandBlast Mobile employs its own dynamic cloud-based sandbox to examine and reveal the vulnerabilities and exploits hiding in mobile applications. It also whitelists trustworthy applications that show behaviors typically associated with mobile threats. To whitelist these applications, it correlates risk analysis data with aggregated factors such as application developer reputation, the number of downloads, and application source. This allows end users to download the applications they need without intervention from their company’s security team.
 
SandBlast Mobile is capable of advanced code analysis by automatically capturing and reverse-engineering applications to expose code and deconstruct flows for semantic analysis. This helps identify suspicious patterns and behaviors.
 
SandBlast Mobile also determines risk scores for devices, which are regularly updated once new findings are uncovered. This continuous analysis provides organizations an up-to-date and accurate picture of mobile threats in their network, as well as detailed information about what is being done to mitigate those risks.
<número>
 [Internal Use] for Check Point employees​
SandBlast Mobile Protect – a lightweight mobile app
Behavioral Risk Engine – cloud-based
SandBlast Mobile Dashboard – cloud-based
SandBlast Mobile Gateway 
SandBlast Mobile Components
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Mobile Components
SandBlast Mobile has four dedicated components that constantly work together to protect mobile devices and their data. The constant communication between these components ensures that you are informed of any suspicious activities and threats occurring in the device. The components are:
SandBlast Mobile Protect Application
Behavioral Risk Engine
SandBlast Mobile Dashboard
SandBlast Mobile Gateway
<número>
 [Internal Use] for Check Point employees​
Gathers data and helps analyze threats.
Examines critical risk indicators. 
SandBlast Mobile Protect Application
1
©2017 Check Point Software Technologies Ltd. 
The SandBlast Mobile Protect Application 
SandBlast Mobile Protect is a lightweight mobile application that gathers data andhelps analyze threats to the mobile device. The application monitors the mobile operating system, application information, and network connections. It also provides data to the mobile Threat Prevention solution, which is used to identify suspicious or malicious behavior. The application examines critical risk indicators found in the data it collects. It does not collect or examine sensitive data such as content or files. 
To minimize use of device resources and bandwidth SandBlast Mobile Protect performs some of its analyses on the device, while resource-intensive analyses are performed in the cloud. 
<número>
 [Internal Use] for Check Point employees​
Receives information from SandBlast Mobile Protect to perform an in-depth mobile threat analysis.
Generates a risk score based on threat type and severity.
Triggers SandBlast Mobile Protect to notify the end user of risk level and possible mitigating actions.
The Behavioral Risk Engine
1
©2017 Check Point Software Technologies Ltd. 
The Behavioral Risk Engine 
The cloud-based Behavioral Risk Engine (BRE) receives information sent by the SandBlast Mobile Protect application, which includes the device’s network, configuration, operating system integrity, and metadata related to the installed applications. It harnesses this data to perform an in-depth mobile threat analysis. This analysis helps detect and monitor possible dubious activities on the device. 
The BRE generates a risk score based on threat type and severity. The risk score determines if and what mitigation is needed to keep the device and its data protected. Once a threat is identified, it triggers the SandBlast Mobile Protect application to notify the end user of the risk level and possible mitigating actions. 
<número>
 [Internal Use] for Check Point employees​
Helps manage and monitor devices.
Configured as a per-customer instance.
SandBlast Mobile Dashboard
1
©2017 Check Point Software Technologies Ltd. 
The SandBlast Mobile Dashboard 
The cloud-based SandBlast Mobile dashboard helps you manage and monitor devices and policies. It is configured as a per-customer instance. 
This dashboard can be integrated with an existing Mobile Device Management/Enterprise Mobility Management solution for automated policy enforcement on devices at risk. When integrated, the Mobile Device Management/Enterprise Mobility Management serves as a repository on which the dashboard synchronizes enrolled devices and identities. 
Using the dashboard, you can register new devices using personal information such as a user’s name, email address, and phone number. The personal information is processed by the dashboard and may also be stored in the dashboard.
<número>
 [Internal Use] for Check Point employees​
Handles all solution communications with enrolled mobile devices.
Stores data elements, such as:
the unique identifier of the registered device.
viewable application certificates.
SandBlast Mobile Gateway
1
©2017 Check Point Software Technologies Ltd. 
The SandBlast Mobile Gateway 
The cloud-based SandBlast Mobile gateway is a multi-tenant architecture to which mobile devices are registered. It handles all solution communications with enrolled mobile devices. The gateway also stores data elements, such as the unique identifier of the registered device and application certificates that may be viewable per customer instance from the organization’s dashboard. Personal information is not processed by or stored in the gateway.
<número>
 [Internal Use] for Check Point employees​
SandBlast Mobile Workflow
The SandBlast Mobile Protect app detects changes in applications or network connections.
SandBlast Mobile Protect sends encrypted artifacts to the SandBlast Mobile gateway using SSL. 
The gateway receives data from the device. 
The gateway aggregates application artifacts for identification and analysis. 
The BRE initiates the analysis to identify the risk type and assess severity of the risk. 
The BRE assigns a risk score to the specific application_id.
Analysis results and application metadata are stored in the BRE database. The BRE sends out a risk score and application_id to the gateway. 
The gateway evaluates risk, score, and application_id. If malicious, it sends a warning to the SandBlast Mobile Dashboard. 
The dashboard sends an alert to SandBlast Mobile Protect. 
1
©2017 Check Point Software Technologies Ltd. 
SandBlast Mobile Workflow
The SandBlast Mobile Threat Prevention solution and its components protect mobile devices from advanced mobile malware, spyware, viruses, and other threats. Below is a detailed workflow of how the components work together.
The SandBlast Mobile Protect application detects changes in applications or network connections with possible MiTM vulnerability.
SandBlast Mobile Protect sends encrypted artifacts to the SandBlast Mobile gateway using SSL. 
The gateway receives data from the device. The gateway process application list is compared to known Application Risk Assessment based on application_id. 
The gateway aggregates application artifacts for identification and analysis. It retrieves the copy of the application online or from the device if not available online. 
The BRE initiates the analysis to identify the risk type and assess severity of the risk. 
The BRE assigns a risk score to the specific application_id.
Analysis results and application metadata are stored in the BRE database. The BRE sends out a risk score and application_id to the gateway. 
The gateway evaluates risk, score, and application_id. If malicious, it sends a warning to the SandBlast Mobile Dashboard. 
The dashboard sends an alert to SandBlast Mobile Protect. The dashboard also alerts the company’s Mobile Device Management/Enterprise Mobility Management, so long as they are configured to do so. 
<número>
Chapter 7 Review Questions
How does SandBlast Threat Emulation and Threat Extraction prevent threats like zero-day attacks and APT?
To prevent these threats, Threat Emulation performs CPU-level inspection of incoming files to look for signs of exploit methods. It runs the inspection in a sandbox environment, away from the organization’s network. If files exhibit malicious routines, Threat Emulation deletes them promptly. 
While Threat Emulation performs the inspection, Threat Extraction provides a clean, sanitized version of the file. This is to avoid any disruption to the company's daily operations.
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
Chapter 7 Review Questions
How does IPS complement the Firewall Software Blade when it comes to preventing threats?
While Firewall blocks network traffic based on source, destination, and port information, IPS analyzes its contents. This is to prevent threats such as drive by download, which are known to hide malicious codes behind hijacked, legitimate websites. 
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
 [Internal Use] for Check Point employees​
Upload a file for Threat detection and emulation.
Configure Threat Emulation.
Lab 7.4: Deploying Threat Emulation and Threat Extraction
LAB BREAK
1
©2017 Check Point Software Technologies Ltd. 
Performance Objectives
<número>
THANK YOU
 [Internal Use] for Check Point employees​
1
©2017 Check Point Software Technologies Ltd. 
©2017 Check Point Software Technologies Ltd.