Redes · Firewall · Check Point · Gaia OS · SmartConsole · ClusterXL · VPN · IPS

Duarte Spínola · 25 de Junho de 2026

Check Point 2026: Access Control, NAT, IPS e ClusterXL — Guia Prático para PME

O Check Point é uma das firewalls de próxima geração com maior penetração em grandes empresas e sector público, conhecida pela arquitectura de blades (módulos activáveis individualmente), gestão centralizada via SmartConsole e o sistema operativo Gaia. Ao contrário de FortiGate ou Palo Alto, onde a gestão e o gateway estão no mesmo appliance, o Check Point separa o Security Management (SMS — servidor de gestão) do Security Gateway (a firewall que processa tráfego). Esta separação traz vantagens em ambientes com múltiplas firewalls geridas centralmente, mas adiciona complexidade inicial. Este guia cobre as configurações principais que um sysadmin precisa de dominar: access control policy, NAT, IPS/threat prevention, Identity Awareness, VPN SSL/IPsec, ClusterXL e CLI troubleshooting. As fontes oficiais estão referenciadas inline, baseadas na documentação R82 e R81.20 (SmartConsole OLH R82).

Neste artigo

  1. Entender a Arquitectura do Check Point
  2. Pré-requisitos e Conceitos Essenciais
  3. Passo 1 — Security Zones e Anti-Spoofing
  4. Passo 2 — Access Control Policy com Inline Layers
  5. Passo 3 — Configurar NAT (Hide e Static)
  6. Passo 4 — Activar IPS e Threat Prevention
  7. Passo 5 — Configurar Identity Awareness com Active Directory
  8. Passo 6 — VPN IPsec Site-to-Site entre Dois Gateways
  9. Passo 7 — VPN SSL / Mobile Access para Teletrabalho
  10. Passo 8 — Configurar ClusterXL (High Availability)
  11. CLI Troubleshooting (fw monitor, cpstat, cphaprob)
  12. Erros Comuns de Configuração
  13. Checklist Rápido de Verificação

1. Entender a Arquitectura do Check Point

O Check Point usa uma arquitectura de dois componentes:

Componente Função Analogia
Security Management Server (SMS) Gestão centralizada — policies, objectos, logs, relatórios O “cérebro” — toma decisões
Security Gateway Processa tráfego, aplica policies, faz NAT, VPN, IPS O “músculo” — executa as decisões

O SMS compila as policies definidas no SmartConsole e instala-as nos gateways. Um único SMS pode gerir dezenas de gateways. Em PME, é comum usar um appliance que faz de SMS e gateway simultaneamente (modo standalone), embora a separação seja recomendada para produção (SmartConsole OLH R82).

O sistema operativo dos appliances é o Gaia OS — um Linux customizado com uma camada de configuração própria (Gaia Web UI e Gaia Clish para CLI). O Gaia gere interfaces de rede, routing, DNS, NTP, backups e licenciamento. A configuração de segurança (policies, NAT, VPN) é feita no SmartConsole — a aplicação de gestão que liga ao SMS.

O Check Point organiza funcionalidades em blades — módulos que podem ser activados ou desactivados por gateway:

  • Firewall — access control (a base, sempre activa)
  • IPS — intrusão e prevenção de ataques
  • Application Control — identifica e controla aplicações
  • URL Filtering — filtra sites por categoria
  • Anti-Bot — bloqueia comunicação com botnets
  • Anti-Virus — detecta malware em tráfego
  • Threat Emulation — sandbox de ficheiros
  • Identity Awareness — mapeia utilizadores a IPs
  • IPsec VPN — VPN site-to-site
  • Mobile Access — VPN SSL para teletrabalho

⚠ Atenção

Cada blade activa consome CPU e memória no gateway. Activar todos os blades num appliance pequeno (Quantum Spark) pode degradar performance. Para PME, activar: Firewall + IPS + Application Control + URL Filtering + Anti-Virus + IPsec VPN. Threat Emulation só se houver licença e hardware suficiente.

2. Pré-requisitos e Conceitos Essenciais

Antes de configurar policies e NAT, é necessário entender os conceitos base do Check Point:

Security Zones — Cada interface do gateway é classificada como Internal (confiável), External (não confiável) ou DMZ. Esta classificação activa anti-spoofing automático — o gateway rejeita pacotes que chegam numa interface de uma rede que não deveria estar acessível por essa interface.

Access Roles — Objectos que combinam identidade (utilizador/grupo do AD) com rede (IP/subnet). Permitem criar regras como “permitir DOMAIN\Finance aceder ao ERP” em vez de “permitir 192.168.1.50”.

Inline Layers — Camadas de policy aninhadas. Uma regra na Access Control Layer principal pode enviar tráfego para uma Inline Layer para inspecção mais detalhada. Isto permite organizar policies por departamento ou zona sem uma lista única de centenas de regras.

Policy Installation — As alterações no SmartConsole ficam pendentes até serem instaladas (Install Policy). O SMS compila a policy e envia-a para os gateways seleccionados. Sem instalação, as alterações não estão activas.

SIC (Secure Internal Communication) — Protocolo de comunicação segura entre SMS e gateways. Usa certificados mútuos. É configurado na adesão do gateway ao SMS — sem SIC, o gateway não pode receber policies.

Gaia Clish — A CLI de configuração do sistema operativo Gaia (rede, routing, DNS). Diferente da CLI de firewall (fw, cpstat, cphaprob) que opera em expert mode.

3. Passo 1 — Security Zones e Anti-Spoofing

A configuração de zonas é feita no SmartConsole, no objecto do gateway:

  1. Abrir SmartConsole > Gateways & Servers
  2. Duplo-clique no gateway object
  3. Navegar para Topology
  4. Para cada interface, definir:
  • Network: a subnet ligada à interface (ex.: 192.168.1.0/24)
  • Security Zone: Internal, External ou DMZ
  • Anti-Spoofing: Enabled (recomendado em todas as interfaces)

Configuração típica para PME:

Interface Network Zone Anti-Spoofing
eth0 (WAN) 203.0.113.0/29 External ON
eth1 (LAN) 192.168.1.0/24 Internal ON
eth2 (DMZ) 192.168.10.0/24 DMZ ON

O anti-spoofing impede que, por exemplo, um pacote com IP de origem 192.168.1.50 (rede interna) chegue pela interface eth0 (WAN/External). O gateway sabe que 192.168.1.0/24 só é acessível via eth1 e rejeita o pacote.

⚠ Atenção

Se adicionar novas redes ou alterar a topologia, é necessário actualizar a topologia do gateway e fazer install policy. O anti-spoofing baseia-se na topologia definida — se a topologia está desactualizada, tráfego legítimo pode ser bloqueado.

4. Passo 2 — Access Control Policy com Inline Layers

A Access Control Policy é a rulebase principal — determina que tráfego é permitido, negado ou droppado entre zonas. As regras são avaliadas de cima para baixo — a primeira que corresponde determina a acção (SmartConsole OLH R82).

Estrutura de uma regra:

  • Source: rede, grupo ou Access Role de origem
  • Destination: rede, grupo ou servidor de destino
  • Service & Applications: porta/protocolo OU aplicação (App Control)
  • Action: Accept, Drop, Reject, Inform
  • Track: Log, Alert, None
  • Install On: gateway específico ou All

Ordem recomendada para PME:

  1. Regra de gestão — permitir tráfego da sub-rede de administração para o gateway
  2. Outbound — Internal → External para aplicações permitidas
  3. DMZ inbound — External → DMZ para serviços publicados (restrito)
  4. VPN — tunnel → Internal (com Access Roles)
  5. Cleanup rule — Any → Any → Drop (no fim da lista)

Criar regra outbound (Internal → External):

  1. Navegar para Security Policies > Access Control
  2. Adicionar nova regra:
  • Source: Internal_Network (objecto de rede criado previamente)
  • Destination: Any
  • Service & Applications: HTTP, HTTPS, DNS (ou aplicações via App Control)
  • Action: Accept
  • Track: Log
  1. Clicar Install Policy para activar

Inline Layers para organizar policies:

Para PME com muitas regras, as Inline Layers permitem organizar a policy por zona ou departamento:

  1. Na regra principal, em Action, seleccionar Inline Layer
  2. Seleccionar ou criar uma Inline Layer (ex.: DMZ_Rules)
  3. Na Inline Layer, criar regras específicas para tráfego DMZ

Nota: Usar Drop em vez de Reject para a cleanup rule. Reject envia uma resposta TCP RST/ICMP, que revela a existência da firewall a um atacante. Drop descarta silenciosamente — o atacante não sabe se o tráfego foi bloqueado ou se o servidor não existe.

Application Control e URL Filtering:

O Check Point identifica milhares de aplicações independentemente da porta. Para activar:

  1. No gateway object, activar a blade Application Control e URL Filtering
  2. Na Access Control Policy, na coluna Service & Applications, adicionar aplicações (ex.: Facebook, BitTorrent, WhatsApp)
  3. Definir acção por aplicação: Allow, Drop, Ask (pedir confirmação ao utilizador)
  4. Para URL Filtering, criar um perfil que bloqueia categorias: Malware, Phishing, Adult Content, Social Networking

5. Passo 3 — Configurar NAT (Hide e Static)

O Check Point tem dois tipos principais de NAT:

Tipo Uso Exemplo
Hide NAT Múltiplos IPs internos traduzidos para um IP público (o do gateway) Clientes LAN a aceder à internet
Static NAT Mapeamento 1:1 entre IP público e IP interno Servidor DMZ acessível via IP público

Hide NAT para tráfego outbound:

  1. Navegar para Security Policies > Access Control > NAT Rules
  2. Adicionar regra:
  • Original Source: Internal_Network (192.168.1.0/24)
  • Original Destination: Any
  • Translated Source: Hide behind gateway
  • Translated Destination: Original
  1. Install Policy

Ou usar NAT automático: no objecto de rede, marcar Add Automatic NAT Rules e seleccionar Hide behind gateway. O SmartConsole gera as regras NAT automaticamente.

Static NAT para servidor DMZ:

  1. Criar objecto de rede para o servidor (ex.: Web_Server = 192.168.10.100)
  2. No objecto, secção NAT, adicionar:
  • Static NAT: activar
  • Public IP: 203.0.113.20 (IP público do servidor)
  1. O SmartConsole gera automaticamente:
  • Regra de Source NAT (servidor → internet: traduz 192.168.10.100 para 203.0.113.20)
  • Regra de Destination NAT (internet → servidor: traduz 203.0.113.20 para 192.168.10.100)

⚠ Atenção

Tal como no PAN-OS, a regra de Access Control deve permitir o tráfego traduzido. Se o tráfego vem da internet (External) para o IP público do servidor, a Access Control rule deve ter como destination o IP interno (192.168.10.100), não o IP público. O NAT é aplicado antes da inspecção da Access Control.

6. Passo 4 — Activar IPS e Threat Prevention

O Check Point Threat Prevention engloba várias blades que actuam em conjunto (SmartConsole OLH R82):

Blade Função Recomendação PME
IPS Detecta e previne ataques conhecidos (signatures) Activar em modo Prevent
Anti-Bot Bloqueia comunicação com servidores C&C Activar
Anti-Virus Detecta malware em tráfego web/email Activar
Threat Emulation Sandbox de ficheiros suspeitos Opcional (requer licença)
Zero Phishing Protege contra páginas de phishing Activar

Configuração de IPS:

  1. No gateway object, activar a blade IPS
  2. Navegar para Security Policies > Threat Prevention
  3. Criar ou editar um Threat Prevention Profile:
  • IPS: activar, modo Prevent (não apenas Detect)
  • Anti-Bot: activar, modo Prevent
  • Anti-Virus: activar, modo Prevent
  • Confidence Levels: Low, Medium, High (determina quantas signatures activar)
  1. Aplicar o profile às regras de Access Control que devem ser inspecionadas

Nota: Começar com IPS em modo Detect durante 1-2 semanas para identificar falsos positivos no tráfego real. Depois mudar para Prevent. Usar o perfil Optimized em ambientes com restrições de performance — activa apenas as signatures de maior confiança e menor impacto.

Actualização de signatures:

