Resumo_CCSE_V3

Prévia do material em texto

Upgrade Tools
· migrate.conf
· migrate
· pre_upgrade_verifier
Advanced upgrade With database Migration
· Tamanho do /var/log da máquina destino deve ter no mínimo 25% a maior do que a máquina de origem
· Máquina destino deve estar conectada na rede e deve ter IP (diferente da SMS em produção)
· A versão deve ser no mínimo igual a atual ou superior
· Deve-se utilizar o migrate_tools da versão destino desejada
CPUSE Agent
Agente de atualização de versão e/ou Hotfix via WebUI e/ou CLI
# show installer status build (exibe versão do cpuse)
CPUSE Updates Policy
Via WebUI pode ser realizado de 3 modos:
· Manual (default)
· Scheduled
· Automatic
Upgrade de Versão
Sempre deve ser realizado primeiro upgrade da SMS e somente posteriormente os GWs.
O SMS é capaz de gerenciar GWs de versões iguais ou inferiores as dele.
Comandos CLI
· add
· set
· show-save
· delete
· cpstart;cpstop
No modo expert é possível utilizar comandos Linux (ls, cd, pwd...) e também pode-se utilizar scripts.
· dbedit - cria e configura objetos e regras no database da Security policy
· fwm load - instala uma Security Policy Específica nos GWs; uso:
 #fwm load <IP_SMS>