As signatures de IPS, Anti-Bot, Anti-Virus e URL Filtering são actualizadas via SmartUpdate (ou automaticamente se configurado). Verificar em SmartConsole > SmartUpdate que os updates estão a ocorrer regularmente. Sem updates, o IPS não detecta ameaças recentes.

7. Passo 5 — Configurar Identity Awareness com Active Directory

O Identity Awareness mapeia endereços IP a utilizadores e grupos do Active Directory, permitindo criar regras de Access Control baseadas em identidade. Para PME com Active Directory, a configuração usa o Identity Agent instalado num Domain Controller (SmartConsole OLH R82).

Configuração passo a passo:

  1. No gateway object, activar a blade Identity Awareness
  2. Configurar Identity Sources:
  • AD Query: o gateway consulta o DC por eventos de login
  • Identity Agent: software instalado num DC que envia mapeamentos em tempo real (mais preciso que AD Query)
  1. Criar Access Roles em SmartConsole > Objects > Access Roles:
  • Name: Finance_Users
  • Users: DOMAIN\Finance (grupo do AD)
  • Networks: 192.168.1.0/24 (subnet onde os utilizadores estão)
  1. Usar o Access Role na Access Control Policy:
  • Source: Finance_Users
  • Destination: ERP_Server
  • Action: Accept

Verificação no CLI (Gaia expert mode):

# Verificar sessoes de Identity Awareness
pdp monitor all

# Estado do PDP (Policy Decision Point)
pdp show status

# Configuracao AD LDAP
adldconfig

Nota: O Identity Agent é mais preciso que o AD Query porque reporta logins e logouts em tempo real. O AD Query tem latência — só detecta o utilizador no próximo intervalo de consulta. Para ambientes onde a precisão é crítica (ex.: regras que negam acesso a utilizadores desligados), usar o Identity Agent.

8. Passo 6 — VPN IPsec Site-to-Site entre Dois Gateways

A VPN IPsec site-to-site liga dois sites através de um túnel encriptado. O Check Point usa o conceito de VPN Communities — grupos de gateways que comunicam entre si (SmartConsole OLH R82).

Configuração:

  1. Em ambos os gateways, activar a blade IPsec VPN
  2. Navegar para Security Policies > VPN Pro > VPN Communities
  3. Criar uma Meshed Community (todos os gateways comunicam com todos) ou Star Community (hub-spoke):
  • Name: Site-to-Site
  • Participating Gateways: adicionar Gateway A e Gateway B
  • IKE Phase 1: AES-256, SHA-256, DH Group 14
  • IKE Phase 2: AES-256, SHA-256, PFS DH Group 14
  • Shared Secret: pre-shared key (ou certificados)
  1. Em cada gateway, configurar o Encryption Domain (redes que o gateway anuncia como protegidas):
  • Gateway A: 192.168.1.0/24
  • Gateway B: 192.168.2.0/24
  1. Install Policy em ambos os gateways

Verificação do túnel no CLI:

# Estado das VPN tunnels
cpstat vpn

# Ver IKE SAs
vpn tu tlist

# Debug de negociação IKE
vpn debug on
# … tentar estabelecer túnel …
vpn debug off

# Ver logs de VPN
fw log -t | grep -i vpn

(Check Point CLI Reference Guide R81.20 — VPN Debug)

9. Passo 7 — VPN SSL / Mobile Access para Teletrabalho

O Mobile Access é a solução de VPN SSL da Check Point para acesso remoto de utilizadores. Permite ligação via browser (web portal) ou via cliente (Check Point Mobile / SecureClient) (SmartConsole OLH R82).

Configuração:

  1. No gateway, activar a blade Mobile Access
  2. Configurar Office Mode (atribuir IPs aos clientes VPN a partir de uma subnet dedicada):
  • Subnet: 10.10.60.0/24
  • Assignment: DHCP ou manual
  1. Navegar para Security Policies > Access Control e criar regra:
  • Source: VPN_Clients (Access Role ou rede 10.10.60.0/24)
  • Destination: Internal_Network (192.168.1.0/24)
  • Action: Accept
  1. Configurar Split Tunneling se necessário (apenas tráfego interno vai pelo túnel)
  2. Configurar autenticação:
  • LDAP/AD para credenciais
  • MFA via RADIUS ou Check Point Mobile OTP
  1. Install Policy

Acesso dos utilizadores:

Os utilizadores acedem via browser a https://vpn.empresa.pt (FQDN configurado no portal) e autenticam-se. Para tunnel mode, descarregam e instalam o cliente Mobile Access.

⚠ Atenção

Para acesso SSL VPN, é necessário um certificado válido no portal. Usar Let’s Encrypt ou CA comercial — um certificado self-signed gera avisos nos browsers e pode impedir a instalação do cliente em máquinas geridas por MDM.

10. Passo 8 — Configurar ClusterXL (High Availability)

O ClusterXL é a solução de HA da Check Point. Dois modos principais:

Modo Descrição Recomendação PME
Active/Passive (HA) Um membro processa tráfego, o outro fica standby Recomendado — simples e fiável
Active/Active (Load Sharing) Todos os membros processam tráfego simultaneamente Complexo — só para ambientes com necessidades de throughput

Configuração Active/Passive:

  1. Em ambos os gateways, configurar interfaces com os mesmos IPs físicos e um IP virtual (cluster IP) por interface
  2. No SmartConsole, criar Cluster Object:
  • Network Objects > New > Cluster
  • Mode: High Availability
  • Sub-mode: Primary Up (o membro com prioridade mais alta reassume quando recupera) ou Active Up (o membro actual mantém-se activo)
  1. Adicionar Cluster Members (os dois gateways)
  2. Configurar Synchronization:
  • Sync Interface: interface dedicada para sync (ex.: eth3, /30 subnet)
  • Full Sync vs Delta Sync: Full Sync sincroniza toda a state table; Delta Sync apenas as alterações
  1. Configurar Cluster Control Protocol (CCP): Broadcast ou Unicast
  2. Configurar Cluster Monitoring: interfaces a monitorar para detectar falhas
  3. Install Policy no cluster object

Verificação no CLI (Gaia expert mode):

# Estado do cluster
cphaprob state

# Estatisticas de failover
cphaprob show_failover

# Interfaces monitoradas
cphaprob -a if

# Reset de contadores de failover
cphaprob -reset show_failover

O output do cphaprob state mostra o modo do cluster, o ID de cada membro, o IP único, a carga atribuída e o estado (ACTIVE, STANDBY, DOWN) (Check Point CLI Reference — Cluster State).

💡 Nota

Para ClusterXL, é necessário que ambos os gateways sejam do mesmo modelo com a mesma versão de software e patches. Usar pelo menos uma interface dedicada para sync — não usar a interface de gestão para sync de produção. Em ambientes onde multicast não é suportado (alguns switches/cloud), usar CCP em modo Unicast.

11. CLI Troubleshooting (fw monitor, cpstat, cphaprob)

O Gaia OS tem dois modos de CLI: Gaia Clish (configuração do sistema operativo) e Expert mode (comandos de firewall/debug). Os comandos mais úteis para troubleshooting são (CLI Reference Guide R81.20):

fw monitor (captura de pacotes no nível da firewall):

# Capturar trafego de um IP especifico
fw monitor -e “accept src=192.168.1.50 and dst=203.0.113.10;”

# Capturar por porta
fw monitor -e “accept dport=80;”

# Capturar TCP apenas
fw monitor -e “accept ip_p=6;”

# Guardar para ficheiro
fw monitor -o /tmp/capture.txt -e “accept;”

O fw monitor mostra os pacotes em 4 pontos: i (inbound antes da firewall), I (inbound depois), o (outbound antes), O (outbound depois). Isto permite ver exactamente onde o pacote é processado ou droppado (CLI Reference — fw tab).

cpstat (estado dos blades):

# Estado geral da firewall
cpstat fw

# Estado VPN
cpstat vpn

# Estado HA
cpstat ha

# Todos os blades
cpstat -f all

fw ctl (conexões e performance):

# Tabela de conexoes activas
fw ctl conntab

# Estatisticas de performance
fw ctl pstat

(CLI Reference — fw ctl conntab)

fw tab (kernel tables):