· send_command - executa funções que não estão incluídas nos comandos CLI standart.
CheckPoint CLISH
· set clienv - define o ambiente CLI para um usuário
· save client - salva o ambiente para o cliente
· lock database override - assume o lock de configuração
· set inactivity-timeout <valor_em_minutos> - define período de inatividade na CLI
· fwm stat - verifica se o GW foi capaz de buscar(fetch) as políticas no SMS.
CPInfo
Utilitário da CheckPoint que coleta dados e informações de diagnóstico dos equipamentos Checkpoint.
· cpinfo 
Exemplo:
· cpinfo -y all (exibe as informações de versão Gaia e Hotfix instalados)
Flags:
· -l (incluí log no arquivo de saída gerado)
· -z (comprime o arquivo de saída utilizando o gzip)
· -v (verbose)
· -n não cria um arquivo cpinfo, deve ser usado com funções
· -o <nome_do_arquivo> direciona a saída para um arquivo e para a tela.
· -y (exibe todos hotfixes instalados)
· -k (incluí tabelas de firewall na saída)
· -i (modo não interativo)
· -d (não checa por updates)
· -a (força o check por update)
· -u (conecta ao user center do usuário com user and password)
· -e <e-mail> (notifica via e-mail o status do upload do arquivo; mais de um mail 
· eve ser usado aspas duplas e separado por ; )
· -s <número_SR> (especifica o SR aberto com a Checkpoint)
· -x <VSID> - gera o CPinfo para uma certa VSID (somente no modo VSID)
CPView 
Cpview é uma utilidade embutida text-based da CheckPoint. O Utilitário CPview exibe dados estatísticos que contém tanto informação geral do sistema (CPU, memória, Espaço em disco) e informações sobre diferentes Software Blades (somente no GW)
O CPview atualiza constantemente os dados para um fácil acesso a visualização, no GW é possível usar os dados estatísticos para monitorar performance.
Sintaxe
cpview
User Interface
É dividida em três sessões:
Usando o CPview
Teclas para navegação:
Teclas para alterar opções da interface do CPview:
Teclas para salvar estatísticas, exibir ajuda e atualizar estatísticas:
Infraestrutura de Firewall CheckPoint
Os componentes da infraestrutura de Firewall Checkpoint é dividida nos seguintes componentes:
· GUI Client
· Security management (SMS)
· Security Gateway (GW)
GUI Client
Aplicações GUI (Graphic User Interface), para manipulação de objetos, Log view e reporting, tal qual SmartView Monitor, SmartEvent, são todos unificados em um único console (SmartConsole). Essas aplicações GUI oferecem a habilidade de configurar, gerenciar e monitorar as soluções de segurança, tarefas de manutenção, gerar reports e enforce de políticas corporativas em real-time.
Security Management
É o componente responsável por todas operações de gerenciamento do sistema. Contem diversos elementos, tais como SMS, reporting suite, log server e etc. Todas as funcionalidades do Management Server é implementada no processo User-mode, onde cada processo é responsável por diversas operações. 
Check Point Management (cpm) é o principal processo. Esse processo prove a arquitetura para um ambiente de segurança unificado. CPM permite o cliente GUI e o management server a comunicar via serviços web usando porta TCP 19009. O processo cpm executa tarefas de database, tais como criar, deletar, e modificar objetos, e compilar política. Processos controlados pelo CPM incluem:
· web-services - transfere requisições para o dle_server.
· dle_server - Contem toda a lógica do servidor e valida a s informações antes de serem salvas na database.
· object_store - Traduz e salva dados na database.
CPM salva todos os dados no database do Postgress SQL e armazena a maior parte dos dados no Solr(um servidor standalone de busca provido pela Lucene HJava Search library). O database Postgres SQL contém objetos, políticas, usuários, administradores, licenças, e dados de gerência. Os dados sãos segmentados em múltiplos domínios de database. Solr gera indexes dos dados para serem utilizados para a capacidade de busca completa em forma de texto .
Processos
CPM
· É o principal processo de gerenciamento e utiliza a porta TCP 19009.
· Salva todos os dados no Postgress SQL database e armazena a maioria dos dados no Solr.
· Postgres SQL contém objetos, políticas, usuários, administradores, licenças e management data. Os dados são armazenados segmentados em múltiplos domínios de database. Solr gera indexes para os dados para possibilitar a busca por full text. O processo CPM efetua tarefas na database, tais como, criar, deletar e modificar objetos, e regras.
Arquitetura CPM
· Fwm - presente em todos os produtos checkpoint que requerem acesso direto ao GUI (ex. SmartEvent), utilizado principalmente para retro-compatibilidade de gateways. Permite a comunicação GUI client, manipulação do database; compilação de políticas e Management high Availability Synchronization.
· Fwd - Firewall Daemon permite processos incluindo kernel, de encaminhar logs para log servers externos tal como SMS. Pela cli se comunica com SMS via comando fw, variáveis de kernel; kernel control commands.
· Fwssd - processo “filho”do fwd. Responsável por gerenciar GWs os quais provê alto nível de protocol enforcement.
· Cpd - Processo central de todo produto CheckPoint. Permite o SIC; puxa status de monitoramento, transfere mensagens entre processos do firewal, busca e instala políticas e mais...
· Cpwd - Checkpoint WhatchDog, invoca e monitora processos críticos, tais como os Daemons CheckPoint na máquina local e tenta reiniciá-los se eles falharem. Dentre estes processos estão cpwd, cpd, fwd e fwm. O utilitário cpwd-admin exibe o status dos processos e configura o cpwd.
Security Gateway
Componente responsável pelo enforcement de segurança, criptografar/descriptografar, autenticação e accounting.
A funcionalidade do Security Gateway é implementada tanto em User Mode quanto kernel. O GW é um dispositivo de rede rodando um SO o que o torna vulnerável a ataques de Network layer (L2). Para mitigar estas vulnerabilidades algumas das funcionalidades de Firewall são implementadas no Kernel mode. Isto permite ao tráfego ser inspecionado antes mesmo de chegar ao IP stack do SO.
Kernel do Sistema Operacional
Firewall Kernel
É responsável pela maioria das operações do GW, tais como , enforcement de segurança, criptografar/descriptografar, NAT e etc.
Existem processos que operam no nível de espaço do User Mode e outros no espaço de Kernel mode.
Processos User e Kernel Mode 
O Kernel mode reside na camada Data Link do modelo OSI. O Kernel de Firewall inspeciona os pacotes entre a layer Data Link e a layer de Network. Todo pacote que passa pelo firewall é inspecionado.
User mode não é mandatório, entretanto, permite o Firewall funcionar de maneira mais eficiente na Application Layer. O firewall emprega serviços do SO e permite uma inspeção mais fácil de arquivos em conexões abertas.
É possível que em alguns casos requeiram que os processos deuser e kernel se comuniquem. Para permitir isto existem dois mecanismos: Input/Output Controls (IOctl) e traps. Quando o kernel precisa se comunicar com processos user mode ele “seta” uma trap modificando um valor na chave de registo. O processo de user mode que estiver monitorando determinada flag “cai” na trap e executa a operação requisitada. Quando uma entidade User Mode precisa “escrever” uma informação em um processo de Kernel, ele usa IOctl, o qual é uma infraestrutura que permite a entidade chamar a função no kernel e prover os parâmetros requisitados.
Processos
Packet Flow
Inbound e Outbound Traffic Flow
Tráfego chega no firewall por uma das interfaces de rede (NIC). o Kernel é instalado em cada interface (NIC) que estiver habilitada no SO. O Kernel consiste em duas partes lógicas distintas chamadas de Inbound e Outbound, que representam o processo do pacote entrando e saindo do Firewall. Esses processos trabalham cada pacote através de outro processo chamado “inspeção”. Cada parte age independentemente, não considerando se o pacote foi ou não inspecionado pelo outro. Algumas funcionalidades são implementadas ambas no Inbound e Outbound. Pontos chave incluem:
· Cada direção tem sua cadeia de módulos ordenada, ou packet handlers.
· Handlers decidem se continua, se é finalizado ou aguarda o processamento de um pacote.
· A inspeção é efetuada em pacotes virtualmente desfragmentados.
O processo de inspeção não espera que um pacote na Outbound que não tenha entrado na Inbound primeiro tenha sido originado no próprio GW. Ele também presume que um pacote não originado do GW era de entrada.
Pontos de inspeção de Kernel do Firewall CheckPoint
Packet Inspection Flow
Packet inspection Flow
1. Pacote chega ao GW e é interceptado pelo NIC no Inbound
2. O chain de Kernel Inbound do Firewall começa a inspecionar o pacote.
3. O pacote que é comparado a Rule Base. Um log é gerado e enviado do processo de Kernel para o processo de User Mode, fwd, localizado no GW.
4. O processo fwd no GW envia o log para o processo fwd no SMS, onde é encaminhado para o cpm via cpd.
5. cpm envia o log relevante para GUI do SmartConsole, tal como o SmartView Monitor.
6. Ao mesmo tempo, dependendo das decisões de roteamento do SO excluindo alguns cenários específicos como VPN routing, o pacote é roteado para a NIC selecionada. O pacote deve passar novamente pelo Kernel de Firewall, desta vez na chain Outbound da NIC e para rede.
Chain Modules
Chain Modules são handlers de processamento de pacotes. Handlers decidem qual módulo irá inspecionar o pacote, e baseado na inspeção, podendo então dar Accept ou Drop do pacote. Cada módulo em uma chain tem um único trabalho. O número de chains em um GW é baseado no número de blades e features habilitadas no firewall. Pacotes Inbound e Outbound e são inspecionados em ambas as direções dos chains.
Exemplo de Chain Module
→fw ctl chain - exibe os chains modules carregados na sua máquina em sua ordem.
Inbound fw ctl Chain Modules
No exemplo abaixo podemos ver o inbound chain, em diferentes configurações podem conter mais ou menos chains modules, diferentes dos do exemplo abaixo.
Inbound Chain
Outbound Chain
No exemplo abaixo podemos ver o outbound chain. O outbound chain exibe basicamente os mesmos chain modules vistos no Inbound. A diferença mais significante é que na inbound vpn decrypt e vpn decrypt verify estão presentes. Isto faz sentido uma vez que é esperado que o pacote seja descriptografado na Inbound. Em adição, o outbound chain contém o vpn encrypt chain module, se o pacote precisar ser criptografado no Outbound.
Outbound Chain
Wire mode
Wire mode permite conexões VPN para manter com sucesso uma VPN segura e privada sem empregar Stateful Inspection. Usando o Wired mode, o firewall pode ser “bypassado” por conexões VPN por definir interfaces internas e comunidade como “trusted”. Isto aumenta a performance do tunnel VPN e reduz o “downtime”. Sem o Stateful Inspection, protocolos de roteamento dinâmico que não sobrevivem a Stateful Inspection na configuração no modo non-Wired podem ser utilizadas (deployed). Wired mode é baseada em uma fonte e destino confiáveis e utilizam interfaces internas, tais como Security Gateways e Comunidades VPN.
Stateful Inspection
Além de checar o IP header de um pacote o Stateful Inspection implementa a checagem de outras características como TCP stream, sequências numéricas, comunicação UDP e numero das portas para monitorar o estado de um pacote operando primariamente na layer de transporte do SO. O engine de inspeção examina todo pacote assim que ele é interceptado na Layer de Network. O estado da conexão e contexto da informação são armazenados e atualizados dinamicamente nas tabelas de kernel. As tabelas de Kernel são também conhecidas como tabelas de estado (State Tables).
1. Pacotes passam pela interface de rede (NIC) no módulo de inspeção, o qual inspeciona os pacotes e os seus dados.
2. Pacotes são “matched” na policy Rule base. Pacotes que não dão match em nenhuma regra são bloqueados (drop).
3. Geração de Logs e/ou alertas que foram definidos no início.
4. Pacotes que passam pela inspeção são movidos através do TCP/IP stack para o seu destino.
5. Os pacotes que não passam pela inspeção e são rejeitados por definição de uma regra, tem um Negative Acknowledgement (NACK) enviado (i.e. RST na TCP e ICMP inalcançável na UDP)
6. Pacotes que não passam pela inspeção e não se aplica a nenhuma regra são bloqueados (dropped) sem ser enviado um NACK.
Security Servers
São elementos cruciais para as funcionalidades do Firewall. Alguns features do firewall requerem um nível mais alto de aplicação de protocolo e RFC compliance, tal como na Application Layer.
Security Servers são processos individuais entro do sistema do Firewall que são responsáveis pela inspeção detalhada de serviços como FTP, HTTP ou SIP e outros serviços de inspeção como o DLP.
NOTA: Quando realizado o deployment do Identity Awareness, estes processos operam de forma diferente.
Como um Security Server Funciona
Essencialmente, quando um cliente inicia uma conexão com o servidor, o Kernel de Firewall sinaliza para o processo fwd utilizando uma trap. O fwd por sua vez cria o processo filho fwssd, processo este que corre no Security Server. Então, o Security Server liga a um socket e gerencia a conexão.
fwd espera pelas conexões nas portas de outros servers (daemons) e inicia o server (daemon) correspondente quando a conexão é feita. fwd também “conversa” com os processos filhos em outros servers usando um pipe e sinais.
→O arquivo $FWDIR/conf/fwauth.conf contém a estrutura dos Security Servers exibindo número de portas, correspondente nome de protocolo e status. Se a porta real for 0, então, uma porta maior aleatória é designada.
Exemplo do $FWDIR/conf/fwauthd.conf
Existem muitas tabelas de Kernel, e cada uma guarda informação relevante a uma função específica do Firewall. Utilizar as informações contidas nas tabelas de Kernel, proteções muito elaboradas e precisas podem ser implementadas. Para visualizar somente os nomes das tabelas e ter uma perspectiva do número de tabelas de Kernel disponíveis utiliza-se o comando fw tab -s. 
A maioria da informação relacionada do tráfego é salva nas tabelas de Kernel. Informação também é salva em htabs, ghtabs, arrays, kbufs, e outros dispositivos. As tabelas podem ser criadas, apagadas, modificadas e lidas. 
Connections Table
A Connections Table é em sua essência uma tabela de conexões aprovadas. O Firewall, sendo um dispositivo de segurança de rede, inspeciona todo pacote entrando e saindo de cada interface. Depois cada pacote é conferido na Rule Base, assume-se que o pacote retornando não deve ser aceito na Rule Base.
Exemplo:
O IP 74.100.100.1 tem permissão de conexão com 212.150.141.5 usando Telnet na porta 23 na Rule Base, e dá drop em todo resto. O pacote Syn vai dar match na Rule Base e passar; mas o pacote Syn-Ack retorna com tuple reverso (IP de origem 212.150.141.5, destino 74.100.100.1) ea porta de origem 23 com uma porta de destino aleatória.
Para mitigar isto, para cada conexão gravada uma entrada tupple reversa dando match na RuleBase também é adicionada a lista de conexões aprovadas. Em alguns cenários como NAT, data connections e protocolos mais elaborados como VoIP, introduz mais complexidade a lógica na manutenção da Tabela de Conexões.
A Tabela de Conexões provê uma performance avançada. Ao manter uma lista de conexões aprovadas na Connections Table, o GW pode aplicar uma analise inteligente para correspondência de regras presumida, economizando tempo valioso e capacidade de computação.
Para visualizar a tabela de conexões utiliza-se o comando:
fw tab -t connections -f
NOTA
Usar o comando fw tab -t connections -f pode impactar na performance.
As Features a seguir são providas com a Connections Table:
· Streaming based applications
· Verificação de sequência e tradução
· Hide NAT (Entradas explicitas podem ser necessárias ser adicionadas na Connections table quando pacotes S2C retornando ao Firewall podem não dar match na Rule Base)
· Logging accounting, monitoring, etc.
· Identificação de Client e Server 
· Data Connections
Formato das Tabela de Conexões.
Cada novo pacote é gravado na tabela em todas entradas disponíveis. Em versões anteriores apenas uma entrada era feita para ada nova conexão. Cada pacote tinha que passar diversas vezes pela Connections table para verificar todos os tipos de conexões disponíveis. Atualmente, cada pacote precisa de uma única passagem pela tabela de conexões já que todas as entradas já estão gravadas na Connections table.
Connections Table
O formato de link simbólico proporciona 6-tuple da conexão que queremos passar. A seta é o pointer para o tuple da entrada Real na Tabela de conexões. Os primeiros seis atributos em cada entrada na Tabela de Conexões a indica a os 6 tuples da conexão. O 6-tuple é uma identificação única da conexão dentro do sistema. A direção pode ser tanto 0 para Inbound quanto 1 para Outbound.
Na imagem acima da Tabela de Conexões, podemos ver a representação de uma simples conexão na Tabela de Conexões. A primeira entrada é chamada de entrada real e contem informações relevante para aquele tráfego, tal como estado, sequência e regra em que deu match.
A entrada Real permite o pacote Client to Server (C2S) entrar no firewall no Inbound. A segunda entrada é um Link Simbólico, que permite que o mesmo pacote C2S passe no Outbound no firewall. A terceira entrada é outro Link Simbólico que permite o tráfego entre no Inbound do firewall. A última entrada também é um Link Simbólico que permite o pacote S2C passar pelo Outbound do Firewall.
Instalação de Política
O processo de instalação de políticas é dividido em três estágios principais: 
· Verificação e Compilação
· Transferência (CPTA)
· Comprometer (commit)
Processo de Instalação de política
Verificação e Compilação
O estágio de Verificação e Compilação da instalação de política ocorre no lado da gerência. Envolve os seguintes passos:
1. Initiation - A instalação de políticas é iniciado tanto pela SmartConsole tanto quanto da linha de comando (CLI).
2. Database Dump - Um despejo dos antigos formatos do postgress para o cpmitable somente se ocorrerem mudanças. O despejo de não cpmi ocorrerá a qualquer momento.
3. Verificação - As informações no database são verificadas para cumprir uma série de regras específicas para o aplicativo e pacote para o qual a instalação da política é solicitada. Se essa verificação falhar, o processo é finalizado, e uma mensagem de erro é enviada ao initiator. O sistema também pode enviar warnings em adição as mensagens de fail/success.
4. Conversion - A informação na database é convertida do seu formato inicial para um formato compreensível para os participantes seguintes do fluxo, tais como a geração de código e o gateway.
5. FWM rexec - Fwm loader consome muito da memória. Para liberar a memória após a verificação e conversão, fwm state é salvo em um arquivo localizado no diretório $FWDIR/tmp/. fwm é então re-executado como um comando, fwm load para “empurrar” os arquivos para geração de códigos e compilação.
6. Code Generation and Compilation - A política é traduzida para linguagem INSPECT e compilado com o compilador INSPECT. Também algumas transformações de dados são completadas. Depois de verificar e compilar a database, o processo fwm compila os arquivos relevantes, tais como objects_5_0.C, e AccessCTRRules_0.C, em vários arquivos (local.ft, local.set, etc.). A política compilada será copiada no diretório $FWDIR/state/<gateway> no SMS.
Transfer (CPTA)
O estágio de transferência ocorre entre o SMS e o Security Gateway. Uma vez que a política é compilada com sucesso e movida para o diretório $FWDIR/state/<gateway> na SMS, o Check Point Transfer Agent (CPTA) transfere a política compilada para o gateway usando o SIC. O uso do SIC vai garantir que a SMS é elegível para instalar a política no gateway. Também criptografa a conexão via SSL para que os dados da política transferida para o gateway seja confiável. Uma vez que o SIC é iniciado, a autenticação do SIC ocorrerá em cada instalação de política.
Commit
Durante o estágio do commit, o firewall é instruído a carregar a nova política que acabou de receber da gerência. Os seguintes passos ocorrem:
· O processo cpd no gateway vai executar o seguinte comando para carregar a política cuja qual acabou de ser transferida para o gateway:
 
fw fetchlocal -d $FWDIR/state/_tmp/FW1
· A política será carregada no kernel.
· Havendo sucesso a política será copiada no diretório $FWDIR/state/FW1 no gateway.
· Se o processo fetchlocal falhar, cpd vai gerar uma notificação da falha e irá informar o processo fwm que o carregamento da política falhou.
Fluxo de Instalação de Política
 Fluxo de Instalação de Política
1. A política é definida no SmartConsole.
2. A política publicada é salva no banco de dados postgres. Em um push, a verificação da permissão do usuário é executada.
3. O dump do banco de dados de postgres para formatos de arquivo antigos (object_5_0.C e outros) para cpmitable e um dump para cpmi não ocorrer.
4. Depois que a política é salva, os arquivos são criados em $FWDIR/conf /*. W e armazenados em rulesbases_5.0.fws.
5. fwm_gen compila o novo $FWDIR/conf /*.W e cria um novo arquivo chamado $FWDIR/conf/*.pf.
6. c_preprocessor compila os arquivos *.pf e lib/*. def e cria um novo arquivo chamado *.cpp.
7. Todos os novos arquivos gerados são armazenados em $FWDIR /state/ no servidor de gerenciamento. *.ccp é compilado, traduzido e transferido para o gateway.
8. O diretório $FWDIR/state/ é enviado ao módulo de aplicação (gateway).
9. O cpd e o kernel no gateway executam um carregamento automático.
Processo de Instalação de Política pelo Processo de Gerênciamento
Fluxo do Processo de instalação de Políticas
1) O comando de instalação da política cpmi é enviado para fwm no servidor de gerenciamento.
2) O fwm encaminha o comando para o cpd para a geração dos códigos e compilação.
3) O cpd invoca o comando cpta que envia a política para todos os GW pertinentes.
4) O cpd no GW recebe a política e verifica a integridade.
5) O cpd no GW realiza o update todos os processos User Mode responsável pelo aspecto do enforcement. Isso inclui emitir processos vpnd para VPN fwssd para o Security Server e assim por diante.
6) A nova política é preparada e o kernel para o tráfego e começa e começa a enfileirar todo tráfego de entrada.
7) O Atomic load inicia. Esse processo deve levar uma fração de segundo.
8) O enfileiramento é liberado e todos os pacotes passam a ser tratados pela nova política.
Rule Matching
O Security Gateway determina a regra a ser aplicada a uma conexão; portanto, é importante entender como as regras são combinadas. As colunas de uma regra contêm os elementos esperados de uma conexão e determinam o que acontece com a conexão.
Matching Baseado em Coluna
As versões do gateway de segurança anteriores a R80.10 inspecionam e combinam as conexões linha por linha (daesquerda para a direita), com base na ordem das regras na Base de regra. A Base de Regra é examinada de cima para baixo e a primeira regra correspondente é executada.
Os Security Gateway R80.10 e posterior correspondem às regras por coluna, de modo que apenas as regras na Base de regras que podem corresponder a uma conexão são consideradas. A correspondência baseada em coluna elimina o processo de examinar regras que não contêm os elementos aplicáveis da conexão.
O processo de correspondência
A política de controle de acesso rege as seguintes colunas para filtrar e combinar o tráfego que entra e sai da rede:
· Fonte
· Destino
· VPN (se habilitado)
· Serviços e aplicativos (se o App Control & URL Filtering Software Blades estiverem habilitados)
· Conteúdo (Content Awareness deve estar ativada)
· Time
· Installed On (gateway alvo)
A inspeção começa na primeira camada ordenada da política de Access Control (geralmente Política ou Rede). Se uma regra correspondente contiver uma inline layer, essa inline layer será processada. A correspondência continua com cada camada de política ordenada adicional após uma correspondência bem-sucedida. Qualquer drop interrompe o processo de correspondência e “dropa” a conexão.
O Security Gateway começa a examinar os campos da coluna de destino para identificar as regras que podem corresponder à conexão. Quando as correspondências possíveis são filtradas, a correspondência continua com a coluna Origem. A inspeção final nos resultados filtrados ocorre quando todas as colunas são correspondidas e a primeira regra (de cima para baixo) que corresponde é executada para a camada e as camadas subsequentes inline layers ou ordenadas são processadas.
A ilustração abaixo demonstra o processo de correspondência do tráfego conectando do A-Host para o B-Host usando FTP.
Correspondência Baseada em Colunas
Uma política de controle de acesso unificado pode conter critérios de aplicativo ou dados que não podem ser correspondidos na primeira conexão de pacote. A integração do aplicativo e dos critérios de dados requer uma inspeção profunda do pacote.
Para otimizar o processo de correspondência, o Firewall pode precisar ligar um ou mais mecanismos de inspeção e inspecionar o cabeçalho e o corpo da conexão antes de determinar a correspondência final. Caso contrário, a Base de Regras pode decidir bloquear a conexão em um estágio inicial. Um bloqueio inicial pode indicar que a conexão não continha critérios de dados aplicáveis suficientes para que o mecanismo fizesse uma deteção adequada ou que todas as regras potenciais correspondentes à conexão resultariam em uma ação Abandonar ou Rejeitar.
Níveis adicionais de inspeção incluem correspondência por porta e correspondência por assinaturas de protocolo
Correspondência (matching) de Regra por Porta
Por padrão, um objeto de serviço é correspondido por porta no primeiro pacote do protocolo de transporte. Ao fazer a correspondência por porta, a Blade de Firewall não considera o protocolo real executado na porta, embora nomes de serviço e números de porta em geral identifiquem serviços (como HTTP, HTTPS e FTP) que são executados em protocolos de transporte (como TCP e UDP) . Por exemplo, se o log do Firewall indica que o serviço HTTP foi correspondido na porta 80, isso significa que o primeiro pacote continha a porta 80 no protocolo de transporte.
Correspondência de Regra por Protocolo
Para R80.10 e gateways posteriores, uma inspeção mais avançada do protocolo para um serviço é possível se a assinatura do protocolo estiver habilitada para esse serviço. A correspondência de uma regra por assinatura de protocolo ou por serviço fornece um nível adicional de segurança quando a Rule Base contém regras, incluindo:
· um site de URL de aplicativo ou um serviço com uma assinatura de protocolo na secção Serviços e Aplicativos
· um tipo de dado na coluna Conteúdo
NOTA:
O recurso de correspondência por assinatura de protocolo é desabilitado por padrão para gateways R80 e superiores. O firewall não pode combinar serviços por assinatura de protocolo para gateways R77.30 e anteriores.
Correspondência na Política de Threat Prevention
As políticas de Threat Prevention R80.10 e superiores podem conter várias camadas ordenadas nas quais o Security Gateways instala como uma Rule base. A Rule Base unificada determina como todas as conexões são inspecionadas. Quando uma conexão corresponde às regras em mais de uma camada, o gateway impõe a ação e as configurações mais rígidas.
Ação tomada: Prevent
Quando a Threat Emulation e a Threat Extraction são executadas no modo Mail Transfer Agent (MTA), a ação da primeira regra correspondida é aplicada. A Threat Emulation é executada em conjunto com a Threat Extraction para Gateways R80.10 e superiores. Para ativar o blade de software de Threat Extraction, o gateway deve ser estabelecido como um MTA.
Nework Address Translation
Network address Translation (NAT) e Network Address Port Translation (NAPT) são as duas principais tecnologias tradicionalmente utilizadas para para ocultar o endereço real de redes para não serem reveladas ou requeridas para serem roteadas publicamente. Isso reduz a necessidade de mais IPs público roteáveis, e permite acesso a recursos internos a parir de redes externas.
Funcionamento do NAT
O NAT é considerado uma infraestrutura de serviços usada, por exemplo, para criar soluções de cluster, servidores de segurança, conexão em modo escritório, etc.
NAT
Quando o NAT é definido em um objeto de rede, regras de NAT são automaticamente adicionadas a base de regras de NAT. O NAT é traduzido em tabelas durante a instalação de políticas e é efetuada no primeiro pacote da conexão. A base de regras de NAT é muito eficiente e pode dar match em duas regras de NAT na mesma conexão. Isto é chamado de NAT bidirecional e se aplica apenas para as regras de NAT automáticas.
NOTE: Mesmo que o NAT mescle duas regras de NAT automáticas em uma, esta feature pode ser desativada e a regra de NAT pode ser manualmente definida para opções adicionais.
As regras de NAT são priorizadas conforme a lista que segue:
1. Manual/Pre-automatic NAT
2. Automatic Static NAT
3. Automatic Hide NAT
4. Post-automatic/Manual NAT Rules
Processo de HIDE NAT
Considere inicialmente o o primeiro pacote original. Quando o pacote chega na interface Inbound, é inspecionado pela Security policy. Se aceito, o pacote é adicionado na tabela de conexões. O primeiro pacote da conexão é comparado com as regras de NAT. O pacote é traduzido se é encontrado um NAT nas regras de NAT. Então o pacote chega em um stack TCP/IP no módulo de Firewall e é roteado para interface outbound.
 Hide NAT
Durante a NAT rule base transversal, ambas source e destination são decididos. De fato são executados nas seguintes localizações:
· src nat no lado do servidor
· dst nat dependendo da propriedade relevante da GUI
O pacote de resposta chega na interface Inbound do Firewall. O pacote passa pela Security policy uma vez que se encontra na tabela de Conexões. O destino do pacote, cuja a origem do pacote original, é traduzido conforme a informação de NAT. Isto ocorre quando o pacote é traduzido in conexão inicial. O pacote chega no stack TCP/IP do Firewall e é roteado para interface Outbound. O pacote passa pela interface Outbound e pela origem, o destino do pacote original é traduzido conforme a informação nas tabelas de NAT. O pacote então deixa o Firewall.
NAT Manual 
Ocasiões em que o NAT manual deve ser utilizado:
· As regras existentes são restritas a um IPs de destino e/ou origem específico(s).
· Ambos endereços de IP de origem e destino são traduzidos no mesmo pacote.
· NAT estático ocorre somente em um sentido.
· Existem regras que usam somente serviços específicos (portas).
· Tradução de endereços de IP para objetos dinâmicos.
A Base de Regras de NAT é processada uma regra de cada vez de cima para baixo, similarmente a Rule Base e Firewall. As regras de NAT manual são adicionadas na NAT Rule Base tanto acima quanto abaixodas regras de NAT automático já existentes.
Exemplo de Manual NAT
A Base de Regras de NAT consiste em duas sessões de títulos principais: uma para o Pacote Original antes do NAT ser aplicado pelo Firewall e outra para o Pacote traduzido depois de aplicado o NAT pelo Firewall. A ordem de processamento, no geral a inspeção e roteamento dos pacotes pelo Security Gateway ocorre como segue:
1. Firewall - Inspeção do pacote original.
2. NAT - Tradução do IP e/ou numero da porta assim como requerido.
3. Routing - Encaminha o pacote resultante.
Quando configurando NAT Manual em Global properties, marque a checkbox Translate destination on client side na sessão Manual NAT.
Global Properties para NAT Rules
Proxy ARP para NAT Manual
Para regras de NAT Manual é necessário configurar proxy ARP para associar o IP traduzido. O proxy ARP permite o Security gateway a responder consultas de ARP para endereços de rede que estão localizados na mesma rede. O ARP proxy está ciente da localização do destino do tráfego, oferecendo o endereço MAC apropriado da rede de destino. Quando os dados recebidos de uma rede externa, o GW encaminha os dados para o host relevante na rede interna.
A configuração do Proxy ARP é necessária nas situações em que uma regra de NAT estático manual que foi criada no GW não responde as requisições ARP para o endereço de IP estaticamente “NATeado” por uma regra de NAT Manual. Outra situação seria quando um GW responde as requisições de ARP com o MAC address incorreto, em sua maioria para o tráfego NAT.
Em situações onde as conexões recebidas são requisitadas por um host interno específico, onde IP público são necessários para ser utilizado com Regra de NAT Manual, pode-se adicionar um endereço de IP Secundário (aliases). Os endereços de IP são adicionados na interface externa do Sistema Operacional Gaia através do Gaia Web portal ou através do Clish usando o comando:
add interface eth0 alias <endereço_IP>/<net/mask>
O comando irá criar automaticamente o proxy ARP no Sistema Operacional Gaia, que será necessário para aceitas as conexões para os IPs públicos utilizados como objetos na configuração da Base de Regras de NAT.
Para configurar o proxy ARP:
1. Associe os IPs com os hosts da rede interna relevantes ao MAC address da interface de rede externa do Security Gateway. É salvo no arquivo $FWDIR/conf/local.arp.
2. Crie as regras de NAT Manual relevantes.
3. Instale a Security policy.
Administração do Firewall
Considere a seguir como os arquivos de configuração são divididos para facilitar eventuais troubleshooting. As principais sub-divisões dos arquivos de configuração estão divididos em diretórios localizados /opt.
· CPsuite-R80 - Gerencia dos Módulos de Firewall (R75.20 - R80). É o diretório de instalação em geral.
· CPshrd-R80 - Armazenado que é usado quando o SVN foundation, incluindo o database do cpd, licenças, registro e generic low level CheckPoint infrastructure (não relacionados a versão).
· CPEdgecmp-R80 - Gerencia dispositivos Edge,
Os diretórios /lib e /conf armazenam arquivos de definição que são importantes. 
· Os arquivos $FWDIR/lib*.def incluem a Rule Base e as definições de protocolos.
· O arquivo $FWDIR/conf/fwauth.NDB armazena as definições de usuários.
· Os arquivos de configuração estão em $FWDIR/conf/fwauthhd.conf.
· $FWDIR/conf/classes.C define os campos para cada objeto do arquivo objects_5_0.C, tal como, cor, num/string, e valor default.
Maneiras de Editar a Database:
· dbedit - utilidade de linha de comando do próprio Management Server.
· GuiDBedit.exe - Ferramenta executável em máquinas Windows-based.
Localizado em:
C:\Program Files(x86)\Checkpoint\SmartConsole\R80\Program.
FW MONITOR
A ferramenta fw monitor, é um analisador de pacotes presente em todos os Security gateways CheckPoint e é essencial para captura de pacotes e analise de tráfego. Provê uma inspeção a nível de kernel. O fw monitor funciona na layer 3 e acima do modelo OSI. O arquivo resultante é no formato .cap usado nas ferramentas de análise de pacotes, tanto no Ethereal e Wireshark.
fw monitor
A forma mais simples de utilizar é rodar o comando fw monitor sem nenhum parâmetro. Entretanto em ambientes com grande volume de tráfego não usar parâmetros ocasionará um output com detalhes em demasia o que pode acabar atrapalhando sua análise. Os filtros são utilizados para especificar os pacotes a serem capturados e também o tamanho do output.
fw monitor -e “accept <expression>;” -o <filename>
Expressões do filtro incluí:
· Host [<IP_Address>]
· Net [<Network_IP_Address, <Mask_Length>]
· Port [<IANA_Port_Number>]
NOTA:
É recomendado desabilitar o SecureXL (fwaccel off) quando utilizando o fw monitor para evitar um tráfego de forma equivocada. Se o SecureXL estiver habilitado a ferramenta irá somente exibir os pacotes não acelerados.
Exemplo de uso:
Capturar tudo entre o host X e o host Y:
Conexões C2S e Pacotes S2C
fw monitor captura os pacotes assim que eles entram e deixam o Kernel de Firewall e quando o pacote entra e deixa no Inbound e Outbound chains. No caso de comunicação Client to Server (C2S), um cliente designado como Host_1, conforme a política, envia tráfego com destino a um Servidor Web localizado atrás do Firewall. Uma vez que o tráfego tem a passagem permitida pelo Firewall baseado na policy Rule Base, o pacote deve atravessar e ser inspecionado em ambas as chains do Firewal (inbound e outbound).
O comando fw monitor funciona carregando um filtro especial aplicado a pacotes suspeitos. Este filtro é diferente do filtro INSPECT utilizado e implementado pela Rule Base. Onde a Rule Base determina qual pacote é aceito, rejeitado ou derrubado (dropped), o filtro INSPECT gerado pelo fw monitor simplesmente captura o fluxo do pacote pelo kernel. Você pode capturar tudo no kernel utilizando o fw monitor, mesmo um tipo particular de fonte de tráfego.
Uma vez que o fw monitor é executado, o filtro INSPECT especificado é compilado e carregado no kernel. Quaisquer parâmetros após accept no comando fw monitor serão exibidos pelo fw monitor. O mesmo filtro é executado em todas as interfaces em todas as direções. A saída do comando utiliza expressões específicas para explicar a localização do pacote enquanto ele se move através do Firewall.
Conexões C2S e S2C 
Os pontos de inspeção são:
· i - Antes da máquina virtual, na direção inbound (pre-Inbound)
· I - Depois da máquina virtual, na direção Inbound (pós-Inbound)
· o - Antes da máquina virtual, na direção Outbound (pre-Outbound)
· O - Depois da máquina virtual, na direção Outbound (pós-Outbound)
No cenário anteriormente exposto o i representa o pacote que partiu do lado do cliente. O I representa o pacote após ser checado com as tabelas da Rule Base. No caso haver NAT estático, o IP de destino será modificado. O o indica o pacote antes do kernel de Outbound e o O indica o pacote após o chain de Outbound do kernel, já no lado do servidor. No caso do uso de Hide NAT, o IP de origem será diferente neste ponto.
Para pacotes indo do Servidor para o cliente (S2C), a inspeção é inversa. Onde I pode ser o pacote NATeado saindo do Inbound chain do firewall no caso do uso de NAT estático. Neste ponto o pacote já foi checado pelas tabelas da Rule Base. O O é o pacote como aparece no lado do cliente.
Automação e Orquestração
Interfaces de Programação de Aplicação (APIs) habilita o uso de sistemas de orquestração para de maneira segura integrar solução de gerenciamento seguro que tenha capacidade de automação no workflow processes. O API da CheckPoint facilita a integração segura com orquestração, altera os sistemas de gerenciamento e ticketing. Possuindo a habilidade de controlar exatamente o que a integração pode ou não pode fazer, organizações tem a confiança de embutir segurança no seu ambiente de TI.
Automação é um processo de automatizar tarefas normalmente realizada através de intervenção humana para ser realizada por uma máquina, ou seja, provendo eficiência e minimizando o fator de erro humano. Orquestração é acoreografia de automatizar os processos de arranjo, coordenação e gerenciamento realizados em um sistema de computador complexo e serviços em um fluxo de trabalho lógico. Ele reduz o tempo e o esforço para implantar várias instâncias de uma única tarefa, executando automaticamente uma série de tarefas que anteriormente só podiam ser realizadas por vários administradores.
Como Orquestração e Automação Diferem
A automação e a orquestração diferem porque a automação está relacionada à codificação de tarefas, enquanto a orquestração está relacionada à codificação de processos. A automação se preocupa com a execução de uma única tarefa, como lançar um servidor da web ou interromper um serviço, de maneira consistente e repetível. A orquestração leva uma série de tarefas automatizadas desenvolvidas por meio da automação e as reúne em um fluxo de trabalho de processo que pode simplificar o gerenciamento complexo das atuais infraestruturas de segurança de rede. A orquestração também envolve o processo de coordenação de uma troca de informações por meio de interações de serviços da web, como XML e JSON.
Check Point APIs
A plataforma de gerenciamento de segurança Check Point R80.10 fornece a estrutura para oferecer suporte a automação e orquestração por meio de sua arquitetura API flexível. Uma API é um conjunto de rotinas, protocolos e ferramentas para construir aplicativos de software. A Check Point fornece uma interface CLI e API completa para gerenciamento de segurança que permitirá a automação das operações diárias e integração total com sistemas de terceiros e outros, como sistemas de gerenciamento de rede, sistemas de ticketing, servidores de virtualização e orquestradores em nuvem.
As operações de automação e gerenciamento Smart Console são permitidas com base no mesmo perfil de privilégio.
As APIs de checkpoint permitem que engenheiros e desenvolvedores de suporte façam alterações no perfil de segurança de suas organizações com ferramentas CLI e Web Services. Uma API pode ser usada para:
· Executar um script automatizado para realizar tarefas comuns.
· Integrar produtos Check Point com soluções de terceiros.
· Criar produtos que usam e aprimorar a solução Check point.
Existem diferentes APIs para vários produtos Checkpoint:
· API de Gerenciamento - usado para ler informações, criar objetos, trabalhar em políticas de segurança e enviar comandos para o servidor de gerenciamento Checkpoint Security. A API Management possui uma opção de web services JSON/XML, um Gaia CLI do R80.10 SmartConsole, a nova ferramenta mgmt_cli e o Gaia Clish.
· Threat Prevention API - Serviço baseado em nuvem usado para controlar emulação de ameaças, Antivírus e Threat Extraction
· Identity Awareness Web Services API - Uma API de serviço da web usada para adicionar, remover e mostrar os estados dos parâmetros de identidade. Por exemplo, usando a API, um novo usuário pode ser adicionado a um Access Role ou um usuário pode ter permissão para se conectar à rede interna de um endereço IP diferente.
· OPSEC SDK - Essas APIs são usadas para abrir e monitorar conexões entre o Security Management Server e os Gateways, e outros hosts e objetos.
NOTA: 
OPSEC SDK contém APIs para comandos que originalmente são usados com o SecurePlatform. Estes comandos são também utilizados no Sistema Operacional Gaia.
Arquitetura de API da Check Point
A arquitetura da API Check Point consiste no servidor de API e nos mecanismos de interação da API. O servidor API se comunica com o CPM da mesma forma que o SmartConsole. Uma sessão automatizada de API gerará logs de auditoria e exibirá os erros e avisos de validação. A arquitetura API também oferece suporte à administração simultânea. Os mesmos perfis de permissões que controlam a GUI são aplicados ao usar a sessão de automação.
O servidor API usa notificação de objeto JavaScript (JSON) para intercâmbio de dados. JSON é um formato de intercâmbio de dados leve que é fácil para indivíduos ler e escrever e para máquinas analisar e gerar. Mecanismos de interação são fontes de comando, tais como Web Services e Management CLIs. Todos os clientes API usam a mesma porta do Portal Gaia.
Arquitetura API
Fontes de Comando
Fontes de Comandos permitem que você comunique com o servidor de API e efetuar muitas tarefas utilizando o gerenciamento de APIs.
· SmartConsole GUI console - A partir do SmartConsole, podemos clicar no botão para abrir uma janela de CLI e executar comandos de API. 
· A Ferramenta mgmt_cli - É executada no modo Expert e permite a utilização de comandos a partir de um computador Linux ou Windows. Mgmt_cli utiliza a mesma autenticação (username e password) que o cliente GUI; entretanto, não requer a instalação do GUI.
· Gaia CLI - Permite o log in de uma conta de administrador no Security Management Server (SMS) e executar comandos de API usando o Clish.
· Web Services - Envia requisições HTTPS para o Security Management Server (SMS).
RESTful API
As APIs RESTful permitem que o sistema use serviços da web para acessar, manipular, excluir, alterar e adicionar recursos. Eles usam métodos HTTP padrão enviados pelo script para dados GET, PUT, POST e DELETE. A API de gerenciamento usa a API RESTful para enviar chamadas usando o método POST.
Um exemplo de uso de uma API RESTful para chamar o login seria:
http POST https://<mgmg>/web_api/login
Content-type: appication/json
O tipo de conteúdo Header informa ao cliente como redigir a solicitação no corpo para o servidor.
Fluxo Operacional
Fluxo operacional do API
Configuração do API Server 
O servidor API de gerenciamento faz parte da instalação do servidor de gerenciamento R80.10. Para gerenciar a segurança através de API e CLI, você deve primeiro configurar o servidor API.
O servidor API executa scripts que automatizam tarefas diárias no Security Management Server (SMS). Também integra produtos Check Point e sistemas de terceiros. Para configurar o servidor API, no SmartConsole, vá para Manage & Settings> Blade. Na secção de gerenciamento de API, clique em Advanced Settings e a janela Configurações da API de gerenciamento será aberta. Defina as configurações de Start up e as configurações de acesso.
As configurações de inicialização iniciam o servidor API quando o Security Management Server é iniciado. A configuração de início automático é selecionada por padrão nos seguintes ambientes:
· Servidores de gerenciamento de segurança (sem funcionalidade de gateway) com pelo menos 4 GB de RAM.
· Servidores de gerenciamento de segurança padrão (com funcionalidade de gateway) com pelo menos 8 GB de RAM.
NOTA: Verifique os requisitos de instalação antes de configurar o servidor API.
As configurações de acesso configuram o endereço IP do qual o servidor API aceita a solicitação. A opção "Management Server Only" é selecionada por padrão. Esta opção instrue o servidor API a aceitar scripts e solicitações da web apenas do Security Management Server. Para enviar uma solicitação de API, abra uma interface de linha comando no servidor e use o utilitário mgmt_cli.
Configurando Servidor de API
Para verificar que o servidor API está funcionando, executa-se no modo Expert o comando:
api status
Para iniciar o servidor API, executa-se no modo Expert o comando:
api start
Para parar o servidor API, executa-se no modo Expert o comando:
api stop
Comandos de Gerenciamento de API
Para utilizar comandos API a partir da SmartConsole GUI, clica-se no botão de interface de comando localizado no lado esquerdo no canto inferior.
Interface de Linha de Comando
Comandos básicos de API incluem:
· login
· add
· set
· show
· delete
· publish
· discard
· logout 
Na GUI, o script começa com uma caixa de diálogo de login para receber um token de sessão. Um comando de login cria uma sessão. os parâmetros de nome de usuário e senha são sempre obrigatórios. A seguir a sintaxe de um script de login:
login user <usename> password <password> --format json
A saída para o exemplo acima é o que segue:
{
“sid” : “97BVpRfN4j8logN-V2XqGYMW3DDwIhoSN0Og8PiKDiM”,“url”: “https://192.0.2.1:443/web_api”, 
“uid”: 7a13a350-9b24-40d7-acd3-5b5024be33e”,
“session-timeout” : 600,
“last-login-was-at” : {
“posix” : 1430032266851,
“iso-8601”: 2020-04-26T10:11+0300”
}
 }
NOTA: - -format json é opcional.
A solicitação de string sid representa o identificador exclusivo da sessão. Esse identificador é inserido no cabeçalho 'X-chkp-sid' de cada solicitação. O parâmetro url identifica a URL que foi usada para acessar o servidor API. A string uid é o identificador do objeto da sessão, ela pode ser usada no descarte da API para descartar as mudanças que foram feitas na sessão, quando o administrador está trabalhando em outra sessão.
Os comandos da API podem ser usados para criar scripts para os principais componentes de gerenciamento de segurança, incluindo:
· 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, CVPN Community Start.
Por exemplo, criar um novo host usando o comando:
add host name <nome_do_novo_host> ip-address <x.x.x.x.>
Ferramenta mgmt_cli
A ferramenta mgmt_cli utiliza a mesma sintaxe utilizada no GUI do SmartConsole. A única diferença é que quando utilizando a ferramenta, para executar um comando devemos prover as credenciais de login ou utilizar um token the session-id que foi anteriormente obtido utilizando o comando de login.
A ferramenta mgmt_cli transforma os argumentos recebidos em chamadas RESTful API.
A ferramenta mgmt_cli pode ser executada em qualquer máquina utilizando Sistema operacional Linux ou Windows. Uma versão da ferramenta de linha de comando Linux já está incluída por padrão na instalação do SmartConsole R80.10. O mgmt_cli.exe não requer instalação GUI. Pode ser copiado e executado em todos computadores baseados em Windows.
O Script API a seguir é um exemplo de uso do mgmt_cli para realizar login e criar um novo host:
mgmt_cli login user “AdminUser1”password “teabag” > id.txt
mgmt_cli add host name “New_host_1” ip-address “10.10.10.10” -s id.txt
mgmt_cli publish -s id.txt
mgmt_cli logout -s id.txt
No exemplo acima, a saída do comando de login é redirecionado para um arquivo chamado id.txt. Por utilizar o parâmetro -s, os demais comandos leem o arquivo id.txt e atomáticamente extraem a sessão deste arquivo.
Usuários logados no management server como Root, podem executar comandos mgmt_cli sem a necessidade de entrar suas credenciais. Estes são usuários com permissões de Super Administradores. Para dicionar esta opção, adicione --root true no final do comando mgmt_cli.
Todos comandos mgmt_cli podem utilizar arquivos CSV com pro[ósitos de automação. Veja no exemplo a seguir o comando sendo utilizado para criar vários hosts a partir de uma tabela Microsoft Excel:
# mgmt_cli add host --batch hosts.csv
Gaia CLI (CLI)
Para executar comandos API no shell do Gaia, deve-se primeiro realizar login como usuário administrativo. A Sintaxe é idêntica aos comandos executados via SmartConsole GUI; entretanto, todos comandos de gerenciamento iniciam com mgmt. Por exemplo:
# mgmt add host
Web Services
O uso de serviços da web para construir um aplicativo que se comunica com o CheckPoint management Server requer os seguintes componentes para as solicitações da web:
· Postagem HTTP to - identifica o servidor de gerenciamento e a porta. A porta padrão é 443.
· HTTP Headers - Consiste no tipo de conteúdo, como application/json e o header x-chkp-sid. O x-chkp-sid é o token de ID da sessão e é obrigatório em todas as chamadas API, exceto login.
· Request Payload - texto contendo os diferentes parâmetros no formato especificado (json ou xml)
Management API Suport
O CheckPoint Management API utiliza todo o potencial do Servidor de gerenciamento de segurança R80.xx e pode ser usado em qualquer ambiente de programação. Para ajudá-lo a construir ferramentas de automação para sua organização ferramentas para sua organização, a CheckPoint recomenda as seguintes ferramentas de referência.
Management API Reference Guide
Este guia online apresenta uma introdução à API da Checkoint. O guia pode ser acessado através da Central de usuários do CheckPoint e do servidor de gerenciamento (/api_docs).
Management API reference V1.0
CheckPoint CheckMates Community
Junte-se à comunidade CheckPoint Exchange Point para navegar pelos scripts mais recentes desenvolvidos por especialistas na área, obter exemplos de código, interagir com desenvolvedores e acessar documentação API adicional. https://community.checkpoint.com/
Redundância
Os Security gateways podem ser configurados para prover redundância e prevenir down-time. A falha de um Security Gateway ou conexão VPN pode resultar em perda de conexões ativas, muitas das quais podem ser de missão crítica e resultar em perda de dados críticos. Independentemente de você preferir o protocolo de redundância de rede Checkpoint ClusterXL ou Virtual Routing Redundancy Protocol (VRRP), não é mais uma escolha de plataforma que você terá que fazer com o Gaia. Ambos ClusterXL e VRRP são totalmente suportados pelo Gaia. 
Advanced ClusterXL
O ClusterXL fornece uma infraestrutura que garante que nenhum dado seja perdido em caso de falha do sistema. Esta solução de cluster CheckPoint usa endereços IP e MAC físicos exclusivos para seus membros de cluster e endereço IP virtual para representar o próprio cluster. Os endereços IP virtuais não pertencem a uma interface de máquina real e é recomendado que cada membro do cluster tenha pelo menos três interfaces: uma interface externa, uma interface interna e uma para sincronização.
O ClusterXL faz parte da instalação padrão do Security Gateway e pode ser configurado para compartilhamento de carga ou modo de alta disponibilidade.
Vantages do uso do ClusterXL
Ambos ClusterXL e VRRP são totalmente suportados pelo Gaia e estão disponíveis para todos os dispositivos Checkpoint, open servers e ambientes virtualizados. Embora ambas as plataformas forneçam a capacidade de monitorar o estado de seus clusters, o ClusterXL fornece recursos operacionais e de monitoramento mais detalhados. Por exemplo, ao usar o ClusterXL, os Administradores do sistema sabem quando o cluster sofreu failover e também podem ver por que ele fez o failover usando o comando cphaprob -l list. Além disso, se uma interface ficar inativa, os Administradores do Sistema podem determinar se ela está totalmente inativa usando o comando cphaprob -a if. Pode ver qual firewall está ativo no momento, ou no caso de Load Sharing, qual gateway está carregando a carga e a porcentagem da carga transportada usando o comando cphaprob stat. As vantagens de usar o ClusterXL incluem:
· Forte integração com CheckPoint Management e pontos de aplicação.
· Failover transparente. 
· Desempenho superior
· Fácil implementação
· Custo-benefício
Load Sharing
O ClusterXL Load Sharing distribui o tráfego dentro de um cluster para que a taxa de transferência total de vários membros seja aumentada. Em Load Sharing Clusters, todos os membros em funcionamento estão ativos e tratam do tráfego de rede. Isso é conhecido como configuração Ativa/Ativa. Os Load Sharing Clusters aumentam o desempenho linear para aplicações com uso intensivo de CPU, como VPNs, servidores de segurança, servidores de políticas e diretório de usuários (LDAP).
Com o Load Sharing, se qualquer membro de um cluster se tornar inacessível, ocorre um failover transparente para os membros operacionais restantes no cluster, fornecendo assim alta disponibilidade. Todas as conexões são compartilhadas entre os Security Gateways restantes, sem interrupção.
As configurações de ClusterXL Load Sharing requerem que todas as máquinas sejam sincronizadas, o que difere de High Availability. As máquinas em uma configuração de alta disponibilidade do ClusterXL não precisam ser sincronizadas, caso contrário, as conexões serão perdidas em um failover.
ClusterXL oferece duas soluçõesde compartilhamento de carga diferentes. Multicast e Unicast. Esses modos diferem na maneira como os membros recebem os pacotes enviados ao cluster.
Multicast Load Sharing
No modo ClusterXL Multicast Load Sharing, cada membro do cluster recebe todos os pacotes enviados para o endereço IP do cluster. O mecanismo Multicast permite que várias interfaces sejam associadas a um único endereço MAC Multicast. Portanto, quando um roteador ou switch da Camada 3 encaminha pacotes para todos os membros do cluster usando o modo Multicast, um algoritmo de decisão ClusterXL nos membros do cluster decide qual membro do cluster deve executar o processamento de imposição no pacote. Somente essa máquina processa o pacote e o envia ao seu destino. As outras máquinas descartam o pacote. Este processo de decisão é o âmago do mecanismo de Load Sharing Multicast. Ele deve garantir que pelo menos um membro processe cada pacote de forma que o tráfego não seja bloqueado e nenhum outro membro manipule os mesmos pacotes, de forma que o tráfego não seja duplicado. Somente switches da camada 3 ou roteadores que aceitam endereços MAC multicast como resposta a uma solicitação ARP com endereço IP Unicast são suportados para compartilhamento de carga multicast.
Unicast Load Sharing
No Modo ClusterXL Load Sharing, uma máquina, chamada de máquina Pivot, recebe todo o tráfego de um roteador com uma configuração Unicast e redistribui os pacotes para as outras máquinas do cluster. Uma máquina Pivot é escolhida automaticamente pelo ClusterXL.
O Pivot é a única máquina que se comunica com o roteador. Nesse esquema, o roteador usa apenas o endereço MAC Unicast do Pivot para se comunicar com o cluster. O Pivot funciona como um roteador de cluster, tanto da rede interna para o exterior e vice-versa. Essa funcionalidade também se aplica a redes DMZ.
Depois que o Pivot recebe o primeiro pacote do roteador ou switch, a função Load Sharing do Pivot decide qual membro do cluster deve lidar com o pacote. Essa função de decisão é feita de maneira semelhante à decisão de Load Sharing Multicast. O Pivot também pode decidir tratar o pacote sozinho. Nesse caso, o Pivot Load Sharing entregará o pacote ao componente do Firewall do Pivot para processamento. Se o Pivot encontrar um problema, ocorre um evento de failover regular e outro membro do cluster assume o papel como novo Pivot. O membro do Pivot é sempre o membro ativo com a prioridade mais alta. Portanto, quando o pivô original se recuperar, ele retomará sua função anterior.
Como o Pivot está ocupado distribuindo o tráfego, ele participa em menor grau da função real de Load Sharing. Os outros membros do cluster assumem mais carga de tráfego. Como o recurso CheckPoint Pivot Mode é baseado apenas em endereços Unicast, ele pode funcionar com todos os roteadores e switches da Camada 3. o diagrama e as etapas a seguir descrevem como um pacote viaja por um cluster de compartilhamento de carga Unicast.
Unicast Load Sharing ModePacket Path
Quando p roteador envia um pacote através do cluster, ocorre o seguinte:
1. O roteador envia um ARP request para o endereço de IP do Cluster.
2. O Pivot envia um ARP reply com o seu próprio endereço MAC Unicast, para o roteador.
3. O roteador envia o pacote para o Pivot. O Pivot decide qual membro do cluster deve tratar o pacote.
4. O Pivot encaminha o pacote ao membro designado do cluster sem alterar o pacote. O endereço de destino do pacote permanece inalterado e nem o NAT nem a decryption são efetuadas no pacote encaminhado. Quando enviando o pacote, o Pivot usa o endereço MAC virtual do membro do cluster designado. O pacote é encaminhado através da interface original.
5. O membro do cluster que recebe o pacote realiza a inspeção e envia o pacote ao seu destino.
6. O pacote retorna ao Pivot. O pacote de retorno passa pelo mesmo processo, embora não possa necessariamente ser encaminhado pelo Pivot para o mesmo membro do cluster.
7. O Pivot designa o membro do cluster para lidar com o pacote.
8. O membro do cluster receptor executa a inspeção e envia o pacote para seu destino.
Proxy ARP
O protocolo de resolução de endereço (ARP) é usado para converter as comunicações do sistema do protocolo IP da Camada 3 para a Camada 2. Para permitir que os membros do cluster se comuniquem entre si, um ARP estático deve ser configurado para cada membro do cluster, iniciando o endereço MAC de todos os outros membros em o cluster. Os pacotes IP enviados entre os membros não são alterados e nenhuma mudança é feita na tabela de roteamento. A sincronização do Cluster não depende do ARP.
Proxy ARP é útil para ambientes que possuem firewalls NAT. É um recurso de Firewall que permite que um roteador ou switch responda a uma solicitação ARP com seu próprio endereço MAC. Ele é usado principalmente para redes que não possuem Security Gateway padrão. O proxy ARP reconhece o destino do tráfego de rede e fornece seu endereço MAC como destino. O tráfego é então roteado para o destino interno usando outra interface ou através de túnel.
Ao usar o NAT estático, um cluster pode ser configurado para reconhecer automaticamente os hosts ocultos atrás dele e emitir respostas ARP com o endereço MAC do cluster, em seu nome. Esse processo é conhecido como Porxy ARP automático. Se estiver usando o modo ClusterXL VMAC ou sub-redes diferentes para o IP do cluster, o Proxy ARP deve ser configurado manualmente.
Para configurar o ARP do proxy:
1. Configure a camada de enlace de dados que corresponde à camada de rede em cada membro do cluster, combine os endereços IP de hosts relevantes na rede onde estão localizados com o endereço MAC do Gateway de segurança na rede onde os endereços IP desses hosts devem ser publicados.
2. Crie regras de NAT manuais relevantes e instale a política.
A correspondência do Security Gateway/membro do cluster é salva no arquivo:
$FWDIR/conf/local.arp
Cada entrada no arquivo contém o endereço do host a ser publicado, o endereço MAC que precisa ser associado ao endereço IP e o IP exclusivo da interface que responde à solicitação ARP. O Proxy ARP pode gerar ataques de negação de serviço (DoS) em uma rede se configurada incorretamente.
Quando as regras de NAT manual são configuradas conforme descrito acima, outra abordagem para obter o proxy ARP correto será configurar aliases (endereços IP secundários), que são adicionados à interface externa relevante para o endereço IP público que será usado para as regras de NAT manual. Quando isso é feito, o sistema operacional Gaia realiza os proxy ARPs automaticamente para esses endereços de IP públicos, sem a necessidade de configurá-los estaticamente no arquivo local.arp.
VMAC
Cluster Virtual MAC (VMAC) é um endereço VMAC atribuído a um roteador virtual. É uma variação do modo Unicast de High Availability (HA) e de Load Sharing. Após o failover no modo High Availability/LoadSharing Unicast, um novo membro Active/Pivot enviará solicitações Gratuitous-ARP (G-ARPs) para o IP virtual com o endereço MAC físico do Active/Pivot. Quando isso ocorre, um membro com um grande número de entradas de NAT estático pode transmitir muitos G-ARPs e os componentes de rede podem começar a ignorá-los ou evitar atualizá-los com rapidez suficiente em sua tabela de cache ARP. Como resultado, podem ocorrer interrupções no tráfego. Configurar o cluster para usar o modo VMAC permite que todos os membros do cluster usem o mesmo endereço VIRTUAL MAC e minimiza possíveis interrupções de tráfego durante um failover. Além disso, G-ARPs para endereços de IO da NAT não são mais necessários.
O VMAC que é anunciado pelos membros do cluster por meio de solicitações G-ARP, mantém o endereço MAC real de cada membro e adiciona outro endereço VMAC a ele. Manter o endereço MAC real de cada membro é necessário para que a conectividade com o endereço IP do próprio membro seja requerido, o tempo de failover do VMAC é menor do que um failover que envolve um endereço MAC físico.
Configurando VMAC
VMAC pode ser configurado via SmartConsole ou CLI. Para configurar oVMAC via SmartConsole, selecione o objeto cluster e navegue até a janela Gateway Cluster Properties. Selecione a opção de menu ClusterXL e VRRP e, a seguir, habilite a opção usar MAC virtual localizada na secção Configurações avançadas.
Para Configurar o VMAC usando a linha de comando, deve-se inicialmente definir o valor do parâmetro global de kernel, fwha_vmac_global_param_enabled para 1(o valor default é 0. O valor default significa que o VMAC está desabilitado).
Para certificar-se que o modo VMAC está habilitado, deve-se utilizar o comando que segue em todos os membros:
fw ctl get int fwha_vmac_global_param_enabled
Se a saída do comando for 1, o VMAC está habilitado. Se não estiver habilitado deve-se utilizar o comando:
fw ctl set int fwha_vmac_global_param_enabled
Para visualizar o VMAC em cada interface virtual do cluster, utiliza-se o comando:
 cphaprob -a if
Sincronização do Cluster
Para ter certeza de que cada membro do cluster do Gateway está ciente das conexões que passam pelos outros membros, existe um mecanismo chamado State Synchronization, que permite que as informações de status sobre as conexões no Security Gateway sejam compartilhadas entre os membros.
A State Synchronization permite que todas as máquinas no cluster estejam cientes da conexão que passa por cada uma das outras máquinas. Isso garante que, se houver uma falha em um membro do cluster, as conexões que foram tratadas pela máquina com falha serão mantidas pelas outras máquinas. Como a rede de sincronização carrega as informações de política de segurança mais confidenciais da organização, é fundamental que os engenheiros do sistema a protejam contra ameaças mal-intencionadas e não intencionais. A CheckPoint recomenda usar uma das seguintes estratégias para proteger as interfaces de sincronização:
· Use uma rede de sincronização dedicada.
· Conecte a interface de rede física dos membros do cluster diretamente usando um cabo cruzado. Em um cluster com três ou mais membros, use um hub ou switch dedicado.
Todos os serviços baseados em IP, inclusive TCP e UDP, reconhecidos pelo Security Gateway são sincronizados. A State Synchronization é usada tanto pelo ClusterXL quanto por produtos de cluster com certificação OPSEC de terceiros. A State Synchronization funciona nos dois modos a seguir:
· Full Synchronization - transfere todas as informações da tabela do Firewall de um membro do cluster para outro. A Full Synchronization é usada para transferências iniciais de informações de estado para milhares de conexões. Se um membro do cluster for ativado após a falha, ele executará a sincronização completa. Depois que todos os membros são sincronizados, apenas as atualizações são transferidas por meio da Delta Synchronization (Delta Sync). A Full Synchronizationl entre os membros do cluster é tratada pelo kernel do Firewall usando a porta TCP 256.
· Delta Synchronization - transfere alterações nas tabelas do kernel entre os membros do cluster, Delta Sync é muito mais rápido do que a sincronização completa. Ele é controlado pelo kernel do Firewall, usando UDP Multicast ou Broadcast na porta 8116.
Executar cphastart em um membro de cluster ativa o ClusterXL no membro é a maneira recomendada de iniciar um membro de cluster. Ele não inicia a sincronização completa. cphamcset desativa o processo de cluster. A sincronização de estado também para. Ainda é possível abrir conexões diretamente para o membro do cluster. Esses comandos devem ser executados apenas pelo Security Gateway, não diretamente pelo usuário.
Para monitorar o mecanismo de sincronização em produtos de clustering ClusterXL ou terceiros OPSEC Certified, execute o seguinte comando:
fw ctl pstat
Restrição de cluster sincronizado
As seguintes restrições se aplicam à sincronização de membros do cluster:
· Apenas membros de cluster executando a mesma plataforma podem ser sincronizados.
· Os membros do cluster devem ter a mesma versão de software.
· As conexões autenticadas pelo usuário por meio de um membro de cluster serão perdidas se o membro de cluster falhar. Isso ocorre porque o estado de autenticação do usuário é mantido por um processo no Security Gateway e não pode ser sincronizado nos membros da mesma forma que os dados do kernel são sincronizados. Todos os outros membros do cluster sincronizados não conseguirão retomar a conexão. No entanto, as conexões autenticadas pelo cliente ou por sessão serão mantidas, porque os estados dessas autenticações são salvos nas tabelas do kernel e podem ser sincronizados.
· O estado das conexões que usam recursos do sistema não pode ser sincronizado pelo mesmo motivo que as conexões autenticadas pelo usuário não podem ser sincronizadas.
· As informações de contas são acumuladas em cada membro do cluster e enviadas para o Security Management Server (SMS), onde as informações são agregadas. Em caso de failover, as informações de contas que foram acumuladas no membro com falha, mas ainda não foram reportadas ao Security Management Server, serão perdidas. Para minimizar o risco, reduza o período de envio das informações contas. No objeto do cluster navegue até a janela Logs > Additional Logging e edite o número de segundos para atualizar o Account Log.
Sincronizar ou Não Sincronizar
Em geral, todas as conexões em um cluster são sincronizadas entre os membros. Há poucas exceções. Os engenheiros de sistema podem optar por não sincronizar certos tipos de conexões por vários motivos, como:
· Uma carga significativa na rede é causada pelo uso de um serviço específico.
· Um serviço pode abrir muitas conexões curtas, cuja perda pode não ser muito importante, ou mesmo notada. Por exemplo, DNS sobre UDP ou HTP.
· A aderência bidirecional é empregada para todas as conexões. Por exemplo, qualquer cluster no modo High Availability (HA) ou ClusterXL em modo Load Sharing sem VPN ou NAT estático.
Para todos os serviços TCP cujo tipo de protocolo é HTTP ou Nenhum, você pode configurar o Security Gateway para atrasar uma conexão de forma que só seja sincronizada se ainda existir após a conexão ser iniciada por x segundos. Esse recurso estará disponível apenas se um dispositivo habilitado para SecureXL estiver instalado no gateway.
Cluster Connectivity Upgrade
Existem vários métodos disponíveis para atualizar as implantações do ClusterXL. O método mais simples é atualizar cada Membro do Cluster como um gateway independente, mas isso causará o tempo de inatividade do sistema. Outros métodos envolvem pelo menos um membro ativo ou dois membros do cluster tratando do tráfego durante a atualização. Com esses métodos, as conexões iniciadas durante ou após o processo de atualização podem ser interrompidas.
O método Connectivity Upgrade (CU) sincroniza conexões existentes para manter a conectividade e eliminar o tempo de inatividade durante as atualizações do cluster. Em um Connectivity Upgrade (CU), sempre há pelo menos um membro de cluster ativo que lida com o tráfego e o failover de conexão é garantido. As conexões são até sincronizadas entre os membros do cluster que estejam executando diferentes versões do CheckPoint Software. Usando CU, os membros do cluster podem ser atualizados para versões R77.20 e superior. Para obter informações detalhadas sobre CU, consulte CheckPoint Connectivity Upgrade Administration Guide.
NOTA:
O Cluster CU oferece suporte à sincronização de roteamento dinâmico ao atualizar para R80.10.
Antes de fazer upgrade com CU, é importante certificar-se de que o cluster tenha 2 ou mais membros, com um membro ativo e todos os outros membros em modo Standby. O estado de um cluster pode ser verificado executando o comando cphaprob stat. Quando a atualização for concluída, uma mensagem exibirá o status da atualização como READY para failover. Neste ponto, o CCP funcionará em modo de transmissão. Para retorná-lo ao modo multicast em todos os membros do cluster, execute o comando cphaconf set_ccp multicast.
Se mensagens de erro forem exibidas no script de atualização de conectividade, interrompa a atualização e entre emcontato com o Suporte CheckPoint.
Existem vários recursos que não sobrevivem após o failover para um membro de cluster atualizado ao usar CU. Esses recursos incluem, mas não estão limitados ao seguinte:
· Limitações gerais de failover, como servidores de segurança e conexões tratadas por serviços marcados como não sincronizados.
· Conexões iniciadas por membros individuais do cluster.
· Conexões TCP que são transmitidas por TCP.
· Conexões VPN para acesso móvel, acesso remoto e modo VPN tradicional.
· Conexões de controle de FTP com NAT.
· Sessões autenticadas com Identity Awareness.
· Conexões DLP
Além disso, as informações do Software Blade não são sincronizadas durante o failover para um membro de cluster atualizado. Se a Blade estiver configurado para manter a conectividade em vez da segurança, a conexão será aceita sem inspeção e encaminhada ao membro de destino. No entanto, se o membro de destino não estiver disponível, a conexão será interrompida.
Adicionar um Membro a um Cluster Existente
ClusterXL suporta até oito membros em um cluster. Para adicionar um membro a um cluster existente:
1. Execute o comando cpconfig para habilitar o ClusterXL no membro do cluster.
2. Altere os endereços de IP do novo membro do cluster para refletir corretamente a topologia.
3. Certifique-se de que todos os produtos CheckPoint estejam instalados no novo membro do cluster. Todos os componentes de Software devem ser idênticos em cada membro do cluster.
4. Na página Membros de Cluster do objeto de cluster, crie um novo membro de cluster com as propriedades apropriadas se o Security Gateway for novo ou converta um gateway existente em um membro de cluster. Se o membro for um novo Security Gateway, certifique-se de que o SIC foi inicializado e a topologia foi definida corretamente.
5. Certifique-se de que as interfaces adequadas no novo membro de cluster estejam configuradas como interfaces de cluster se o modo de cluster for Load Sharing ou Nova High Availability.
6. Instale a política de segurança no cluster. O novo membro agora faz parte do cluster.
Stick Connections
Uma conexão é fixa quando todos os seus pacotes são tratados, em qualquer direção, por um único membro do cluster. Esse é o caso no modo de alta disponibilidade, onde todas as conexões são roteadas por meio do mesmo membro de cluster.
No modo de Load Sharing, há casos em que é necessário garantir que uma conexão que começa em um membro de cluster específico continuará a ser processada pelo mesmo membro de cluster em ambas as direções. Para esse fim, certas conexões podem ser tornadas sticky ao ativar a Sticky Decision Function (SDF)
Em uma conexão sticky, o pacote de resposta retorna por meio de um gateway de segurança diferente do pacote original. O mecanismo de sincronização sabe como lidar adequadamente com essas conexões. Em uma conexão sticky, um membro do cluster pode receber um pacote fora do estado, que o Security Gateway normalmente descarta porque representa um risco à segurança. Nas configurações de cluster em Load Sharing, o NAT estático e as conexões criptografadas podem não ser fixas quando os endereços IP de origem e destino mudam. As conexões não aderentes também ocorrerão se o administrador do sistema tiver configurado o roteamento assimétrico, onde um pacote de resposta retorna por meio de um Security Gateway diferente do pacote original. O roteamento assimétrico ocorre quando um pacote é feito por NAT ou criptografado.
Sticky Decision Function
O SDF é necessário em casos de Roteamento Assimétrico. Nestes casos, o pacote é modificado pelo membro do cluster, e uma vez que o pacote que entra no Firewall não é o mesmo que sai, a função de decisão regular não será capaz de garantir que o pacote retornará pelo membro original . O SDF tentará combinar cada pacote com várias tabelas do kernel, na tentativa de decidir qual membro deve lidar com o pacote.
O SDF permite que certos serviços operem em uma implantação de Load Sharing. Por exemplo, é necessário para o tráfego do protocolo de encapsulamento de camada 2 (L2TP) ou quando o cluster é um participante de um túnel VPN site a site com um par de terceiros.
Os seguintes serviços e tipos de conexão são compatíveis com a ativação do SDF:
· Implantações de VPN com pares VPN de terceiros.
· Conexões criptografadas do Endpoint Connect/SSL Network Extender.
O SDF não é compatível com tecnologias de aceleração, como SecureXL e CoreXL, ou uma placa aceleradora baseada em hardware. A ativação do SDF desativa esses produtos de aceleração.
Gerenciamento em High Availability
O Security Management Server consiste em vários bancos de dados com informações sobre diferentes aspectos do sistema, como objetos, usuários e informações de política. Esses dados mudam cada vez que o administrador do sistema faz modificações no sistema. É importante manter uma cópia desses dados para que informações cruciais não sejam perdidas permanentemente no caso de uma falha do servidor de gerenciamento de segurança.
Além disso, se o servidor de gerenciamento falhar ou estiver inativo para fins administrativos, um servidor secundário deve estar instalado para assumir suas atividades. Na ausência do servidor de gerenciamento de segurança, as operações essenciais realizadas pelos gateways, como a busca da Security Policy e a recuperação da Certificate Retrieval List (CRL), não podem ocorrer. A instalação de um Security Management Server secundário e a implantação Management High Availability (HA) fornecem redundância de servidor de gerenciamento de segurança (SMS).
Em um ambiente de alta disponibilidade de gerenciamento, o Active Security Management Server, que é especificado como o principal, sempre tem um ou mais servidores de gerenciamento em espera prontos para assumir em caso de falha. O Standby Security Management Server deve ter o mesmo sistema operacional e versão. A existência do Standby Security Management Server permite que backups cruciais sejam implementados. Quando um Standby Security Management Server (SMS) é instalado, configure e especifique-o como Secundário. Inicialmente, o Security Management Server primário e secundário devem ser sincronizados manualmente. Se servidores Standby adicionais estiverem instalados, configure a sincronização automática no Global Properties.
Uma vez que o Security Management Server (SMS) secundário tenha sido instalado e sincronizado manualmente, o primário e o secundário estão preparados para funcionar como o Security Management Server (SMS) ativo.
Security Management Server Secundários 
O Security Management Server secundário é criado com banco de dados vazio que é preenchido com informações recebidas do Active Security Management Server. O servidor de gerenciamento de segurança secundária está pronto quando:
· É representado no Security Management Server Primário como um objeto de rede.
· O SIC foi inicializado entre ele e o servidor de gerenciamento de segurança primário.
· A sincronização foi concluída com o servidor de gerenciamento de segurança primário pela primeira vez.
Em uma situação em que o Security Management Server primário fica permanentemente indisponível, não é suficiente fazer o failover e alterar o servidor em espera para Ativo. O servidor Secundário deve ser promovido a Primário, ou um novo servidor Primário deve ser estabelecido. O banco de dados só pode ser exportado de um servidor primário.
Todas as operações de gerenciamento, como edição e instalação da política de segurança e modificação de usuários e objetos, são feitas pelo Active Security Management Server. Se o servidor ativo estiver inativo e qualquer uma dessas operações precisar ser executada, o servidor secundário ou um dos servidores de gerenciamento de segurança em espera deve ser ativado pelo administrador do sistema. Esta transição do modo de espera para o ativo deve ser iniciada manualmente.
Os servidores Standby são sincronizados com o servidor Ativo para que sejam mantidos atualizados com todas as mudanças nos bancos de dados e na Política de Segurança. Os