# Listar todas as kernel tables
fw tab -s

# Ver tabela de conexoes (ID 8158)
fw tab -t connections -f

# Resumo da tabela
fw tab -t connections -s

Logs em tempo real:

# Tail dos logs da firewall
fw log -t

# Filtrar logs por IP
fw log -t | grep 192.168.1.50

⚠ Nota

O fluxo de troubleshooting recomendado é: (1) cpstat fw para ver se a firewall está activa; (2) fw monitor para capturar pacotes e ver se chegam ao gateway; (3) fw ctl zdebug drop para ver que pacotes estão a ser droppados e porquê; (4) cphaprob state se for um problema de HA; (5) vpn debug on se for um problema de VPN.

12. Erros Comuns de Configuração

Problema Causa Solução
Policy não aplica após Install Erro de SIC entre SMS e gateway Verificar SIC: cp_conf sic no gateway. Re-inicializar SIC se necessário
NAT não funciona para servidor DMZ Access Control rule usa IP público em vez do interno A regra de Access Control deve usar o IP interno (depois da tradução NAT)
Tráfego droppado sem regra deny Anti-spoofing activo com topologia desactualizada Actualizar topologia do gateway (Topology tab) e fazer install policy
VPN IPsec não estabelece Mismatch de IKE parameters entre os dois gateways Verificar que Phase 1 e Phase 2 são idênticos. Usar vpn debug on para diagnóstico
Identity Awareness não mapeia utilizadores Identity Agent não instalado ou AD Query sem permissões Instalar Identity Agent no DC. Verificar que a conta de serviço tem permissões de leitura no AD
IPS bloqueia tráfego legítimo Signatures em modo Prevent com falsos positivos Mudar IPS para Detect, analisar logs, excluir signatures problemáticas. Depois voltar a Prevent
ClusterXL não faz failover Sync interface em baixo ou CCP bloqueado Verificar cphaprob -a if para estado das interfaces. Garantir que a sync interface está UP
Mobile Access não conecta Certificado self-signed ou porta 443 bloqueada Importar certificado de CA confiável. Verificar porta 443 na WAN
Install Policy falha Memória insuficiente no gateway ou policy muito grande Verificar fw ctl pstat. Simplificar Inline Layers. Considerar upgrade de hardware
Performance degradada Todos os blades activos em hardware insuficiente Desactivar Threat Emulation se não for essencial. Usar perfil IPS Optimized

13. Checklist Rápido de Verificação

  • [ ] Configurar topologia e security zones em todas as interfaces (Internal, External, DMZ)
  • [ ] Activar anti-spoofing em todas as interfaces
  • [ ] Criar regra cleanup no fim da Access Control (Any → Any → Drop com Log)
  • [ ] Usar Drop em vez de Reject na cleanup rule (não revela a firewall)
  • [ ] Configurar Hide NAT para tráfego outbound (Internal → External)
  • [ ] Configurar Static NAT para servidores DMZ com IP público dedicado
  • [ ] Activar blades: IPS, Anti-Bot, Anti-Virus, Application Control, URL Filtering
  • [ ] Começar IPS em modo Detect, migrar para Prevent após 1-2 semanas
  • [ ] Criar Threat Prevention Profile e aplicar às regras allow
  • [ ] Activar Identity Awareness e configurar Identity Agent no DC
  • [ ] Criar Access Roles (AD groups + network) para regras baseadas em identidade
  • [ ] Configurar VPN Community com IKEv2, AES-256, SHA-256, PFS
  • [ ] Configurar Mobile Access com Office Mode e certificado válido
  • [ ] Activar MFA para VPN SSL (Mobile OTP ou RADIUS)
  • [ ] Configurar ClusterXL Active/Passive se houver dois gateways
  • [ ] Verificar sync interface dedicada para ClusterXL
  • [ ] Verificar com cphaprob state que ambos os membros estão saudáveis
  • [ ] Activar SmartUpdate para updates automáticos de signatures
  • [ ] Fazer backup regular do SMS: migrate export
  • [ ] Testar fw monitor e cpstat fw para confirmar que a firewall processa tráfego

Artigos Relacionados

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário