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. Ossecurity gateways podem buscar a política de segurança e recuperar uma CRL dos servidores ativos e em espera.
Security Management Server Failover
O failover do servidor de gerenciamento de segurança é um procedimento manual. Se o Active Security Management Server falhar ou for necessário alterar o Active para Standby, as seguintes etapas devem ser executadas para evitar a perda de dados.
Se o Active Security Management Server estiver respondendo:
1. Sincronize manualmente os Security Management Server Active e Standby.
2. Altere o servidor de gerenciamento Active Security Management Server para Standby.
3. Altere o Security Management Server Standby para Active.
Se o Active Security Management Server falhou e não responde às tentativas de alteração, altere manualmente o servidor Standby para Active. Certifique-se de que nenhum servidor peer esteja ativo antes de fazer a alteração.
NOTA:
Se dois Security management Server (SMS) forem definidos como ativos ao mesmo tempo, um comportamento inesperado pode ocorrer.
Antes de fazer alterações no ambiente de alta disponibilidade, certifique-se de que o status de cada Security Management Server seja conhecido.
Sincronizando Management Servers HA Active e Standby
A sincronização pode ser realizada manualmente ou automaticamente. A sincronização manual é um processo inicializado pelo Administrador do sistema. Ele pode ser configurado para sincronizar bancos de dados e a Política de Segurança instalada. Após a instalação dos servidores em espera, a primeira sincronização deve ser realizada manualmente, mesmo que o sistema esteja configurado para sincronização automática.
A sincronização automática é configurada pelo administrador do sistema para permitir que o servidor em Standby seja sincronizado com o servidor Active em intervalos definidos. Este é o modo padrão de sincronização porque mantém o servidor em espera atualizado. A programação de sincronização é baseada na data de instalação da Política de Segurança, que pode ser definida sempre que a política for salva ou em um horário programado, como diariamente às 2h. Sempre é possível sincronizar manualmente, mesmo quando a sincronização automática foi selecionada.
Quando a sincronização está em andamento, todas as bases de dados são bloqueadas e um snapshot dos recursos é salvo em um disco local. O sistema então compacta os dados do snapshot e copia o snapshot do servidor ativo para todos os servidores em Standby. Os servidores em Standby sobrescreverão seu banco de dados com o snapshot e enviarão notificação de status de restauração para o Active Security Management Server.
Para que o Management HA funcione corretamente, os seguintes dados são armazenados em backup e sincronizados:
· Banco de dados de gerenciamento de segurança de rede (como os objetos de rede, configurações de política e a própria política de segurança)
· Dados de configuração e autoridade de certificação interna (ICA) (como bancos de dados de objetos e usuários, informações de certificado e CRL, que estão disponíveis para serem buscados pelos Security Gateways CheckPoint)
· Bancos de dados do Endpoint Security, se aplicável.
Status de Sincronização
O status de sincronização indica o status do servidor de gerenciamento de segurança em relação ao servidor de gerenciamento de segurança selecionado. Este status pode ser visualizado na janela Gerenciamento de alta disponibilidade ou no SmartView Monitor, dependendo se você está conectado ao servidor de gerenciamento ativo ou em espera. Os seguintes status podem ser exibidos:
· Nunca foi sincronizado - Imediatamente após a instalação do Secondary Security Management Server, ele ainda não passou pela primeira sincronização manual que o atualiza com o servidor de gerenciamento do Security management Server primário.
· Sincronizado - o peer está devidamente sincronizado e possui as mesmas informações do banco de dados e política de segurança instalada.
· Atraso - O peer Security management Server ainda não foi sincronizado, desde que o servidor ativo teve alterações aplicadas a ele.
· Avançado - O peer Security management Server está mais atualizado.
· Colisão - o Active Security Management Server e peer têm diferentes políticas e/ou banco de dados instalados. O Administrador do sistema deve realizar a sincronização manual e decidir qual dos servidores sobrescrever.
Troubleshooting de Sincronização
A sincronização pode falhar por motivos técnicos, como quando o Active Security Management Server não se conecta ao Servidor em espera. Para resolver problemas como este, execute uma das seguintes ações:
· Sincronize manualmente o Standby Security Management Server.
· Instale a política de segurança no Active Security Management Server novamente.
· Se esta opção se a sincronização automática estiver configurada. assim que a política for reinstalada, a sincronização deve ocorrer automaticamente.
A sincronização também pode falhar se ocorrer uma colisão. Neste caso, o Administrador do Sistema deve sincronizar manualmente os servidores e escolher qual banco de dados é o banco de dados dominante. O CA é mesclado para evitar problemas de segurança. Se ocorrer uma colisão entre os servidores e um dos Security management Servers for sobrescrito, use os Logs de auditoria para entender melhor a situação. Revise as operações de gerenciamento que foram executadas recentemente no servidor sobrescrito e execute-as novamente, no servidor dominante, se necessário.
Produtos de Clustering OPSEC Certificados
Os produtos que carregam o selo OPSEC Certified foram testados para garantir a integração e interoperabilidade com o software CheckPoint e plataformas de hardware. Há vários produtos OPSEC Cerfified High Availability e Load Sharing que são usados para configurar clusters de HA Security Gateways e distribuir o tráfego uniformemente entre os gateways clusterizados. Essas aplicações de cluster variam em recursos de monitoramento, gerenciamento e desempenho. Seu papel, no entanto, é o mesmo, pois cada um deles:
1. Decide qual membro do cluster irá lidar com cada conexão.
2. Realiza verificações de saúde, que envolvem verificar o status dos membros do cluster (Ativo, Standby ou Down) e o status das interfaces dos membros.
3. Executa o failover.
Assim como o ClusterXL, os produtos de clustering certificados OPSEC usam a sincronização de estado do CheckPoint para trocar e atualizar dados de conexão e outros estados de Security Gateway entre os membros do cluster.
VRRP Clusters
O protocolo de redundância de roteamento virtual (VRRP) e o ClusterXL são mutuamente exclusivos. VRRP é um protocolo de gerenciamento de rede usado para aumentar a disponibilidade e o desempenho de hosts de serviço de gateway padrão na mesma sub-rede. Ele melhora a confiabilidade e o desempenho da rede host, permitindo que um roteador virtual atue como o gateway padrão para essa rede.
VRRP permite que você configure um grupo de roteadores como roteador de gateway padrão para backup ou redundância. Como solução de cluster, faz com que o grupo de roteadores físicos apareça como um único roteador virtual, permitindo que os hosts configurem o roteador virtual como seu gateway padrão. As plataformas de roteamento VRRP compartilham o endereço IP correspondente à rota padrão configurada nos hosts. Similarmente ao ClusterXL, uma das plataformas de roteamento VRRP é a Master (ativa) e as demais são backups (standby). Se o master falhar, um dos roteadores de backup se tornará o novo roteador mestre, fornecendo um gateway padrão virtual e permitindo que o tráfego seja roteado sem depender do roteador com falha. Um algoritmo de prioridade é usado para determinar se o failover para um backup é necessário, quando o master ou suas interfaces falham. O VRRP aumenta a redundância, tornando-o significativamente benéfico em situações em que a disponibilidade do caminho padrão para hosts de rede é crítica. Pode ser implementado em Ethernet, comutação de rótulo multiprotocolo e redes token ring.
Tal como acontece com o cluster ClusterXLVRRP pode ser configurado para alta disponibilidade ou compartilhamento de carga. Cada cluster VRRP, conhecido como roteador virtual, tem um Identificador de Roteador Virtual (VRID) exclusivo. O VRID é um número usado para agrupar os roteadores. Um roteador virtual pode ter um ou mais endereços IP virtuais (VIP) aos quais outros nós de rede se conectam como um destino final ou o próximo salto em uma rota. Apenas o Mestre é atribuído a um VIP. O backup é atribuído a um VIP no failover, quando se torna o mestre. A implementação de VRRP da CheckPoint evita buracos negros causados por rotas assimétricas criadas quando apenas uma interface no roteador master falha, em oposição ao próprio master. O Gaia libera prioridade sobre todas as interfaces em um roteador virtual para permitir que o failover ocorra.
NOTA:
Você não pode ter uma implantação standalone em um cluster Gaia VRRP.
VRRP Features
O VRRP foi projetado especificamente para permitir o roteamento, encaminhamento e comutação de dados entre um pool de roteadores virtuais. Ao usar VRRP, um caminho padrão de maior disponibilidade é obtido sem a necessidade de configuração de roteamento dinâmico ou protocolos de descoberta de roteador em cada host. Embora existam métodos como o Proxy ARP que podem ajudar os clientes a encontrar seu roteador padrão, muitos engenheiros de segurança simplesmente configuram a rota estática para um único roteador em cada cliente porque é mais fácil. No entanto, se o roteador único ficar inativo, o cliente não conseguirá acessar outras redes.
VRRP inclui:
· Tempo de failover minimizado e sobrecarga de largura de banda quando um roteador principal fica indisponível.
· Suporte de até 255 roteadores virtuais em uma interface física de roteador, sujeito à plataforma que oferece suporte a vários endereços MAC.
· Interrupções de serviço minimizadas durante o failover.
· Provisão para seleção de vários roteadores virtuais em uma rede para compartilhamento de carga.
· Não há necessidade de fazer alterações de configuração nos nós finais se um roteador de gateway falhar.
· Os protocolos de descoberta de roteador para suportar operações de failover não são mais necessários.
· Os problemas de failover são tratados no nível do roteador, e não na borda da rede.
· Funcionalidade em uma ampla variedade de tecnologias de LAN multiacesso capazes de suportar tráfego IP.
Tipos de VRRP
VRRP pode ser configurado um dos modos abaixo:
· Simple Monitored Circuit VRRP - Essa configuração contém todos os parâmetros básicos e é aplicável para a maioria dos ambientes. Cada roteador virtual é configurado como na unidade.
· Advanced VRRP - Este procedimento requer que os usuários configurem manualmente um roteador virtual para cada interface monitorada. Use VRRP avançado se estiver trabalhando com:
· Um sistema no qual o VRRP já foi configurado usando este método.
· Um ambiente onde é necessário monitorar cada interface individualmente.
· O modo VMC preempt.
O Simple Monitored Circuit VRRP e o Advanced VRRP não podem ser usados juntos no mesmo Security gateway.
Monitored Circuit VRRP
O Monitored Circuit VRRP é uma funcionalidade incluída na implementação do CheckPoint VRRP. Elimina problemas de conexão causados por rotas assimétricas quando apenas uma interface no Master falha, ao contrário de toda a plataforma. Esse problema ocorre em ambientes onde um gateway é membro de dois ou mais roteadores virtuais, normalmente um com interfaces internas e o outro com interfaces externas. Por exemplo, quando uma interface externa falha ou se torna inacessível, o Master faz failover para o roteador virtual externo de backup enquanto o roteador virtual interno permanece no Master. Isso pode causar problemas de conectividade quando o roteador virtual interno aceita tráfego e não consegue se conectar ao novo Master externo.
Simple Monitored Circuit VRRP monitora todas as interfaces VRRP nos gateways de segurança. Ao usar VRRP avançado, cada interface em um roteador virtual pode ser configurada separadamente. Se uma interface falhar, o mestre libera sua prioridade sobre todas as interfaces VRRP. Isso permite que o mestre faça failover em todos os roteadores que incluem o mestre com falha.
Para liberar a prioridade, Gaia subtrai o Delta de Prioridade, um parâmetro proprietário do CheckPoint que é definido quando o roteador virtual é configurado, a partir do Valor de Prioridade calcula-se uma Prioridade Efetiva. Se configurado apropriadamente, a Prioridade Efetiva será menor do que a dos roteadores de backup nos outros roteadores virtuais e o protocolo de eleição VRRP é acionado para selecionar um novo Master. Se a prioridade efetiva para o mestre e backup atuais forem iguais, o gateway com o endereço IP mais alto se tornará o Master.
Security Policies
As políticas de segurança devem ser configuradas para aceitar pacotes VRRP na plataforma Gaia se for um Security Gateway habilitado para blade de firewall. O destino Multicast atribuído pela Internet Assigned Numbers Authority (IANA) para VRRP é 224.0.0.18. Se a política não aceitar pacotes de 224.0.0.18, as plataformas de Firewall em um roteador virtual assumem o estado Master. Se os seus Security Gateways usam protocolos de roteamento dinâmico, como OSPRF ou RIP, crie novas regras para cada endereço IP de destino multicast.
Advanced VRRP
O VRRP avançado permite que os roteadores virtuais sejam configurados no nível da interface. Cada roteador virtual deve ser configurado para monitorar a interface VRRP. O VRRP avançado pode ser alterado para VRRP de Simple Monitored Circuit, excluindo todos os roteadores virtuais existentes e criando novos. Ao alterar, é importante compreender que um endereço de backup não pode ser movido de uma interface para outra enquanto um Security Gateway for um mestre. As etapas a seguir são realizadas para excluir e adicionar novas interfaces com os endereços IP necessários:
1. Causa um failover para o backup.
2. Reduza a prioridade ou desconecte uma interface.
3. Exclua o roteador virtual da interface.
4. Crie um novo roteador virtual usando o novo endereço IP.
5. Configure o roteador virtual.
O VRRP avançado pode ser configurado via WebUI ou CLI. Use os comandos set e show para definir as configurações globais e avançadas de VRRP via CLI, como:
set vrrp interface VALUE
show vrrp interface VALUE
Parâmetros de Configuração VRRP
Independentemente do tipo de método VRRP usado, os parâmetros de configuração VRRP devem ser definidos e configurados em cada modo. Os valores de cada parâmetro estão descritos na tabela a seguir.
	Parâmetro
	Descrição
	VRID
	O intervalo é 1-255. Escolha um esquema de numeração para os roteadores virtuais que faça sentido para sua organização.
	Priority
	O intervalo é 1-254. O valor padrão é 100. O valor de prioridade determina qual roteador assumirá o controle em caso de falha. O roteador com prioridade mais alta se torna o novo mestre. Para fornecer uma transição rápida em caso de falha, defina a prioridade para 254 para pelo menos uma plataforma em cada VRID e escolha os valores na extremidade superior da escala para os backups. Prioridade efetiva = Prioridade - Delta de prioridade.
	Priority Delta
	Este parâmetro se aplica apenas ao VRRP de Monitored Circuit. A CheckPoint recomenda usar delta de prioridade padrão, como 10, para simplificar a configuração. Escolha o valor que garantirá que, quando uma interface falhar, o Delta Priority subtraído da prioridade resulta em uma prioridade efetiva menor do que a de todos os roteadores de backup.
	Hello Interval
	O intervalo é de 1 a 255 segundos. A configuração padrão é 1 segundo. O Hello Interval é o intervalo de tempo em segundos no qual o master envia anúncios VRRP. Defina o mesmo valor para todos os nós no VRID.
	Authentication
	Escolha não exigir autenticação para anúncio VRRP ou exigir uma senha simples antes que o anúncio VRRP seja aceito pela interface. Selecione o mesmo método de autenticação para todos os nós no VRID.
	Backup Address (Virtual IP Address)
	Este parâmetro aplica-seapenas ao VRRP de circuito monitorado. O endereço de backup deve estar na mesma rede que a interface usada para o VRID. Quando inserido, o sistema usará a interface que está nessa sub-rede para o VRID.
Parâmetros de configuração VRRP
Acceleration
A CheckPoint provê dois features de aceleração baseadas em software para otimizar a performance: SecureXL e CoreXL.
SecureXL é um produto de aceleração por software instalado nos Security Gateways, para criar a SecureXL Layer. O CheckPoint Security Gateway habilita decisões de segurança para serem realizadas por aplicações de baixo nível para remover os gargalos de performance. CoreXL é uma tecnologia de aprimoramento de desempenho para gateways de segurança em plataformas de processamento de múltiplos núcleos de CPU. Quando habilitado, o CoreXL capacita os núcleos da CPU de processamento para executar simultaneamente várias tarefas, o que melhora o desempenho do Security Gateway sem exigir alterações no gerenciamento ou na topologia da rede. Multi-Queue, permite que cada interface de rede use mais de uma CPU para aceleração.
SecureXL: Security Acceleration
SecureXL é uma tecnologia de aceleração que acelera várias operações intensivas de segurança, incluindo operações realizadas pelo Stateful Inspection Firewall da CheckPoint. Quando habilitado em um Security Gateway, algumas operações com uso intensivo de CPU são processadas por software virtualizado em vez do kernel do Firewall. Usando SecureXL, o Firewall pode inspecionar e processar conexões com mais eficiência, transferindo operações para software ou hardware com desempenho otimizado, aumentando drasticamente o rendimento sem comprometer a segurança. SecureXL está incluído no Gaia e não requer uma licença adicional.
Fluxo de tráfego com e sem SecureXL
Using SecureXL
SecureXL acelera o desempenho de processamento de pacotes, lembrando certos atributos de pacotes e fluxos de pacotes que já foram validados pelos blades. A validação de pacotes e conexões relacionados é então delegada à API SecureXL, que permite descarregar o processamento de segurança para unidades de processamento otimizadas. Essa validação é feita no nível de interrupção de hardware em hardware x86 ou supervisiona a execução de código otimizado adicional nos dispositivos de segurança que os suportam. Ambas as abordagens envolvem uma sobrecarga de computação substancialmente menor do que a exigida pelo Security Gateway.
Da perspectiva do SecureXL, existem três caminhos para o fluxo de tráfego:
· Firewall Path - Pacotes e conexões que são inspecionadas pelo Firewall. Esses pacotes e conexões não são processados pelo SecureXL. Esse caminho também é conhecido como caminho lento (Slow Path).
· Accelerated Path - pacotes e conexões que são descarregados do Firewall para o SecureXL. Esses pacotes e conexões são processados rapidamente.
· Medium Path - pacotes que não podem usar o caminho de aceleração porque exigem uma inspeção mais profunda. Embora não seja necessário que o Firewall inspecione esses pacotes, eles podem ser descarregados por outro recurso. Por exemplo, os pacotes examinados por IPS não podem usar o caminho acelerado e podem ser transferidos para a IPS Passive Streaming Library (PSL), que fornece remontagem de fluxo para conexões TCP. como resultado, o SecureXL processa esses pacotes mais rápido do que os pacotes no caminho lento.
O objetivo do SecureXL é minimizar conexões que são processadas em um caminho lento e acelerar a taxa de conexão. Conforme uma conexão está sendo estabelecida, se um pacote é examinado usando métodos de segurança tradicionais e é determinado como seguro, a camada de dispositivo SecureXL assume a responsabilidade de examinar todos os pacotes restantes para reduzir a latência. O SecureXL pode ser implementado em uma camada de hardware, como dispositivos baseados no Sistema operacional Gaia, ou em uma camada de software virtual em servidores abertos.
Packet Acceleration
A aceleração de pacote, também conhecida como aceleração de taxa de transferência, identifica as conexões por cinco atributos:
· Endereço de Origem.
· Endereço de Destino.
· Porta Fonte.
· Porto de destino.
· Protocolo
Quando o pacote em uma conexão corresponde a todos os cinco atributos, o fluxo de tráfego pode ser processado no caminho acelerado. No entanto, apenas os pacotes durante a conexão TCP / UDP específica podem ser acelerados.
Os pacotes que tentam estabelecer uma nova conexão TCP, ou uma entrada comparável da tabela de conexão UDP no Firewall, são tratados no caminho lento porque requerem mais processamento. uma vez que o primeiro pacote é visto pelo Firewall e as informações de conexão adequadas são descarregadas para um sistema operacional do dispositivo, outros pacotes são tratados no código de nível de interrupção do sistema operacional.
O SecureXL melhora a taxa de transferência do tráfego do Firewall não criptografado e a taxa de transferência do tráfego criptografado (VIN) em uma quantidade significativa, especialmente para pacotes pequenos fluindo em conexões de longa duração.
Existem vários fatores que impedem um pacote de ser acelerado, como:
· O recurso ClusterXL Stick Decision Function (SDF) está habilitado.
· O primeiro pacote de qualquer nova sessão TCP ou UDP, a menos que exista um modelo.
· Conexões destinadas ou originadas do Security Gateway.
· Conexões que requerem Security Servers (autenticação, antivírus, filtragem de URL, anti-spam, aplicação do protocolo DNS).
· Conexões que possuem um manipulador (ICMP, FTP, H323, etc.)
· Alguns recursos IPS (IP, ID, TTL).
· Pacotes Multicast.
Session Rate Acceleration
O SecureXL também reduz a sobrecarga no estabelecimento de certos tipos de novas conexões, melhora na taxa de conexão (conexões por segundo), taxa de configuração/desativação de conexão (sessão por segundo) e taxa de transferência em certos ambientes de tráfego de alta taxa de conexão.
O princípio envolvido é uma extensão simples da abordagem do SecureXL para validações no momento do fluxo do Firewall. As validações on-time estendem-se de 5 atributos específicos para um intervalo, ou bloco, de um ou mais desses atributos. Isso significa que, para acelerar a taxa de novas conexões, as conexões que não correspondem a 5 atributos especificados ainda são processadas pelo SecureXL.
Como exemplo, a porta de origem de um fluxo de pacote pode ser mascarada, fornecendo efetivamente uma correspondência global para a porta de origem. Depois que um fluxo é validado e estabelecido, o SecureXL cria e salva o modelo desse fluxo com a porta de origem mascarada. Qualquer novo pacote de configuração de conexão que corresponda aos outros 4 atributos é processado no caminho acelerado, evitando assim a inspeção Firewall e sobrecarga de computação adicional. A segurança não é afetada porque o sistema operacional continua a rastrear o estado da nova conexão usando a Stateful Inspection.
Masking the Source Port
Para examinar como as portas são usadas no estabelecimento de conexões TCP, considere o seguinte cenário. Um cliente solicitando uma conexão a um servidor inicia o Three-way Handshake TCP. O cliente adiciona o servidor, normalmente em um número de porta conhecido dependendo do serviço fornecido pelo servidor, tal como porta 23 para Telnet ou porta 80 para HTTP. Juntos, o endereço IP do servidor e o número de porta conhecido formam um endereço de soquete. O cliente atribui e emparelha um número de porta selecionado pelo sistema operacional com o endereço IP do cliente para criar um endereço de soquete para a direção reversa.
 Port Connections
Application Layer Protocol - An HTTP Example
Considere os protocolos de aplicativos de nível superior que envolvem várias conexões TCP entre cliente e servidor, simultaneamente (em paralelo), sequencialmente ou ambos. HTTP, responsável pela maior parte do tráfego da Internet, é um desses protocolos. O HTTP gera a maioria das novas solicitações de conexão no tráfego corporativo e da Internet.
As páginas da Web consistem em vários componentes HTTP,texto e talvez dezenas de elementos gráficos. usando HTTP, cada componente é baixado do servidor para o cliente usando uma conexão TCP separada. Essa ação envolve uma sobrecarga substancial na configuração e desmontagem da conexão e no rastreio da conexão do Firewall de proteção (Firewalls em ambas as extremidades).
Em todos os casos entre um cliente web e um servidor web, o estabelecimento da conexão TCP é iniciado pelo cliente web, que então envia uma solicitação HTTP. Os servidores web respondem enviando o componente HTTP:
· HTTP Request (->) - Cada um dos pacotes do cliente da web que solicita um componente HTTP do servidor da web tem o mesmo endereço de origem, endereço de destino, porta de destino (80) e protocolo (HTTP). Apenas a porta de origem, atribuída (uma por conexão) pelo sistema operacional do cliente web, difere para criar um endereço de soquete exclusivo no cliente para cada solicitação / componente HTTP (por meio de conexões TCP separadas para cada componente).
· HTTP Component (<-) - Indo na direção oposta, cada um dos pacotes do servidor da web que constrói os componentes da página da web no cliente da web tem o mesmo endereço de origem, endereço de destino, porta de origem (80 e protocolo (HTTP). Apenas a porta de destino é diferente (ela foi atribuída por qualquer sistema operacional cliente a essa conexão).
Assim que uma conexão envolvendo um fluxo para a porta 8- é aprovada pelo firewall para o cliente web (resultante da primeira solicitação HTTP), um modelo é criado e armazenado. Todas as configurações de conexão subsequentes que transportam essas solicitações adicionais podem compartilhar a mesma aprovação de modelo, porque é normal que as portas de origem sejam diferentes. Estabilizar essas conexões subsequentes não envolve uma viagem de ida e volta ao Firewall, resultando em um processamento mais rápido por meio do Firewall do servidor.
Similarmente, no Firewall do cliente, uma vez que uma conexão envolvendo um fluxo para a porta 80 seja aprovada pelo Firewall (como acima), todas as conexões subsequentes que transportam essas solicitações adicionais podem compartilhar a mesma aprovação. O estabelecimento dessas conexões subsequentes não envolve uma viagem direta ao firewall. SecureXL acelera as conexões subsequentes através de ambos os Firewalls quando várias conexões compartilham o mesmo endereço de origem, endereço de destino, portas de destino e protocolo.
Secure Connection Templates
Os modelos de conexão SecureXL criam a oportunidade de gerar taxa de conexão e desempenho extremamente impressionantes. Dado o benefício dos modelos de conexão em ambientes HTTP pesados, o aumento significativo de desempenho pode ser refletido nas configurações de tráfego do mundo real, como em farms de servidores da web e empresas onde há uma grande quantidade de tráfego da web para um conjunto pequeno e concentrado de servidores .
Para acelerar o ritmo de estabelecimento das conexões, o SecureXL agrupa todas as conexões que correspondem a um determinado serviço e cujo único elemento diferenciador é a porta fonte. Este tipo de agrupamento permite que até mesmo o primeiro pacote de um handshake TCP seja acelerado. Os primeiros pacotes da primeira conexão no mesmo serviço serão encaminhados ao kernel do Firewall, que criará um modelo de conexão. SecureXL tem três modelos diferentes:
· Accept Templates - criado quando uma conexão é estabilizada combinando uma nova conexão com um determinado conjunto de atributos de tuple. As conexões subsequentes são estabelecidas sem realizar uma correspondência de regra e, portanto, são aceleradas. Os Accept Templates são habilitados por padrão e gerados a partir de conexões ativas de acordo com as regras de política. Aceitar aceleração de modelo somente em conexões com a mesma porta de destino.
· Drop templates - gerados por roteadores de política para acelerar a velocidade na qual uma conexão é descartada, combinando uma nova conexão a um conjunto de atributos de tuple. As conexões subsequentes são droped sem realizar uma correspondência de regra e, portanto, são aceleradas. Drop Template é realizado também apenas em conexões com a mesma porta de destino. Esses Templates estão desabilitados por padrão.
· NAT Templates - gerados para atingir alta taxa de sessões para NAT. Esses Templates são suportados nos modos de cluster HA/VRRP e Load Sharing. NAT Templates são controlados por parâmetros globais do kernel e desabilitados por padrão.
Fatores que Impedem Templating
Existem fatores que podem impedir o templating se todos os outros parâmetros são atendidos para aceleração de pacote, tais como:
· Ranges de Portas de Origem,
· Recursos de IP não suportados na Aceleração,
· Tráfego NATeado, a não ser que os Templates de NAT estejam habilitados,
· Conexões criptografadas.
Uma vez que a modelagem é desativada na Rule Base, todas as conexões que correspondem às regras inferiores na Rule Base não podem ser modeladas. Use fwaccel stat para determinar em qual modelo de regra está desabilitado e mova as regras mais usadas acima dessa regra para tirar vantagem da aceleração de sessão.
Packet Flow
A imagem que segue exibe a lógica de decisão para o fluxo de pacotes passando através dos appliances de segurança SecureXL.
Lógica de Decisão do Packet Flow
Um novo pacote chega na interface de entrada. O pacote é verificado em relação à tabela de conexões, que espelha a tabela de conexões do Firewall. Se houver uma correspondência de 5-tuple, o novo pacote faz parte de um fluxo existente e é encaminhado à interface de saída (Outbound) para tratamento (forward, drop ou reject). Esse caminho envolve a menor quantidade de sobrecarga de encaminhamento e acelera a taxa de transferência de pacotes que fazem parte de um fluxo existente.
Se o novo pacote não corresponder a uma entrada na tabela de conexões, ele representará um novo fluxo e exigirá uma nova entrada na tabela de conexões. Porém, se o pacote corresponder a um Template de conexão existente, a nova entrada da tabela de conexões pode ser criada (com base nas informações na entrada da tabela do Template de conexão) sem uma viagem de ida e volta para a aplicação de Firewall. O pacote é então encaminhado para a interface de saída (Outbound) para tratamento. Esse caminho reduz a sobrecarga envolvida na criação de uma nova entrada na tabela de conexão e acelera a taxa de conexão para novas conexões que correspondem ao modelo de conexão existente.
Se o novo pacote não corresponder a um modelo de conexão existente, uma viagem de ida e volta para a aplicação de Firewall será necessária para aplicar a Security policy. Este caminho envolve a maior sobrecarga.
Capacidades VPN
SecureXL adiciona recursos de roteamento VPN e melhora a conectividade para suportar VPN em ambientes de roteamento dinâmico.
VPN Link Selection
A seleção de link VPN permite que várias interfaces externas sejam configuradas para encapsular os pacotes VPN. Ele permite que o Firewall crie, mantenha e atualize uma tabela de entradas do Link Selection. O Firewall pode especificar qual link precisa ser usado para uma determinada Security Association. Se esse link cair, o Firewall pode atualizar as entradas do Link Selection para começar a usar um link diferente para o mesmo túnel.
Dynamic VPN Routing
Dynamic VPN Routing permite que o domínio VPN seja determinado dinamicamente em vez de configurar um domínio VPN estático. Com o Dynamic VPN Routing habilitado, as conexões podem passar de texto não criptografado para criptografado ou de criptografado para texto não criptografado, com base na rota percorrida pela conexão. As propriedades da conexão se adaptam às mudanças de rota entre uma interface externa (não confiável) e uma interface interna (confiável) por comunicação em texto criptografado ou não criptografado, respectivamente.
Wire Mode Connections
Wire Mode Connections permite que o tráfego confiável passe sem Stateful Inspection. Se uma interface interna e a VPN Community forem configuradas como wired (confiável), o tráfego quepassa pela interface interna e é criptografado usando a VPN Community irá ignorar qualquer Stateful Inspection. Isso aumenta a velocidade de conectividade com menor segurança para o tráfego entre interfaces wired e uma VPN Community wired.
CoreXL: Multicore Acceleration
Como a primeira tecnologia de segurança a aproveitar totalmente os processadores multi-core de uso geral, o CoreXL apresenta balanceamento de carga de nível de núcleo avançado que aumenta o throughput para a inspeção profunda necessária para atingir a prevenção de intrusão e alto throughput. Com o CoreXL, alto desempenho e alta segurança podem ser alcançados simultaneamente. Como SecureXL, CoreXL também está incluído no sistema operacional Gaia e não requer licenciamento adicional.
Configuração do CoreXL em uma máquina com 8 núcleos de CPU
Usando CoreXL
O suporte a CPU muti-core permite que os CheckPoint Security Gateways compartilhem o tráfego entre os núcleos de um único sistema, fornecendo desempenho superior em um único servidor. A combinação de CPUs multi-core e tecnologia de aplicação de segurança SecureXL multi-threaded é a base para a próxima geração de aceleração de segurança: Segurança da camada de Aplicação. Ao juntar-se a uma CPU multi-core com aceleração de segurança SecureXL, os Security Gateways podem fornecer mais de 10 Gbps de throughput.
Usando CoreXL, o kernel do firewall é replicado várias vezes. Cada cópia replicada, ou instância, do kernel do Firewall é executada em um núcleo de processamento. As instâncias lidam com o tráfego simultaneamente e cada instância é um kernel de inspeção completo e independente. Com relação à topologia de rede, configuração de gerenciamento e Security policy, um gateway CoreXL funciona como um gateway de segurança normal. Todas as instâncias kernel de um gateway tratam do tráfego que passa pelas mesmas interfaces e aplicam a mesma Security policy. O tráfego que entra em placas de interface de rede (NIC) é direcionado a um núcleo de processamento de CPU executando o Secure Network Distributor (SND), que irá distribuir pacotes não acelerados entre as instâncias do kernel do Firewall e acelerar com segurança os pacotes autorizados para serem processados usando SecureXL.
O CoreXL atua como um balanceador de carga e melhora o desempenho do Security Gateway em situações em que grande parte do tráfego não pode ser acelerado pelo SecureXL ou quando o gateway tem muitos recursos IPS habilitados, o que desabilita a funcionalidade SecureXL. Ele também melhora o desempenho de gateways com grandes regras de base de regra e NAT. O CoreXL não beneficia o gateway quando o tráfego consiste principalmente em tráfego VPN ou VoIP.
CoreXL não é compatível quando um dos seguintes recursos está ativado:
· Modo tradicional VPN.
· Sobreposição de NAT.
Configurando CoreXL
CoreXL é habilitado ou desabilitado usando cpconfig e requer reinicialização para ter efeito. Quando habilitado, deve-se inserir o número de instâncias do kernel do Firewall para o gateway. O número padrão de instâncias do kernel é derivado do número total de núcleos no sistema, conforme descrito na tabela a seguir:
	Número de Cores
	Número de Instâncias de Kernel
	1
	CoreXL desabilitado
	2
	2
	4
	3
	6-20
	(número de CPU cores) - 2
	Mais de 20
	(número de CPU cores) - 4
Não mais que 40 no total.
Se estiver usando CoreXL com ClusterXL, o número de instâncias do kernel deve ser idêntico em todos os membros do cluster. Isso ocorre porque a Sincronização de estado entre os membros do cluster é realizada por instância do kernel do Firewall CoreXL. Por exemplo, a instância #2 no membro do cluster A só pode sincronizar com a instância #2 ou membro do cluster B.
Processando Core Allocation
A arquitetura do software CoreXL inclui o Secure Network Distributor (SND). O SND é responsável por processar o tráfego de entrada das interfaces de rede, acelerando com segurança os pacotes autorizados (se o SecureXL estiver em execução) e distribuindo os pacotes não acelerados entre as instâncias do kernel. Em outras palavras, o SND é essencialmente um núcleo de CPU executando SecureXL e CoreXL.
O tráfego que entra na NIC é direcionado a um núcleo de processamento que executa o SND. A associação de uma interface específica com um núcleo de processamento é chamada de afinidade da interface com aquele núcleo. Afinidade é um termo geral usado para descrever interrupções de ligação de NIC aos processadores. As configurações de afinidade para todas as interfaces são definidas automaticamente por padrão quando a arquitetura CoreXL inclui o processamento de tráfego de entrada de NICs. Essa afinidade faz com que o tráfego da interface seja direcionado para esse núcleo e o SND seja executado nesse núcleo. Definir uma instância do kernel ou um processo para ser executado em um núcleo específico é chamado de afinidade da instância, ou processo, com aquele núcleo. O tráfego de todos os NICs é direcionado para o núcleo que executa o SND.
A afinidade padrão para todas as interfaces é automática. Se o SecureXL estiver em execução, a afinidade para cada interface será redefinida automaticamente a cada 60 segundos e equilibrada entre os núcleos disponíveis. Se o SecureXL não estiver em execução, as afinidades padrão de todas as interfaces serão com um núcleo disponível. Em ambos os casos, qualquer núcleo de processamento executando uma instância do kernel, ou definido como afinidade para outro processo, é considerado indisponível e não será definido como afinidade para nenhuma interface.
Em alguns casos, os núcleos SND podem estar sobrecarregados devido ao alto tráfego em várias interfaces atribuídas ao mesmo núcleo SND. A afinidade sim manual pode aliviar esse sintoma. Use o comando sim affinity -l para ver a distribuição de afinidade. Cada interface ocupada deve receber seu próprio valor de Interrupt ReQuest (IRQ) e distribuída entre os núcleos SND. A atribuição de interfaces IRQs pode ser verificada no arquivo /proc/interrupts.
Em alguns casos, pode ser aconselhável alterar a distribuição das instâncias do kernel, o SND e outros processos entre os núcleos de processamento. Isso é feito alterando as afinidades de diferentes NICs e/ou processadores. entretanto, para garantir a eficiência do CoreXL, todo o tráfego da interface deve ser direcionado para núcleos que não executam instâncias do kernel. Portanto, alterar as afinidades de interfaces ou outros processos exigirá a redefinição do número de instâncias do kernel e a garantia de que as instâncias sejam executadas em outros núcleos de processamento.
Em circunstâncias normais, não é recomendado que o SND e uma instância compartilhem um núcleo. No entanto, é necessário que o SND e uma instância compartilhem um núcleo ao usar uma máquina com exatamente dois núcleos.
Adding Processing Cores to the Hardware
Aumentar o número de núcleos de processamento na plataforma de hardware não aumenta automaticamente o número de instâncias do kernel. Se o número de instâncias do kernel não aumentar, o CoreXL não utiliza alguns dos núcleos de processamento. Depois de atualizar o hardware, aumente o número de instâncias do kernel usando cpconfig.
A reinstalação do Security Gateway mudará o número de instâncias do kernel se você tiver atualizado o hardware para um número maior de núcleos de processamento, ou se o número de núcleos de processamento permanecer o mesmo, mas o número de instâncias do kernel for alterado manualmente em relação ao padrão.
Em uma implantação em cluster, a alteração do número de instâncias do kernel, como reinstalar o CoreXL, deve ser tratada como uma atualização de versão. Siga as instruções no Upgrade Guide e execute uma atualização de esforço mínimo com downtime da rede ou uma atualização com zero downtime, substituindo a alteração do número de instância pela atualização de versão no procedimento. Uma atualização completa de conectividade não pode ser executada ao alterar o número de instâncias do kernel em um ambiente em cluster.
Allocationg an Aditional Core to the SND
Em algunscasos, a configuração padrão das instâncias e do SND não será a ideal. Se o SND está reduzindo o tráfego e sua plataforma contém núcleos suficientes para que você possa reduzir o número de instâncias do kernel, você pode alocar um núcleo adicional para o SND. É provável que isso ocorra, especialmente se grande parte do tráfego for acelerado pelo SecureXL, em uma implantação de ClusterXL em Load Sharing ou se os recursos IPS estiverem desabilitados. Em qualquer um desses casos, a carga de tarefas do SND pode ser desproporcional às instâncias do kernel.
NOTA:
A CheckPoint recomenda que sua plataforma tenha pelo menos 8 núcleos de CPU para alocar um núcleo adicional ao SND.
Allocating a Core for Heavy logging
Se Security Gateway estiver executando logs pesado, pode ser aconselhável alocar um núcleo de processamento para o daemon fwd, que realiza o registo. Assim como adicionar um núcleo para o SND, esta ferramenta reduz o número de núcleos disponíveis para instâncias do kernel.
Dynamic Dispatcher
O Dynamic Dispatcher é um recurso CoreXL que ajuda a melhorar a distribuição de carga e atenua os problemas de conectividade durante os picos de tráfego. Sem o Dynamic Dispatcher, novas conexões para uma instância do Firewall CoreXL são fixas ou atribuídas estaticamente, com base nos endereços IP do pacote e no tipo de protocolo IP. Essa atribuição estática pode resultar em situações em que uma ou mais instâncias manipulem mais conexões ou executem mais processos nos pacotes encaminhados a eles do que as outras, o que pode fazer com que a carga fique desequilibrada entre os núcleos da CPU. Além disso, durante os horários de pico e a instalação da política, um núcleo de sobrecarga pode fazer com que o tráfego seja atrasado ou interrompido.
Quando o Dynamic Dispatcher está ativado, as conexões com as instâncias CoreXL são atribuídas dinamicamente, com base na utilização dos núcleos da CPU. O Dynamic Dispatcher distribuirá a carga igualmente entre os núcleos da CPU. As conexões abertas em uma taxa mais alta que teriam sido atribuídas à mesma instância por uma decisão estática agora são distribuídas para várias instâncias.
O recurso Dynamic Dispatcher vem habilitado por padrão no R80.10. Quando habilitada, a decisão de atribuição dinâmica é feita para os primeiros pacotes de conexões atribuindo uma classificação a cada uma das instâncias e selecionando a instância com a classificação mais baixa. A classificação de cada instância é calculada de acordo com a utilização da CPU da instância. Se a utilização da CPU de uma instância for alta, a classificação dessa instância também será alta. Instâncias com classificação mais alta provavelmente serão selecionadas pelo SND.
Quando Habilitar o Dynamic Dispatcher
O Dynamic Dispatcher é mais benéfico em ambientes com grande número de núcleos de CPU e quando as cargas da CPU não estão devidamente balanceadas. Habilite o Dynamic Dispatcher se os seguintes limites ou situações ocorrerem:
· Uma instância CoreXL consome sua cota de CPU em > 85%, mesmo por um segundo.
· Outras instâncias do CoreXL consomem o núcleo da CPU em 75% e abaixo. A diferença no consumo de CPU entre instâncias sobrecarregadas e normalmente carregadas é de 10% ou mais.
· O tráfego é interrompido ou atrasado em um núcleo sobrecarregado durante os picos de tráfego ou durante a instalação da política.
Quando o Dynamic Dispatcher está ativado, as conexões são sempre atribuídas dinamicamente, mesmo nos casos em que não há diferenças significativas na carga da CPU, com a exceção de pacotes criptografados de VoIP e VPN. Esses dois tipos de tráfego sempre serão tratados pela mesma instância do Firewall. A distribuição de conexões em todas as instâncias do Firewall CoreXL pode ser verificada usando o comando fw ctl multilik stat. Verificar as conexões permitirá que você monitore as conexões atuais e, por fim, decida se deseja ou não ativar o recurso Dynamic Dispacther. Para ativar totalmente o Dynamic Dispatcher em um Security Gateway, execute o seguinte comando no Modo Expert e reinicie:
fw ctl multilik dynamic_dispatching on
Firewall Priority Queues
As Priority Queues do firewall priorizam o tráfego quando os núcleos da CPU no firewall são 100% utilizados e os pacotes precisam ser descartados. Este recurso é desabilitado por padrão no R80.10. Quando habilitadas, as Priority Queues só ficam ativas quando a CPU está sobrecarregada. Quando o Firewall é totalmente utilizado, a perda de pacotes pode ocorrer independentemente do tipo de conexão (por exemplo: conexões SSH e DHCP).
Priority Queues (filas de prioridades) prioriza os pacotes com base no tipo de conexão, e cada conexão com a mesma prioridade terá uma parcela igual dos recursos da CPU. Existem 8 filas prioritárias por padrão e até 8 filas adicionais podem ser configuradas manualmente. Quando um novo pacote chega, a conexão é classificada para saber a qual está atribuída. Por exemplo, os pacotes de uma conexão SSH irão para a fila de controle.
	Queue Priority
(0 - highest)
	Queue Name
	Type of Connection
	Can Connections Migrate?
	0
	Routing
	DHCP, VRRP, OSPF, BGP, IGMP, PIM
	No
	1
	Control
	GUI/SSH/Ports 18xxx/Management Services
	Yes
	2
	Cluster Sync
	Local/Full sync
	No
	3
	High Priority
	User Difined
	Yes
	4
	Light Data Queue
	Ligh Connections
	Yes
	5
	Default Data Queue
	Medium weight connection or new connection
	Yes
	6
	Log Notification
	Log and Drop Notifications
	No
	7
	Heavy Data Queue
	Heavy Connections
	Yes
Alguns tipos de conexão podem ser migrados entre Priority Queues (filas de prioridade) para receber uma prioridade mais baixa ou mais alta em relação a outras conexões. Por exemplo, uma nova conexão começa sua vida na Default Data Queue (Fila # 5). Se esta conexão ficar mais leve, ela migrará para uma Priority Queue (fila de prioridade) mais alta, como a Light Priority Queues (Fila nº 4). Se a conexão ficar mais pesada, ela pode migrar para uma Priority Queues (fila de prioridade) mais baixa, como a Heavy Priority Queues (Fila nº 7). O Firewall decidirá se a conexão deve ou não ser migrada, com base no tempo médio de carregamento de uma conexão desse tipo. Ele sabe a quantas filas possíveis a conexão foi atribuída e a carga da CPU causada por esta conexão.
Para habilitar o Dynamic Dispatcher em um Security Gateway sem as Priority Queues do Firewall, execute o seguinte comando no Modo Expert e reinicie:
fw ctl multilik prioq 2
Fluxo dos Pacotes com o CoreXL e SecureXl Habilitados
Fluxo dos Pacotes pelo Gateway
Acceleration Path
O pacote é completamente manipulado pelo dispositivo SecureXL. Ele é processado e enviado de volta à rede.
Medium Path
O pacote é manipulado pelo dispositivo SecureXL, exceto para processamento de IPS, Application Control, Antivírus e Anti-bot. A layer CoreXL passa o pacote para uma das instâncias do Firewall para realizar o processamento. Este caminho está disponível apenas quando CoreXL está habilitado.
Firewall Path
O dispositivo SecureXL não pode processar o pacote. Ele é passado para a layer CoreXL e, em seguida, para uma das instâncias para processamento completo no Slow Path.
Multiple Traffic Queues
Como mencionado antes, o SND é um núcleo de processamento que acelera o tráfego das interfaces de rede usando SecureXL e distribui pacotes não acelerados entre instâncias usando CoreXL. O número de CPUs alocadas ao SND é limitado pelo número de interfaces de rede que tratam do tráfego. Por padrão, cada NIC tem uma fila (queue) de tráfego controlada por uma CPU. Portanto, os usuários não podem usar mais núcleos de CPU para aceleração do que o número de interfaces que controlam o tráfego. Multi-Queue é um recurso de aceleração que permitirá que você configure mais de uma fila (queue) de tráfego para cada NIC, para usar mais núcleos de CPU para a aceleração.
Usando Multi-Queue
Quando a maior parte do tráfego de rede está sendo acelerada, a carga da CPU para SND pode ser muito alta, enquanto a carga da CPU das instâncias do Firewall CoreXL é muito baixa. Isso resultaem uma utilização ineficiente da capacidade da CPU. O uso do Multi-Queue para configurar mais de uma fila de tráfego para cada interface de rede com suporte ajuda a equilibrar a carga de maneira eficiente entre CPUs SND e CPUs de instância CoreXL.
A CheckPoint não recomenda atribuir SND e uma instância CoreXL ao mesmo núcleo de CPU. O Multi-Queue não melhora o desempenho do Firewall em situações como quando todas as instâncias do Firewall estão altamente carregadas e a maior parte do tráfego está sendo processada nos Slow Path ou Medium Path do CoreXL, ou seja, nos casos em que todos os núcleos da CPU usados pelo SecureXL estão congestionados. Além disso, o Multi-Queue não ajuda quando IPS ou outras Software Blades de inspeção profunda são muito usados.
Configurando Multi-Queue
CheckPoint recomenda configurar o Muti-Queue quando uma das seguintes condições está presente:
· A carga de CPU para SND é alta (idle < 20%).
· A carga de CPU das instâncias do CoreXL é baixa (idle > 50%).
· Não existem núcleo de CPU a serem atribuídos ao SND alterando a afinidade da interface.
NOTA:
A Interrupt ReQuest (IRQ) das filas (queues) é definida automaticamente quando o SO é inicializado. Alterar manualmente a afinidade de IRQ das filas (queues) pode afetar negativamente o desempenho.
Use as seguintes diretrizes para ajudar a determinar se sua rede pode se beneficiar da configuração de Muiti-Queues:
· Certifique-se de que SecureXL e CoreXl estejam habilitados.
· Certifique-se de que as interfaces de rede suportam Multi-Queue.
· Examine a affinity da CPU para ver como as funções da CPU são alocadas para as interfaces (SND) e para as instâncias CoreXL. Para ver a alocação de funções da CPU, execute o seguinte comando:
f w ctl affinity -l
fw ctl affinity -l
· Examine a utilização da CPU em relação as percentagens de uso e idle. Rode o top no Security Gateway e pressione 1 para alterar para visualização SMP.
Exemplo de utilização de CPU
· Determine se mais núcleos de CPU podem ser alocados para o SND. Se houver mais interfaces de rede tratando do tráfego do que CPUs atribuídas ao SND, então, mais CPUs podem ser alocadas para SND.
Para configurar o Multi-Queue nas interfaces que suportam, rode o comando:
cpmq set
O comando exibirá todas as interfaces com suporte que estão ativas e permitirá que alterações sejam feitas na configuração Multi-Queue de cada interface. É importante reinicializar o gateway após alterar a configuração do Multi-Queue. No máximo cinco interfaces podem ser configuradas.
Para visualizar o status do Multi-Queue nas interfaces que suportam, rode o comando:
cpmq get
SmartEvent
A Blade SmartEvent transforma entradas de los em informações de segurança significativas. Ele correlaciona eventos de log, agrega dados e identifica padrões de ataque em potencial de vários dispositivos. Ele prioriza os eventos de segurança entre uma infinidade de atividades de registo na rede, tornando mais fácil para os Cyber Security Administrators remediar e prevenir eventos críticos. Com seus relatórios gráficos personalizáveis e interface de usuário (GUI) intuitiva, os administradores podem monitorar prontamente padrões e eventos à medida que eles se desdobram e fornecer relatórios às principais partes interessadas na organização.
A Solução Smart Event
CheckPoint SmartEvent Software Blade é uma solução unificada de gerenciamento e análise de eventos de segurança que fornece informações gráficas de gerenciamento de informação. Ele permite que os administradores de segurança vejam as atividades da rede em tempo real em visualizações ou relatórios personalizados. Visualizações personalizadas permitem monitorar atividades relevantes para proteger sua organização. Os relatórios personalizados permitem que você relate as atividades de segurança aos principais interessados em sua organização.
O SmartEvent fornece uma visão de alto nível e uma análise forense detalhada de incidentes para ajudar no monitoramento, correção, e remediação de incidentes de segurança. Ele também ajuda você a executar análises de dados com eficiência e a identificar eventos de segurança críticos entre um grande número de registros na rede. Com o SmartEvent, você pode coletar, processar e pesquisar bilhões de entradas de registros em segundos.
Logs and Events
Um log é um registo de uma ação realizada por uma Software Blade. As entradas de log mostram os padrões de tráfego que são relevantes para a segurança geral da organização. Um evento é um registo de um incidente de segurança ou de rede baseado em um ou mais logs e em um conjunto de regras personalizado definido na política de eventos (Event Policy).
A Event Policy é um conjunto de regras que definem o comportamento do SmartEvent. Uma entrada de registo (ou várias entradas de registo) torna-se um evento quando corresponde a qualquer regra definida na Event policy. Um exemplo de uma única entrada de log que se torna um evento é um evento High Severity Anti-bot, devido às regras definidas na Event Policy. Várias entradas de log também podem se tornar um evento, como no caso de um evento de Certificate Sharing, no qual dois logins foram encontrados com o mesmo certificado, mas usuários diferentes.
O SmartEvent define automaticamente os logs que não são de Firewall, VPN ou HTTPS Inspection logs, como eventos. Esses eventos são criados pela Unidade de Correlação (Correlation Unit) quando há um padrão suspeito de dois ou mais logs. Os eventos correlacionados são definidos na guia Policy na GUI do SmartEvent.
Como a maioria dos registros são Firewall, VPN e HTTPS, o SmartEvent não os definirá automaticamente como eventos. Isso evita problemas de desempenho do SmartEvent Server. No entanto, a ativação de eventos consolidados para firewall economiza espaço em disco e torna possível manter um histórico de eventos mais longo. Para criar eventos para o Firewall, navegue até a guia SmartEvent Policy e habilite Consolidated Sessions > Firewall Session.
SmartEvent Components
O SmartEvent utiliza vários componentes-chave para agregar logs, identificar eventos de segurança críticos e fornecer consultas de eventos eficientes. Os três componentes principais são Log Server, Correlation Unit e SmartEvent Server.
Log Server
O Log Server é responsável por armazenar logs coletados dos CheckPoint Security Gateways e dispositivos de terceiros. O Correletion Unit conecta o Log Server para ler os logs usando o protocolo LEA (Log Export API). O Log Server usa a porta 18184 para esta conexão por padrão.
NOTA:
Ao configurar o Log Server para usar uma porta LEA diferente, você deve configurar manualmente a nova porta no Smart Event Server e no Correlation Unit.
Correlation unit
O Correlation Unit avalia os logs do Log Server para identificar eventos. Cada registo consiste em dados de produtos CheckPoint e dispositivos de terceiros. Ele procura padrões de ameaça nesses dados que correspondam à Event Policy instalada. Ao analisar um log, o Correlation Unit executa uma das seguintes ações:
· Registros de marcas que individualmente não são eventos, mas podem fazer parte de um padrão maior a ser identificado posteriormente,
· Gera um evento com base na Event Policy,
· Pega uma nova entrada de registo que faz parte de um grupo de itens que juntos constituem um evento e a adiciona a um evento em andamento,
· Descarta os logs que não atendem aos critérios de evento.
Assim que uma ameaça é detectada, o Correlation Unit encaminha o evento para o Smart EventServer.
Os Correlation Units SmartEvent podem analisar logs para mais de um Log Server. A CheckPoint recomenda instalar um Correlation Unit em cada Log Server se a sua organização produzir um alto volume de atividade de log. Com uma rede pequena, é melhor pré-configurar o armazenamento de Correlation Unit no SmartEvent Server.
SmartEvent Server
O SmartEvent Server hospeda o banco de dados de eventos. Ele recebe todos os logs identificados como eventos pelo Correlation Unit. O SmartEvent Server realiza outra análise para determinar a gravidadedo evento e que ação tomar. O evento é então armazenado no Events Database. Este banco de dados roda em Apache Solr, uma plataforma de busca de código aberto escrita em Java. A principal vantagem do Solr é que ele gerencia os logs com seus índices, o que permite uma forma mais eficiente de gerar resultados de pesquisa.
SmartEvent Clients
Os clientes SmartEvent gerenciam o SmartEvent Server e fornecem uma visão geral das informações de segurança para o ambiente de uma organização. Eles consolidam bilhões de logs e os exibem como eventos de segurança priorizados. Os administradores podem usar as informações exibidas para monitorar a atividade da rede, identificar e investigar eventos críticos e responder imediatamente a incidentes de segurança para evitar novos ataques.
Os clientes SmartEvents são:
· SmartConsole - instalado como um aplicativo externo.
· SmartEvent GUI - requer instalação do cliente.
· Aplicativo SmartView Web - não requer instalação de cliente. Ele tem o mesmo monitoramento de eventos em tempo real e visualizações de análise do SmartConsole. Para fazer login no SmartEvent usando a aplicação SmartView Web, navegue até https://<Security_Management_Server_IP>/smartview/ ou https://<Security_Management_Server_hot_name>/smartview/.
NOTA:
A URL da aplicação SmartView Web diferencia maiúsculas de minúsculas. O "/" no final é obrigatório. O SmartEvent deve ser habilitado para visualizar o SmartView
SmartEvent Workflow.
O workflow abaixo fornece uma visão de alto nível sobre como os diferentes componentes SmartEvent interagem:
Smartview workflow
1. Os produtos CheckPoint e outros dispositivos de terceiros suportados encaminham os registros ao Log Server para armazenamento. O Correlation Unit lê todos os logs do Log Server e faz a análise de correlação com base na política SmartEvent. A Política de Eventos reside na Correlation Unit.
2. Depois que o Correlation Unit identifica um padrão de ameaça, ele identifica as entradas de log associadas como um evento e as envia ao SmartEvent Server. O SmartEvent Server atribui um nível de severidade ao evento, invoca quaisquer reações automáticas definidas e adiciona o evento ao banco de dados de eventos que reside no servidor. Os níveis de severidade e reações automáticas são definidos na Política de Eventos. Uma reação automática é o curso de ação imediato definido para um evento detectado. Por exemplo, um aviso automático por e-mail é enviado aos Administradores do sistema assim que um evento ocorre.
3. O cliente SmartEvent exibe os eventos recebidos. Ele apresenta todas as informações necessárias para o monitoramento em tempo real das investigações e correções de eventos de segurança. Os administradores também podem utilizar o cliente SmartEvent para gerar relatórios, ajustar e instalar a Política de Eventos.
SmartEvent Deployment
Os componentes do SmartEvent podem ser instalados em uma única máquina (uma implantação standalone) ou espalhados por várias máquinas e locais (uma implantação distribuída). Implementar um implantação distribuída é altamente recomendado se sua organização prevê um alto volume de atividade de registro.
Habilite o SmartEvent no Security Management Server ou habilite em um servidor dedicado. Você também pode instalar mais de um SmartEvent Correlation Unit. Cada um pode analisar o log de vários Log Servers ou Domain Log Servers. Os dispositivos SmartEvent dedicados da CheckPoint também estão disponíveis como uma opção ao implantar o SmartEvent em sua organização. Uma licença ou contrato válido é necessário para implementar o SmartEvent.
Antes da instalação, certifique-se de realizar as seguintes ações:
· Use um servidor dedicado para SmartEvent que esteja conectado a um servidor de gerenciamento.
· Faça uma instalação limpa.
· Desinstale o cliente SmartEvent antigo instalado nos computadores, antes de instalar o novo cliente.
· Conecte-se a um servidor de gerenciamento (Security Management Server ou Multi-Domain Server), versão R77.xx ou superior.
NOTA:
A CheckPoint recomenda configurar os parâmetros de gerenciamento de espaço em disco para excluir entradas de log antigas quando o espaço em disco disponível for de 45% ou menos. Essa configuração se aplica apenas aos arquivos de log brutos e não tem efeito no banco de dados de eventos, pois usa uma política de gerenciamento de espaço em disco interno.
Definindo a Rede Interna
Para ajudar o SmartEvent a determinar se os eventos são originados interna ou externamente, a rede interna deve ser definida nas configurações iniciais. Existem quatro opções para calcular a direção do tráfego:
· Incoming - Todos os soucers estão fora da rede e todos os destinos estão dentro.
· Outgoing - todas as fontes estão dentro da rede e todos os destinos estão fora.
· Internal - as origens e destinos estão todos dentro da rede.
· Outro - Uma mistura de valores internos e externos torna o resultado indeterminado.
NOTA:
Recomenda-se adicionar todos os objetos de rede internos, não objetos de host.
Adding Network and Host Objects
Certos objetos do servidor de gerenciamento são adicionados durante a sincronização inicial com o servidor SmartEvent e atualizados em um conjunto interno. No entanto, pode ser necessário ou útil adicionar outra rede ou objetos de host à rede interna, como:
· Se houver dispositivos ou redes não representados no servidor de gerenciamento que são importantes para definir a rede interna.
· Ao adicionar sources ou destinations a exclusões ou exceções no evento.
· Quando selecionando sources ou destinations em um filtro.
Identificando um Evento 
Um dos principais recursos do SmartEvent é a capacidade de identificar um possível incidente ou evento de segurança a partir da grande quantidade de registros que podem ser gerados em uma organização. Conforme mencionado anteriormente, os eventos são detectados pelo Correlation Unit. O Correlation Unit verifica os logs em busca de critérios que correspondam a uma definição de evento. SmartEvent usa os seguintes procedimentos para identificar eventos:
· Matching um log com exclusões globais
· Matching um log com cada definição de evento
· Criação de um candidato a evento
· Atualizando um evento
Matching um Log com as Exclusões Globais
Quando a Correlation Unit lê um log, Quando o Correlation Unitt lê um log, ele primeiro verifica se o log corresponde a alguma Global Exclusionl definida. Quando as Global Exclusion são definidas, elas direcionam o SmartEvent para ignorar os logs que não devem contribuir para um evento. Se um log corresponder a uma exclusão global, ele será descartado pelo sistema. Se não corresponder, o Correlation Unit começará a corresponder os logs a cada definição de evento.
Matching um Log com cada Definição de evento
Cada definição de evento contém um filtro que é composto de vários critérios que devem ser encontrados em qualquer log correspondente. Por sua vez, os critérios são divididos por produto. Isso significa que uma definição de evento pode incluir vários produtos diferentes, mas cada produto tem seus próprios critérios (conjunto de valores).
Por exemplo, para que um log URL Filtering corresponda à Event Definition A, ela deve corresponder aos valores de ação, tipo de evento, porta e protocolo listados na categoria URL Filtering. Um log do SecurityGateway deve corresponder aos valores listados em sua respectiva coluna. SmaerEvent divide este processo em duas etapas:
O Correlation Unit primeiro verifica ou não o valor do produto na figura abaixo, se o Log 1 não contiver um valor de produto aceitável, o Correlation Unit irá então comparar o log novamente na próxima Definição de Evento e assim por diante. Se o log não corresponder a nenhuma definição de evento, ele será descartado.
Em seguida, o Correlation Unit verifica se o log corresponde aos critérios específicos do produto em uma definição de evento. Por exemplo, a URL Filtering gera logs que envolvem o Firewall, spyware, proteção de código malicioso e outros, que são preenchidos no campo Event Type. Se um eventocorresponder aos registros de filtragem de URL envolvendo o Firewall, o registo de filtragem de URL envolvendo spyware falhará na definição de evento. Outros critérios também podem ser específicos ao Produto, como ação, porta e protocolo.
Event Definition Matching Log
Voltando ao exemplo, o Correlation Unit agora examina se o log contém os critérios necessários para que o log URL Filtering corresponda. Se os critérios não corresponderem, o Correlation Unit continuará comparando os critérios de log a outras definições de evento.
Criando um Evento Candidato
Assim que o log corresponder aos critérios, ele será adicionado a um Event Candidate. Os Event Candidate permitem que o SmartEvent rastreie os logs até que um limite de evento seja cruzado, momento em que um evento é gerado. Um limite de evento permite que os administradores do sistema definam os limites para que os logs se tornem um evento. Os limites geralmente são o número de conexões, logs ou falhas e o período de tempo em que ocorreram. Um exemplo de limite de evento seria: Detetar o evento quando mais de "x" conexões / logs / falhas forem detectadas em um período de "y" segundos.
NOTA:
· O Event Candidate pode rastrear múltiplos produtos CheckPoint e produtos não Checkpoint.
· Logs devem ser originados do mesmo endereço de IP de origem.
· O Event Candidate rastreia os logs após todos os critérios corresponderem.
Event Candidate 10.1.1.15
Cada definição de evento pode ter vários Event Candidates existentes simultaneamente para controlar os logs agrupados por propriedades semelhantes, como por host, serviço, destino ou qualquer combinação destes ou outros. Em nosso exemplo, todos os logs que formam o Event Candidate 10.1.1.5 têm um valor de origem comum e foram descartados, bloqueados ou rejeitados por um Firewall. Eles são agrupados porque a definição de evento é projetada para detetar atividade originada do endereço de origem 10.1.1.5.
Sempre que um log corresponde à definição do evento, mas possui propriedades diferentes daquelas dos Event Candidate existentes, um novo Event Candidate é criado e adicionado a um Pool de Event Candidate. SmartEvent cria um novo EventCandidate para um log com origem diferente.
Amostra do Event Candidate Pool
O Event Candidate Pool é um ambiente dinâmico, com novos logs sendo adicionados e outros logs sendo descartados quando excedem um limite de definição de evento.
Para ilustrar melhor, considere o evento definido para detetar uma alta taxa de conexões bloqueadas. O SmartEvent rastreia o número de conexões bloqueadas para cada Firewall e os logs do tráfego bloqueado em cada Firewall formam um Event Candidate. Quando o limite de logs de conexão bloqueados de qualquer Firewall é ultrapassado, esse Event Candidate se torna um evento.
Embora essa definição de evento crie um Event Candidate para cada Firewall monitorado, outras definições de evento podem criar muitos mais.
Amostra de um Event Candidate Pool com Múltiplos Candidatos
Updating an Event
Descobrir um evento não significa que o SmartEvent pare de rastrear os logs relacionados ao evento. Quando um candidato se torna um evento, o Correlation Unit encaminha o evento para o Event Database. O Correlation Unit continuará adicionando logs correspondentes ao evento enquanto eles continuarem a chegar, mesmo se um limite de evento for atingido. Manter o evento aberto condensa o que poderia aparecer como várias instâncias do mesmo evento para um e fornece informações precisas e atualizadas quanto ao horário de início e término do evento.
Monitorando a Rede
Os administradores podem usar o SmartConsole e o SmartView Monitor para monitorar a atividade da rede e identificar, analisar, e gerenciar os eventos de segurança.
Usando o SmartConsole Logs& Monitor
O SmartConsole incluí um catálogo de views e reports na sessão Logs & Monitor do GUI. Os Views e os Reports são customizáveis, permitindo que você exiba e reporte eventos e dados de maior importância na sua rede. Por exemplo, pode ser importante monitorar o tráfego na rede baseado em localização geográfica.
Com apenas alguns clicks, você pode facilmente mudar de uma visão de alto nível para uma visão de análise forense detalhada de atividade da rede. A opção de busca utilizando texto livre permite uma rápida análise de dados e identificar eventos de segurança.
SmartConsole > Logs & Monitor
Utilizando SmartView monitor
Use o SmartView Monitor para responder rapidamente a mudanças em gateways, túneis, usuários remotos e padrões de fluxo de tráfego e atividades de segurança. Por exemplo, funcionários remotos de uma organização relatam problemas para se conectar à rede. usando a visualização SmartView MonitorCounter, o administrador pode avaliar que há mais falhas de conexão do que sucesso. Um relatório pode ser criado para determinar o que está impedindo os funcionários de se conectar à rede.
O SmartView Monitor fornece visualizações gráficas em tempo real e históricas de:
· Status do gateway
· Remote Users
· System Counters
· VPN Tunnels
· Cooperative enforcement (para Endpoint Security Servers)
· Traffic
Sample System Counter View
Event Queries
Uma visualização é um painel interativo composto de widgets. Um widget pode exibir informações em diferentes formatos, como um gráfico ou uma tabela. Cada widget é a saída de uma consulta. Para revisar mais sobre um evento, clique duas vezes no widget para fazer uma busca detalhada em uma visualização mais específica dos arquivos de log brutos.
Exemplo de View
Queries são usados para definir os eventos a serem vistos. Essas consultas filtram e organizam os dados do evento para exibição. SmartConsole fornece um conjunto predefinido de consultas que são organizadas por combinações de propriedades de eventos. Por exemplo, um conjunto de consultas Threat Prevention incluirá eventos Threat Prevention, bem como eventos IPS.
As consultas de eventos podem ser personalizadas para exibir eventos específicos relacionados e passos definidos pela organização. Consultas de eventos personalizadas podem ser criadas do zero ou com base em uma consulta existente.
Os eventos são facilmente monitorados por meio de consultas personalizadas e predefinidas. Para ajudar a identificar padrões suspeitos, use os seguintes recursos para pesquisar e filtrar eventos:
· Filtros.
· Busca por texto livre utilizando operadores Boleanos, wildcards, campos, e ranges.
· Sugestões e pesquisas recentes.
· Período de tempo.
Investigando Eventos de Segurança
Para investigar melhor um evento, clique duas vezes no evento para abrir a janela Log Detail. A janela Log Details fornecerá informações importantes sobre o evento.
Janela de Detalhes de Logs.
Captura de Pacotes
Quando ativado, os arquivos de captura de pacote são enviados do Security Gateway para o Log Server junto com o log. O conteúdo da captura de pacotes fornece mais informações sobre o tráfego que gerou o log. Se algum registo tiver capturas de pacote relacionadas, abra um visualizador de pacote para ver o conteúdo do pacote capturado.
A captura de pacotes é ativada por padrão. Para ver uma captura de pacote, navegue até a visualização Logs & Monitor e abra o log. Clique no link no campo de captura de pacote e a janela Packet Capture Viewer Output será aberta. A captura do pacote pode ser salva em um arquivo para investigação posterior.
Custom Commands
O SmartEvent fornece uma maneira conveniente de executar executáveis de linha de comando comuns que podem ajudar na investigação de eventos. Clicar com o botão direito do mouse no endereço IP, origem ou destino, em um evento, fornece uma lista de comandos padrão e personalizados. Eles aparecem apenas em células que se referem a endereços IP, porque o endereço IP da célula ativa é usado como o destino do comando quando executado. Os comandos padrão são ping, whois, nslookup e Telnet.
Ping Output
Importando Arquivos de Log Offline
Os administradores do sistema podem importar e examinar logs de arquivos de log previamente gerados. Isto torna possívelrever ameaças a segurança e padrões de anomalias que ocorreram antes do SmartEvent ser instalado. Permite a investigação de ameaças, tais como scans não autorizados tendo como alvos hosts vulneráveis, ataques de denial of service (DDoS), anormalidades na rede e outras atividades baseadas em hosts.
O administrador pode rever logs de um período específico de tempo e focar em implementar recursos em ameaças que estiveram ativas por um período de tempo, mas podem ter sido perdidas. Por exemplo, novos eventos podem ter sido atualizados dinamicamente e agora podem ser processados em relação ao período anterior. 
Remediando Eventos de Segurança
Uma vez que um evento é identificado, investigado, e concluir-se ser uma ameaça, pode-se remediar o problema por:
· Configurar Event policy
· Configurar IPS policy
Configurando Event Policy
Use a guia Política do cliente SmartEvent GUI para configurar e personalizar os eventos que definem a política de eventos. Todos os eventos detectáveis pelo SmartEvent são organizados por categoria no ramo Event Policy.
Cada evento é habilitado ou desabilitado usando a caixa de seleção correspondente. Desmarcar a caixa de seleção ao lado de um evento remove esse tipo de evento da Event Policy na próxima vez que a Event Policy for instalada.
Dependendo do threshold definido em cada Event, o número de eventos detectados pode ser um tanto quanto alto. Ainda assim, somente uma porção destes eventos podem ser significantes.
A seleção de um evento exibe suas propriedades configuráveis no painel Detail e uma descrição do evento no painel Description. Para corrigir um evento de segurança, pode ser necessário ajustar ou configurar:
· Threshold
· Severity
· Reações automáticas
· Exceptions
· Working hours
Nem todos esses elementos aparecem para todos os eventos. Depois de instalar e executar o SmartEvent por um curto período, você descobrirá quais desses elementos precisam ser ajustados por evento.
Threshold
A configuração Threshold define os limites que, quando excedidos, indicam que um evento ocorreu. Os limites normalmente consistem em uma série de conexões, logs ou falhas e o período de tempo em que ocorreram.
Severity
A gravidade de um evento determina em quais consultas, entre aquelas que filtram por gravidade, esse tipo de evento aparecerá. os níveis de gravidade são:
· Informacional
· Low
· Medium
· High
· Critical
Reações Automáticas
Com a correção do início do salto, um evento após a deteção pode desencadear uma reação automática. Múltiplas reações automáticas podem ser configuradas, dependendo das necessidades do sistema. Por exemplo, uma única reação automática de mail pode ser definida para informar um responsável diferente para cada tipo de evento. As reações automáticas podem ser criadas em Configurações gerais.
Existem cinco tipos de reações automáticas:
· Mail - Alerta um Administrador de Sistema por email quando um determinado evento ocorre.
· Block Source - Instrue o Security Gateway a bloquear o(s) IP(s) de origem a partir do qual foram detectados eventos configurado por um período determinado de tempo.
· Block Event Activity - Instrue o Security Gateway a bloquear um ataque distribuído originado de múltiplas fontes, ou ataques a múltiplos destinos por um período determinado de tempo.
· External Script - Executa um script.
· SNMP Trap - Gera um SNMP Trap.
Exceções
As exceções permitem que um evento seja configurado de forma independente para as origens ou destinos que aparecem. Por exemplo, se o evento Port Scan da Rede Interna estiver definido para detetar um evento quando 30 conexões tiverem ocorrido em 60 segundos, defina que duas varreduras de portas detetadas no host A dentro de 10 segundos uma da outra também são um evento.
Working hours
O horário de trabalho é usado para detetar tentativas não autorizadas de acessar sistemas protegidos e outras operações proibidas após o expediente. Para definir Horas de trabalho regulares para um evento, selecione um objeto Hora no menu suspenso. Os objetos de tempo são configurados em Configurações gerais.
Configurando Políticas de IPS
A proteção IPS e os perfis devem ser revisados para entender por que um evento foi gerado. Os administradores também podem revisar os eventos para investigar como o tráfego é tratado pelo IPS. Qualquer evento gerado pelo IPS Software Blade é facilmente investigado e corrigido através da janela Event Detail. Na janela Event Details, você pode:
· Vá para o artigo Consultivo da CheckPoint, que fornece informações básicas sobre a proteção IPS.
· Revise uma descrição detalhada da proteção IPS.
· Adicione uma exceção à proteção IPS.
Reportando Eventos de Segurança
Os relatórios facilitam a geração, revisão e compartilhamento rápido de dados de segurança usando gráficos e tabelas de dados. Eles fornecem informações mais detalhadas do que uma visualização. Relatórios predefinidos e personalizados podem ser gerados para fornecer informações de segurança em uma programação (diária, semanal ou mensal) ou conforme necessário. Por exemplo, um executivo pode solicitar um resumo mensal de segurança sobre as tendências de segurança mais recentes para avaliar a política e os procedimentos da empresa, como permitir que os funcionários acessem determinados sites e aplicativos durante o horário de trabalho.
Exemplo de Report
Usando Reports Pré-definidos
Use modelos de relatórios gráficos predefinidos para os problemas de segurança vistos com mais frequência. Para abrir o catálogo de relatórios predefinidos e personalizados, clique na guia [+]. Clique duas vezes em um relatório para abri-lo. O SmartEvent baixa automaticamente novos relatórios predefinidos e atualiza os relatórios existentes.
Lista de Reports
Importando e Exportando Reports
A opção Export to PDF e Export to Excel permite que você salve o repor corrente como arquivo PDF ou Excel, baseado nos filtros de tempo e período de tempo definidos. 
Layout de relatório e modelos de definição de widget também podem ser exportados. Similarmente, a opção Import Template permite que você importe estes arquivos de template de outro servidor, ou de outro administrador.
Adicionando um Logo aos Reports
Por padrão, o logotipo CehckPoint é exibido nas páginas de rosto do relatório. Os administradores do sistema podem configurar relatórios para mostrar o logotipo de sua empresa. Salve a imagem no diretório $RTDIR/smartview/conf no servidor SmartEvent.
Definindo Reports Customizados
Como cada empresa é diferente uma da outra, SmartEvent ajuda os Administradores de Sistema a criar reports customizados para “encaixar” na respetiva organização. Para customizar um report, selecione um report pé-definido ou crie um totalmente customizado, em seguida click em Edit para definir o novo report.
Definindo Esboço e Filtros do Report
A área de trabalho mostra Views à esquerda quando você edita um relatório. Uma visualização é um painel interativo composto de widgets. Também é uma secção do relatório mostrada na página ou em várias páginas, se incluir uma tabela. O painel Views possui controles de gerenciamento que ajudam a adicionar, remover, alterar a sequência de visualizações e até adicionar filtros para os dados incluídos no relatório.
As alterações nas visualizações são aplicadas apenas ao relatório personalizado no qual você está trabalhando.
Definindo Views
Quando você clica em uma determinada View thumbnail, ele mostra os widgets incluídos nessa visualização. Um widget é uma representação dos dados coletados. Cada widget está contido em um painel com opções de gerenciamento que permitem adicionar, remover, mover ou redimensionar um widget. Observe que não é possível mover ou redimensionar o widget para fora das bordas da página. Para layouts de tabela que se expandem para várias páginas, selecione Show all table rows na janela Split Table across multiple pages na opção View Settings.
NOTA:
A visualização gráfica desejada da postura de segurança da sua organização pode ser rapidamente customizada adicionando um widget a umavisualização. Antes de adicionar um widget, certifique-se de que a visualização tenha espaço suficiente; caso contrário, uma mensagem de erro aparecerá.
Filtrando reports por grupos de Usuários
Os administradores de sistema podem precisar gerar vários relatórios para diferentes interessados principais. A média de um relatório para um executivo de nível C pode conter informações não relevantes para um chefe de departamento. Relatórios, visualizações e widgets podem ser filtrados para um ou mais grupos de usuários Active Directory.
Antes de habilitar este recurso, um objeto Função de Acesso que inclui os grupos AD a serem usados na consulta do relatório deve ser definido. Para filtrar relatórios para grupos de uso específicos, observe os logs de login de reconhecimento de identidade e copie os nomes do grupo relevante. Adicione um filtro para o campo User Group e insira o nome do grupo a ser incluído no filtro. Para vários grupos, use uma lista separada por vírgulas.
Medidas Preventivas
Depois de remediar eventos de segurança, medidas preventivas podem ser colocadas em prática para assegurar que um evento seja endereçado tão logo seja possível e prevenir a repetição de uma ocorrência.
Criando uma Nova Definição de Evento
Assim que uma nova ameaça for descoberta e corrigida, tome uma ação preventiva criando uma nova definição de evento. Na próxima vez que esse padrão de ameaça for detectado, ele criará um evento no Banco de dados de eventos, permitindo que seja abordado e corrigido mais rapidamente. O Event Definition Wizard facilita a configuração de uma nova definição de evento do zero ou com base em um evento existente.
Event Definition Wizard
Ao criar uma nova definição, o Event Definition Wizard permite que você escolha se um evento será gerado quando uma definição de evento for correspondida por um único log ou vários logs. Também oferece opções para escolher quais produtos podem acionar um evento. Todas as definições de eventos definidas pelo usuário são salvas automaticamente na pasta User Defined Events na Selection Tree.
.Reporting an Event to CheckPoint
Relatar dados de eventos ao Checkpoint pode ajudar a ChekPoint a melhorar a tecnologia IPS para detetar novas ameaças. Apenas as informações do evento serão enviadas ao Checkpoint por meio de uma conexão SSL segura. Os dados são mantidos em sigilo e a CheckPoint apenas usa as informações para melhorar o IPS.
Report Event to Checkpoint
Eliminando Falsos Positivos
Para eliminar falsos positivos, é importante entender como um falso positivo pode ser gerado. Certos tipos de serviços são caracterizados por uma grande quantidade de tráfego que pode ser identificada incorretamente como eventos. A seguir estão exemplos de serviços e protocolos que podem gerar eventos.
· Software que realiza uma varredura de rotina da rede para garantir que tudo esteja funcionando corretamente.
· Uma alta taxa de conexão em um servidor da web. O SmartEvent deve ser configurado para permitir uma taxa de conexão mais alta por minuto em um servidor da web ocupado ou para excluir esta fonte de um evento de varredura.
Consulte o CheckPoint Logging and Monitoring Administration Guide para uma lista de tipos de servidores onde a alta taxa de conexão é comum. Modifique a política de eventos ajustando os limites de eventos e adicionando exclusões para servidores e serviços, para reduzir ainda mais a quantidade de positivos falsos detectados.
Para eliminar falsos positivos, altere os limites e outros critérios de um evento. Por exemplo, aumente o número de conexões, logs ou falhas e/ou o período de tempo para que ocorram.
Ambiente de Alta Disponibilidade (HighAvailability Environment)
O banco de dados do SmartEvent mantém uma cópia sincronizada dos objetos de gerenciamento localmente no Smart Event Server. Este processo, também conhecido como dbsync, permite que o SmartEvent funcione independentemente de diferentes versões de gerenciamento e diferentes servidores de gerenciamento em ambiente High Availability.
Management High Availability existe para Security Management Servers e em um ambiente Multi-Domain Security Management. O processo dbsync suporta alta disponibilidade para os servidores Multi-Domain e os servidores Domain.
O processo dbsync conecta-se inicialmente ao Management Server (SMS) com o qual o SIC está estabelecido. Ele recupera todos os objetos e, após a sincronização iniciada, obtém atualizações sempre que um objeto é salvo. Nesse ponto, o dbsync regista todas as máquinas de gerenciamento High Availability e testa periodicamente a conectividade com o servidor de gerenciamento atual. Se a conectividade for perdida, ele tentará se conectar aos outros servidores de gerenciamento de High Availability até encontrar um servidor ativo e se conectar a ele.
Se dois servidores de gerenciamento estiverem ativos simultaneamente, o dbsync permanecerá conectado somente a um e não receberá nenhuma alteração feita no outro servidor de gerenciamento até que uma operação de sincronização seja executada.
SmartEvent Correlation Unit High Availability
Várias unidades de correlação podem ler registros dos mesmos servidores de registro, fornecendo redundância se um deles falhar. Os eventos detectados pelos Correlation Units serão duplicados no banco de dados do SmartEvent. Esses eventos podem ser verificados filtrando com o campo Detected By na definição Event Query. O campo Detect By especifica qual Correlation Unit detetou o evento. O servidor SmartEvent fica indisponível, os Correlation Units retêm os eventos até que possam se reconectar ao SmartEvent Server e encaminhar os eventos.
Security Checkup
Com as ferramentas CheckPoint Security CheckUp, os administradores podem gerar um relatório de análise de segurança abrangente que resume os eventos de segurança, seus riscos e remediação. Esses relatórios são usados principalmente para fins de Proof of Concept (PoC). O Security CheckUp organiza dados de segurança para exibir informações importantes e relatórios de análise de ameaças que geram gráficos e organizam dados de segurança para exibir descobertas importantes sobre malware, ataques, perda de dados e acesso à web de alto risco. O SmartEvent deve ser ativado antes de executar os relatórios Security CheckUp e a ferramenta é instalada como suplemento. A diferença entre os relatórios do SmartEvent e os relatórios Security CheckUp é que o relatório do Anonymizer não usa endereços IP ou nomes de usuário.
Cada relatório pode ser localizado em qualquer idioma e personalizado para exibir informações de um período de tempo específico ou preferências de filtro. Como outros relatórios, os relatórios do Security CheckUp podem ser gerados de acordo com a programação ou conforme a necessidade e salvos como um arquivo PDF ou Excel para fins de compartilhamento de informações e investigação de eventos de segurança.
Security Checkup Report
Remote and Mobile Access
Escolhendo Solução Remote Access 
Todas as soluções CheckPoint Remote Access fornecem conectividade segura para recursos corporativos. Métodos fortes de autenticação de usuário e controle de acesso granular reforçam a segurança da rede. As soluções CheckPoint Remote Access usam os protocolos de criptografia IPSec e Secure Socket Layer (SSL) para criar conexões seguras. Todos os clientes CheckPoint podem trabalhar por meio de dispositivos NAT, hotspots e proxies em situações com topologias complexas, como aeroportos ou hotéis.
Existem alguns fatores a serem considerados ao escolher soluções de acesso remoto para sua organização:
· Client-Based ou Clientless: A solução requer que um cliente Checkpoint seja instalado no computador do endpoint ou não tem cliente, para o qual apenas um criador da web é necessário? Várias soluções podem ser necessárias em sua organização para atender a diferentes necessidades.
· Secure Connectivity ou EndPoint Security: A solução requer apenas conectividade segura, enquanto o tráfego é criptografado entre o cliente e o gateway VPN, ou segurança de endpoint que forneceproteção mesmo quando não há conectividade com a rede?
· VPN SSL versus VPN IPSec: Sua organização precisa de um túnel VPN completo para proteger o acesso de qualquer aplicativo instalado ao negócio ou precisa de um portal de negócios mais simples para acesso seguro?
Tipos de Instalação
Existem três tipos de instalações para soluções de acesso remoto:
· Client-Based - nesta solução, o aplicativo cliente é instalado em computadores. Os clientes geralmente são instalados em um dispositivo gerenciado, como computadores ou dispositivos da empresa. O cliente fornece acesso à maioria dos tipos de recursos corporativos de acordo com os privilégios de acesso do usuário.
· Clientless - nesta solução, os usuários se conectam por meio de um navegador da web e usam conexões HTTPS em vez de se conectar por meio de um dispositivo gerenciado. As soluções Clientless geralmente fornecem acesso a recursos corporativos baseados na web.
· On Demand Client - Esta solução de acesso remoto combina as duas primeiras opções. Um usuário se conecta a um navegador da web e instala um cliente quando necessário. O cliente fornece privilégios de acesso à maioria dos tipos de recursos corporativos de acordo com os privilégios de acesso do usuário.
Secure Connectivity e Endpoint Security
Conexões seguras podem ser combinada com recursos adicionais para proteger a rede ou os computadores terminais. Com a conectividade segura, o tráfego é criptografado entre o cliente e o gateway VPN e há suporte para autenticação forte do usuário. Após a autenticação dos usuários, eles podem acessar os recursos corporativos que são permitidos a eles na política de acesso. Todas as soluções de acesso remoto da CheckPoint oferecem conectividade segura e exigem licenças.
A verificação de segurança para computador endpoint garante que os dispositivos conectados ao portal atendam aos requisitos de segurança. As máquinas de endpoint que não estão em conformidade com a Política de Segurança têm conectividade limitada ou nenhuma conectividade com recursos corporativos. Algumas soluções de Checkpoint fornecem isso.
Em termos de Endpoint Security, os computadores de endpoint estão protegidos o tempo todo, mesmo quando não há conectividade com a rede corporativa. Um firewall integrado para desktop e protege computadores terminais em todos os momentos com uma política de segurança gerenciada centralmente. Isso é importante porque os clientes remotos não estão na rede protegida e o tráfego para os clientes só é inspecionado se um firewall de desktop estiver presente. Algumas soluções da CheckPoint fornecem isso. Essas soluções requerem licenças com base no número de clientes instalados.
NOTA:
As soluções CheckPoint podem incluir mais recursos do Endpoint Security, como Anti-Malware e criptografia de disco.
SSL VPN versus IPSec (Layer 3) VPN
As soluções da CheckPoint fornecem acesso de nível empresarial por meio de Layer 3 (IPSec) e SSL VPN. Há uma diferença fundamental em como um portal SSL VPN e um túnel VPN Layer 3 se conectam à rede corporativa. Em uma solução VPN Layer 3, é necessário um cliente VPN residente, que cria a interface virtual de Layer 3 que qualquer aplicativo pode usar. As soluções SSL VPN requerem apenas um navegador do lado do cliente e permitem que dispositivos móveis com um aplicativo dedicado acessem recursos corporativos sem estabelecer um túnel VPN.
Layer 3 VPN versus SSL VPN
Em uma solução SSL VPN, os usuários podem se conectar com segurança a aplicativos empresariais baseados na web (web-based) por meio de um portal da web (web portal). Esta solução não requer que os usuários instalem um cliente VPN. SSL VPN é a solução recomendada para dispositivos pessoais e não gerenciados usados para fins comerciais.
As soluções VPN Layer3 exigem que os funcionários remotos instalem um cliente VPN antes de obter acesso aos recursos corporativos. Depois que um usuário instala o cliente, o túnel VPN Layer 3 fornece uma conexão segura para aplicativos de negócios nativos e baseados na web. Isso é recomendado para empresas com funcionários que usam dispositivos gerenciados ou não gerenciados.
Ambas as soluções podem ser configuradas para impor autenticação de dois fatores.
Clients
Todas as opções de Remote Access proveem acesso remoto seguro aos recursos corporativos. Cada um tem diferentes recursos e possuem diferentes requisitos organizacionais.
 Mobile Access Portal
O Mobile Access Portal, uma solução VPN SSL clientless, é recomendado para usuários que desejam acessar recursos corporativos de qualquer computador ou dispositivo não gerenciado. Esta solução não requer que os usuários instalem um agente ou cliente VPN. O Mobile Access Portal fornece conectividade segura e verificação de segurança. Requer uma licença Mobile Access Software Blade configurada para esse Security Gateway. A política Mobile Access se aplica ao Mobile Access Portal. O portal também pode ser usado com dispositivos gerenciados.
O Mobile Access Portal fornece acesso a recursos corporativos baseados na web. O cliente sob demanda, SSL Network Extender, pode ser usado para acessar todos os tipos de recursos corporativos.
NOTA:
Cada Security Gateway habilitado com Mobile Access leva ao seu próprio portal Mobile Access User. Pode-se configurar a URL no Mobile Access First Time Wizard. Para personalização do portal, os administradores do sistema podem ir para Portal Customization em Mobile Access no SmartConsole.
SSL Network Extender
SSL Network Extender (SNX) é um thin SSL VPN sob demanda cliente que é instalado automaticamente na máquina do usuário remoto por meio de um navegador da web. Este cliente VPN é instalado como um plug-in de navegador. Depois de instalado, ele permite uma conexão segura usando o túnel SSl VPN para conectar usuários a recursos corporativos. SSL Network Extender requer licenças Mobile Access e IPSec VPN Software Blades no Security Gateway.
SSL Network Extender tem dois modos:
Network - os usuários podem acessar todos os aplicativos baseados em IP e em web na rede interna. Para que os usuários obtenham acesso a esses aplicativos, os administradores do sistema devem primeiro defini-los como aplicativos nativos no Mobile Access. O usuário pode acessar os recursos iniciando o cliente a partir do desktop ou do Portal Mobile Access. Para trabalhar no modo de rede, os usuários devem ter privilégios de instalação.
Apppication - os usuários podem acessar a maioria dos tipos de aplicativos baseados em web baseados em IP nativos na rede interna, incluindo a maioria dos aplicativos TCP. Os usuários só podem iniciar o cliente no portal Mobile Access. Depois de instalados, os usuários podem acessar recursos internos definidos como aplicativos nativos no Mobile Access. Trabalhar no modo de aplicativo não requer privilégios de instalação.
CheckPoint Mobile
CheckPoint Mobile oferece uma opção de acesso remoto para várias plataformas diferentes.
· CheckPoint Mobile for Windows - Uma solução de cliente VPN IPSec para empresas de médio a grande porte que não exigem Endpoint Security Policy. Ele fornece conectividade segura e verificação de segurança. Esta opção requer licenças IPSec VPN e Mobile Access Software Blade.
· Checkpoint Mobile para Iphone e Ipad - um cliente SSL VPN que fornece conectividade segura e acesso a recursos corporativos baseados na web e Exchange Active Sync. Esta opção é melhor usada para trabalhadores remotos que possuem dispositivos móveis iOS. Uma licença Mobile Software Blade é necessária para esta opção.
· CheckPoint Mobile para Android - Um cliente SSL VPN para usuários de sistema Android. Ele fornece conectividade segura e acesso a recursos corporativos baseados na web e Exange Active Sync. Uma licença Mobile Software Blade é necessária para esta opção.
CheckPoint Capsule Workspace
Capsule Workspace é um cliente SSL VPN para dispositivos móveis que fornece aos usuários remotos acesso contínuo a um ambiente de negócios seguro e separado. Uma licença Check Point Capsule é necessária no Security Gateway. 
SecuRemoteSecuRemote é um cliente IPSec VPN de função limitada que fornece apenas conectividade segura, SecureRomote é um cliente gratuito e requer apenas uma licença IPSec VPN Software Blade no Security Gateway.
Opções Remote Access Adicionais
CheckPoint oferece opções adicionais de Remote Access, incluindo especificamente para Endpoint Security. Para obter mais informações detalhadas sobre a solução e opções do RemoteAccess, consulte SK678020.
CheckPoint Capsule
O CheckPoint Capsule atende às necessidades de acesso móvel protegendo com segurança os dispositivos contra ameaças e protegendo documentos comerciais onde quer que estejam, ao mesmo tempo em que fornece um ambiente comercial seguro para dispositivos móveis.
O CheckPoint Capsule protege a comunicação remota e troca de dados usando três componentes: Capsule Workspace, Capsule Docs e Capsule Cloud.
Capsule Workspace
Usando o Capsule Workspace, os usuários móveis recebem um login seguro com fácil acesso a aplicações de negócios e documentos. Esta solução permite que funcionários trabalhem remotamente e se conectarem com segurança à rede e usar e armazenar facilmente dados e documentos de negócios dentro do contêiner de segurança do aplicativo. Os usuários têm acesso a e-mail corporativo, arquivos, diretórios, contactos corporativos e calendários. O Capsule Workspace permite que os funcionários da empresa usem seus dispositivos pessoais para tarefas relacionadas ao trabalho e, ao mesmo tempo, coloquem apenas os dados da empresa sob controle da equipe de TI corporativa. Com a integração do Capsule Docs e uma senha no nível do aplicativo, os dados corporativos são protegidos em qualquer lugar. O Capsule Workspace também oferece criptografia de dados off-line, política e limpeza remota e controle de compartilhamento. Com o Capsule Workspace, as organizações podem aumentar a produtividade dos funcionários e, ao mesmo tempo, proteger o uso de dispositivos pessoais e dados corporativos.
Os principais benefícios incluem:
· Um aplicativo é usado para acessar informações comerciais, fornecendo segregação entre pessoais e profissionais no dispositivo.
· oferece uma ótima experiência ao usuário final com notificações push, editor de documentos, HTML5 e muito mais.
· Fornece uma solução ponta a ponta sem comprometer a segurança, do Microsoft Exchange ao dispositivo móvel.
Capsule Connect
O Capsule Connect complementa o Capsule Workspace para prover acesso a aplicações nativas.
Os principais benefícios incluem:
· Cliente completo para VPN Layer 3
· Funciona no background
· On Demand (iOS) / Sempre ativo (Android)
· Suporta todos os métodos de autenticação VPN
· Infraestrutura para Capsule Cloud
O cenário típico de usuários incluí:
· Aplicações corporativas usando aplicativos nativos
· Soluções Remote Desktop não-HTML5
· Mail corporativo usando clientes Nativos.
Como Capsule Connect e o Capsule Workspace Diferem
Ambos, Capsule Connect e Capsule Workspace oferecem conexão segura para usuários remotos que utilizam seus dispositivos móveis. Entretanto, existem diferenças entre os dois.
Comparação do Capsule Connect e Capsule Workspace
Capsule Docs
O aumento da colaboração do usuário e das plataformas de compartilhamento de arquivos pode levar a problemas de segurança, como roubo de informações e vazamento de dados. Capsule Docs Evita esses problemas, protegendo o documento real com os seguintes recursos:
· Classificar - Defina um conjunto de permissões, que pode incluir marcações como cabeçalhos, rodapés e marcas d'água.
· Compartilhar - Decida com quem compartilhar o documento.
· Criptografar - Aplicar criptografia (AES256 + RSA2048) ao documento para que seja protegido e acessado apenas por usuários e grupos autorizados.
Classificação de Documentos no Capsule Docs
Uma vez que os arquivos estão protegidos, o usuário pode armazenar o documento em qualquer lugar e compartilhá-lo em diferentes plataformas. Capsule Docs protege o conteúdo do documento, independentemente de onde ele é mantido ou com quem é compartilhado. No caso de um invasor obter o documento, o conteúdo do documento é criptografado e não pode ser acessado por usuários não autorizados.
O Capsule Docs não exige que os usuários tenham uma senha adicional porque usa credenciais do Active Directory para autenticação.
Os usuários e administradores de sistema podem compartilhar um documento com um usuário externo, adicionando o endereço de e-mail do destinatário à lista de usuários autorizados na primeira tentativa de acessar o documento, o usuário externo será solicitado a instalar um cliente editor ou viewer e se registrar o sistema. Este registo é rápido e requerido apenas uma vez.
Criptografia de Conteúdo
O conteúdo é criptografado com chave simétrica. AES 256 é usado para um implementação local e AES 128 é usado para um implementação na nuvem. O Content Encryption Key é gerado pelo cliente e criptografado com chaves assimétricas geradas pelo servidor de gerenciamento. O Content Encryption Key pode ser acessado com um dos seguintes:
· Chave Mestra (RSA 2048)
· Chave de Classificação (RSA 2048) e User/Group key (RSA 2048)
Implementação Cloud 
Capsule Docs na Nuvem é a melhor opção para organizações que preferem não implantar um servidor adicional. Nesta configuração, a nuvem armazena chaves de criptografia da comunidade, usuários, políticas, configurações e registros de auditoria. O LDAP é usado para gerenciar usuários em uma implantação em nuvem. o registo do usuário é feito através do Capsule Web Portal e a autenticação é feita no LDAP.
Implementação na Nuvem
Capsule Cloud
Capsule Cloud utiliza solução CheckPoint Sftware Blade como um serviço baseado na nuvem.
Capsule Cloud aplica a Security Policy dentro da rede da organização para dispositivos internos e externos. Ajuda a empresa a proteger os funcionários que usam laptops e dispositivos móveis quando estão fora do ambiente seguro do escritório. Esta é a melhor opção para organizações com vários escritórios satélite e filiais remotas. Para empresas menores e usuários individuais, o cliente Capsule Connect pode ser instalado em seus dispositivos para se conectar ao Capsule Cloud para segurança.
Para proteger a comunicação entre os locais, qualquer tráfego de rede vindo de e indo para dispositivos remotos é direcionado para a Capsule Cloud por meio de um túnel seguro. O Capsule Cloud inspeciona o tráfego com base nas Security Policies implementadas pelo escritório corporativo. Capsule Cloud emprega soluções de segurança CheckPoint, como Anti-Bot, Anti-Virus, Application Control, IPS e URL Filter.
A conexão de um gateway à Capsule Cloud é mais eficiente em comparação com a instalação das políticas localmente, pois essa configuração requer menos recursos da máquina. Security Gateways com recursos limitados também podem acessar e empregar mais blades no CheckPoint Capsule Cloud.
Cloud Portal
Os administradores podem gerenciar e aplicar políticas para dispositivos locais ou externos usando o SmartConsole ou a interface de usuário da web da Capsule Cloud. Cloud Portal é o Capsule Cloud WebUI. Use o portal da nuvem para:
· Configure políticas de URL Filtering, Threat Prevention e inspeção HTTPS
ver o tráfego do usuário e registros de auditoria.
· ver o tráfego do usuário e registros de auditoria
· Gerenciar usuários e escritórios
· Baixar os aplicativos e utilitários da Capsule Cloud.
· Alterar as configurações do cliente e do dispositivo
· Acessar utilitários da Capsule Cloud
· Determinar a localização de clientes em roaming (por meio do recurso Location Awarenessl)
Os administradores de rede com acesso ao Portal da nuvem podem ter privilégios de acesso de Administrador ou Help Desk. Os administradores com privilégios de administrador podem visualizar todas as guias e realizar operações no Portal da nuvem, enquanto aqueles com direitos de Help Desk só têm permissão para gerenciar usuários e dispositivos. Escritórios são gateways corporativos que se conectam à Capsule Cloud por meio de uma VPN. O gatewayencaminha o tráfego para a nuvem Capsule, onde o tráfego é inspecionado com base nas Security Policies aplicadas.
Para conectar um dispositivo ao Capsule Cloud, você deve criar uma comunidade VPN Site-to-Site entre os dois. O New Office Wizard irá ajudá-lo a configurar esta comunidade no Portal da Nuvem e a gestão do gateway local.
O recurso Location Awareness dá aos administradores a opção de limitar o acesso a usuários externos da Capsule Cloud. Nesta opção, os usuários com endereço IP ou domínios e portas na rede interna não serão capazes de se conectar ao Capsule Cloud.
Capsule Cloud - Location Awareness
Mobile Access Software Blade
O ambiente de negócios atual pode exigir que funcionários, contratados e outros profissionais do conhecimento acessem recursos corporativos de locais remotos. Sem as medidas de segurança adequadas, você corre o risco de perda de credencial, acesso não autorizado, perda e vazamento de dados, invasão e proliferação de malware e muito mais.
O CheckPoint Mobile Access Software Blade é uma solução abrangente de acesso remoto que permite que trabalhadores móveis e remotos se conectem com facilidade e segurança à rede corporativa de qualquer local, com qualquer dispositivo compatível, enquanto protege a rede, usuários remotos e dispositivos móveis contra ameaças.
Este Software Blade se integra a um gateway CheckPoint existente, permitindo um acesso remoto mais seguro e operacionalmente eficiente para seus usuários. Os dados transmitidos por acesso remoto são descriptografados, filtrados e inspecionados em tempo real pelos serviços de segurança de gateway da CheckPoint. Ele aplica os protocolos Secure Socket Layer (SSL) e IPSec (também conhecido como Layer3) VPN a conexões remotas para garantir que a comunicação e os dados sejam criptografados.
O Mobile Access Software Blade também fornece autenticação do usuário e a capacidade de verificar a postura de segurança do dispositivo remoto. Isso fortalece ainda mais a segurança para acesso remoto. A solução Mobile Access também garante autenticidade usando métodos de autenticação padrão, como Certificados, RADIUS, SecurID e Dynamic ID para transferir informações e dados.
Mobile Access Wizard
Ao habilitar o Mobile Access Software Blade em um gateway, o Mobile Access Wizard o guiará pelas diferentes definições de configuração. Ele também permite que usuários remotos autorizados acessem aplicações web internas por meio de um navegador web, dispositivo móvel ou cliente de acesso remoto. O Mobile Access Wizard ajuda a definir configurações como os métodos de acesso móvel, o URL principal do Mobile Access Portal e as autenticações que estarão disponíveis para usuários da web ou de dispositivos móveis.
NOTA:
Uma vez que o Mobile Access está habilitado, ele usa HTTPS 443. Esta é a mesma porta SSL do portal Web Gaia. Para evitar conflito, altere a porta do portal Web Gaia para uma porta diferente, por exemplo a porta TCP 4434, e adicione uma regra de acesso à política do Firewall para permitir a nova porta.
Mobile Access Methods
A sessão do wizard do Mobile Access Methods permite que você selecione de onde os usuários podem acessar as aplicações Mobile Access:
· Web - Através de um navegador de qualquer computador. O SSL Extender (SNX) pode ser baixado pelos usuários quando necessário para acessar aplicações nativas.
· Dispositivos Móveis - A partir de dispositivos iOS ou Android. Os dispositivos devem ter a aplicação CheckPoint instalada.
· Capusle Workspace - Através do contêiner seguro no dispositivo móvel para dar acesso aos usuários aos websites internos, compartilhamento de de arquivos e servidores Exchange.
· Capsule Connect/VPN - Através de um aplicativo de túnel Layer3 completo que dá aos usuários acesso à rede para todos os aplicativos móveis.
· Desktops/Laptops - Clientes CheckPoint para PCs e Macs que utilizam um túnel Layer 3 para prover acesso a recursos da rede interna.
Web Portal
O URL principal do Mobile Access Portal precisará ser especificado. O padrão é https://<endereço IP do gateway>/sslvpn. É possível usar o mesmo endereço IP para todos os portais no gateway com variação no caminho. Um arquivo PFX (.p12) pode ser importado para obter um certificado confiável. um PFX é o formato combinado que contém a chave privada e o certificado. Todos os portais no mesmo endereço IP usarão o mesmo certificado.
Applications
O Mobile Access fornece ao usuário remoto acesso a vários aplicações corporativas. O assistente permite que você selecione as aplicações que estarão disponíveis para usuários da web ou de dispositivos móveis:
· Aplicações Web - Selecione as aplicações Web que os usuários poderão acessar. As aplicações serão exibidas no portal Mobile Access. As opções de aplicação inculem: 
· Aplicação Web Demo (World Clock) - Enquanto estiver testando o Mobile Access, selecione esta opção para ter uma aplicação web que será exibida da mesma forma de quando estiver em produção.
· Aplicação Web Customizada - Especifique um URL personalizado como a página de destino para os usuários que se conectam ao MobileAccess. Por exemplo, o URL pode ser a página inicial do site da intranet da sua empresa.
· Mail/Calendar/Contacts - Especifique os detalhes de seu Exchange Server e os aplicativos de e-mail/calendário/contatos existentes que seus usuários móveis podem acessar. As opções incluem CapsuleWorkspaceMail, aplicativções ActiveSync e aplicações Outlook Web. 
· Compartilhamento de Arquivo - Cria e configura aplicações de compartilhamento de arquivos usando o protocolo Windows Common Internet File System (CIFS).
· Serviços Citrix - Selecione para incluir aplicações nativas suportadas pelos serviços Citrix. Mobile Access Suporta conectividade do cliente Citrix aos servidores XenApp internos.
· Apps nativos - Aplicações nativas são aplicações baseadas em IP que são hospedados em servidores dentro da organização. Selecione para especificar o caminho para um executável existente, tal como MS Remote Desktop, Telnet, e FTP.
Integração com Active Directory (AD)
Se escolher usar Active Directory (AD) ao habilitar o Mobile Access Software Blade, selecione o domínio AD, insira suas credenciais e teste a conectividade. Caso contrário, selecione “I don't want to use activedirectory now.”
Mobile Access Workflow
O Mobile Access permite que os usuários se conectem com segurança as aplicações e dados da empresa. Abaixo está um exemplo de um fluxo de trabalho de alto nível para configurar o acesso a aplicações internas.
1. Habilite a Mobile Access Software Blade no Security Gateway usando o SmartConsole.
2. Siga os passos do Mobile Access Wizard para as definições de configuração.
3. Adicione regras de Firewall para permitir conexões de dispositivos móveis.
4. Cier e distribua certificados para autenticação de usuário mobile usando o Cerificate Creation and Distribution Wizard. Você pode pular este passo se você não estiver usando certificados como método de autenticação.
5. O usuário final baixa uma solução de endpoint, tal como a aplicação Capsule Workspace. 
6. O usuário abre a aplicação (no exemplo, Capsule Workspace) e entra o nome do site do Mobile Access e a autenticação requerida.
Exemplo do Workflow do Mobile Access
User Authentication
Os métodos de autenticação a seguir são usados para o Mobile Access:
· Certificdo ( Internal ou External Certificate Authority)
· RADIUS Server
· SecurID
· Username e Password ( interno, LDAP)
· Dynamic ID One-Time password (OTP)
Janela de Fator de Autenticação
NOTA:
Um certificado só pode ser usado como primeiro método de autenticação. O DynamicID não pode ser usado como primeiro método de autenticação.
Autenticação pode ser configurada em Security Gateways pre-R80 em um destes dois lugares:
· Na janela Gateway Properties do gateway em MobileAccess> Authentication: Selecione o método que todos os usuários devem usar para se autenticar no Mobile Access. O método de autenticação padrão é Username and Password. As configurações para autenticação de dois fatores com DynamicIDOTP também podem ser definidas aqui.
· Na janela Gateway Porperties de um gateway em Legacy Authentication: o método de autenticação padrão é Certificado do ICA.
· Nos Security Gateways com R80.10 mais recente, os administradores podem configurar várias opções de login. A opção de login pode ser diferente para cada gateway e cada Software Blade com um cliente compatível. Para obter mais informações sobre quais clientes Mobile Access suportam várias opções de login, consulte SK111583.
Recursos de Segurança do Gateway
Lado do Servidor
Uma vez ativado no Security Gateway, o Mobile Access Software Blade oferece uma conexão segura, fornecendo medidas de segurança no servidor e no cliente.
O Mobile Access usa IPS Web Intelligence para proteger a rede de ameaças e ataques relacionados à web, incluindo códigos maliciosos ocultos em aplicações baseados na web e injeção suspeita de SQL. Ele também verifica arquivos, como documentos e executáveis, usando o a Blade de Antivirus.
Com o Mobile Access habilitado, os administradores selecionam as aplicações nativas e baseadas na web que podem ser acessados ​por usuários remotos e definem as ações que podem ser executadas nas aplicações. O Mobile Access criptografa todo o tráfego usando HTTPS para aplicações baseados na web e algoritmo 3DES ou RC4 para aplicações nativas. Para que os usuários finais acessem os aplicativos nativos, eles precisam instalar o SSL Network Extender.
Lado do Cliente
No lado do cliente da conexão, o Mobile Access pode escanear dispositivos endpoint para verificar sua conformidade de segurança e certificar-se de que suas proteções estão atualizadas. O Mobile Access pode ser configurado para recusar uma conexão se o dispositivo for considerado em não conformidade.
O Mobile Access só permitirá conexões com dispositivos que puderam ser autenticados, usando um dos métodos de autenticação suportados, incluindo, DynamicID, que é o método de autenticação de dois fatores da CheckPoint para máquinas. Além disso, a segurança pode ser aprimorada evitando que os navegadores armazenem em cache determinado conteúdo, como um PDF, que os invasores podem roubar.
As organizações também podem exigir que usuários remotos utilizem o Capsule Workspace, o desktop virtual proprietário da CheckPoint. Este espaço de trabalho virtual fornece um ambiente seguro, no qual os arquivos são criptografados e dá aos usuários a opção de limpar os dados após cada sessão.
Implementação do Mobile Access 
O Mobile Access pode ser implementado de diversas maneiras, dependendo do que se adequa a necessidade da organização:
· Implementação Simples
· Implementação em Cluster
Implementação Simples
Esta implantação é a mais fácil de configurar. Nesta implantação, um único Security Gateway habilitado com o Mobile Access Software Blade inspeciona todo o tráfego de rede, incluindo aqueles provenientes de dispositivos terminais. Seu gateway existente atua como seu gateway Mobile Access.
Implementação Simples
Implementação em Cluster
Uma implantação de cluster funciona melhor para organizações com grande número de usuários de acesso remoto simultâneos. Cada cluster pode ser implantado em qualquer uma das implantações mencionadas acima. Nesta implementação, no entanto, é recomendado que cada membro do cluster tenha três interfaces: uma interface que leva à organização, uma segunda que leva à Internet e uma terceira para sincronização. Cada interface está em uma sub-rede diferente.
Mobile Access Policy
CheckPoint Mobile Access estende a funcionalidade de Firewall para os usuários remotos. As Mobile Access policy Rules são definidas e unificadas na s políticas de Access Control. Isto incluí regras relacionadas ao Mobile Access Portal, Capsule Workspace, e clientes sob demanda.
Na Access Control Rule Base, as regras podem ser configuradas para serem aplicadas a todos os Mobile Access Gateways. As regras podem ser configuradas para serem aplicadas a um ou mais clientes, tais como o Mobile Access Portal ou Capsule Workspace.
Mobile Access Rule Base
As regras de Mobile Access para os Security Gateways na versão R80.10 ou acima, podem ser configuradas como parte da Unified Access Control Policy na SmartConsole ou na Legacy shared Mobile Access policy na SmartDashboard.
As regras para os Gateways pre-R80 só podem ser configurados via SmartDashboard. Regras Mobile Access para ambas opções de políticas devem incluir usuários e grupo de usuários, as aplicações a serem acessadas, e o(s) gateway(s) a que a(s) regra(s) se aplica(m).
Configuração Mobile Access
Todos os gateways Mobile Access em um ambiente devem usar a mesma fonte para a política do Mobile Access. Você não pode configurar o ambiente para ter alguns gateways que usam a Unified Access Policy e alguns que usam a opção Legacy Policies.
NOTA:
Ao usar o Unified Access Policy, alguns recursos e configurações do Mobile Access ainda são feitas no SmartDashboard.
Para configurar um gateway R80.10 para usar a Unified Access Control Policy :
1. Na SmatrConsole, navegue até a aba Gateways & Servers, e abra o objeto do Gateway Mobile Access.
2. Sececione Mobile Access.
3. Na sessão Policy Source, selecione Unified Access policy.
4. Instale política.
Mobile Acces na Access Control Policy
Para configurar a autorização de Mobile Access na Access Control Policy, o Mobile Access Software Blade deve estar habilitado. O Mobile Access Blade só entende regras de aplicação Mobile Access Blade definido e com ou sem uma função de acesso definida na coluna Source.
Security Gateways com Mobile Access habilitado, são adicionados automaticamente ao Remote Access VPN Community. Para configurar regras para o portal ou cliente Mobile Access, inclua a comunidade ou uma Comunidade de acesso remoto que inclua o Gateway Mobile Accessl na coluna VPN. Por padrão, a comunidade Remote Access VPN contém um grupo de usuários que contém todos os usuários.
Para usar uma aplicação Mobile Access na Access Control Policy, ele deve ser definido como Mobile Application no SmartConsole ou SmartDashboard. Outros objetos de aplicação, como objetos de Content Awareness e URL Filtering, não podem ser usados em regras de Mobile Access. Por exemplo, uma aplicação URL Filtering do Facebook não pode ser usada para Mobile Access. Uma nova aplicação da web do Facebook deve ser criado e autorizado como uma aplicação da web para Mobile Access. Os objetos de aplicações móveis podem ser criados na coluna Service & Application de uma regra.
Para conceder acesso aos recursos por meio dos clientes de acesso remoto específicos, crie funções de acesso para os clientes e inclua-os na coluna Source de uma regra. Se uma função de acesso for definida na coluna Source de uma regra, o Identity Awareness Software Blade deve estar habilitado em todos os destinos de instalação aos quais a regra se aplica. As funções de acesso para acesso remoto serão aplicadas aos clientes Mobile Access e VPN IPSec. Quando uma função de acesso para um cliente está na coluna Source de uma regra, a regra será aplicada ao tráfego originado desse cliente.
Mobile Access policy Layers and Inline Layers
As regras do Mobile Access podem ser incluídas em camadas de política e camadas em linha. Mobile Access deve ser habilitado para cada camada que contém regras com aplicações Mobile Access. Em uma política com camadas Ordered Policy, a ordem das regras na Rule Base é importante porque a primeira regra que corresponde ao tráfego é aplicada. A correspondência continua em cada camada subseqüente até que o tráfego do MobileAccess seja correspondido com uma regra de Drop ou Accept em todas as camadas. Nesse caso, a aplicação que corresponde a Mobile Access é tomada última regra que corresponde com a aplicação Mobile Access.
Uma Inline Layer do Mobile Access pode ser configurada em qualquer Ordered Layer. Uma regra de bypass para aceitar o tráfego do Mobile Access deve ser criado em todas as Layers e colocadas acima da Layer do Mobile Access. A regra de bypass corresponderá ao tráfego do Mobile Access nacamada e permitirá que o tráfego se mova para a próxima Layer até atingir Mobile Access Inline Layer. Use a função de acesso para todos os usuários do Mobile Access na coluna Source e Accept em Action para criar a regra de bypass .
Como uma Inline Layer ou Sub-policy Layer, o Mobile Access é correspondido na regra pai e, em seguida, na regra Inline Layer. A aplicação correspondente para Mobile Access é obtida da última regra correspondida com uma aplicação Mobile Access. Se a regra correspondente na Inline Layer não contiver uma aplicação Mobile Access, a política procurará uma aplicação Mobile Access na regra pai da Inline Layer.
Best Practices
É uma prática recomendada colocar regras do Mobile Access que autorizam aplicações acima das regras que contêm serviço vinculado. Por exemplo, uma regra que permite o acesso a uma aplicação web Mobile Access, como Outlook Web Access (OWA) em HTTPS, deve estar acima de uma regra que permite ou bloqueia HTTPS. Se a regra HTTPS for a primeira, a aplicação da web corresponderá a essa regra e a política não alcançará a regra que contém o aplicação Mobile Access.
A CheckPoint recomenda a criação de Inline Layer para Mobile Access. Para usar o Inline Layer de maneira eficiente, defina uma regra pai na camada de política principal. A regra pai corresponderá a todo o tráfego do Mobile Access e enviará o tráfego a Inline Layer. É necessária uma função de acesso que inclua todos os usuários do Mobile Access na coluna Source.
Quando criar regras, não use o Security Gateway como destino. Use Any ou hosts internos da aplicação relevante na coluna Destination. Isto se deve ao fato das aplicações de Mobile Access serem definidas na coluna Services & Applications. Por sua vez, não use Any na coluna Service & Applications. Para que uma aplicação seja exibida no portal Mobile Access ou Capsule Workspace, esta deve ser um objeto de aplicação Mobile Access que é usado explicitamente na Rule Base.
Threat Prevention
O cenário de ameaças de hoje continua a evoluir em um ritmo rápido. Como resultado, a prevenção de ameaças tornaram-se mais complexas do que nunca. Muitas organizações são desafiadas a acompanhar o cenário de ameaças em expansão dinamicamente, bem como as novas tendências, como consumerização, conformidade regulamentar e serviços baseados em nuvem. organizações e indivíduos continuam a ser vitimados e sitiados por ataques cibernéticos sofisticados em uma taxa cada vez maior. as empresas não precisam apenas se preocupar com ataques à rede, mas também com ataques direcionados aos computadores do usuário final, como vírus e bots. Além disso, novos malwares são criados quase a cada segundo.
Ataques de dia zero e Advanced Persistent Threats (APTs) são tipos diferentes de ameaças que os invasores empregam para visar as empresas. Ambos usam técnicas de evasão que indeterminam as defesas de uma organização. Portanto, é importante que as organizações implementem uma estratégia de segurança multifacetada para expor e combater essas e outras ameaças.
Zero-Day Attacks
Ataques Zero-day visam falhas ou vulnerabilidades de software desconhecidas para fornecer novas variantes de malware existente. Eles são conhecidos por “enganar” as soluções anti-malware e antivírus mais atualizadas. Como ainda não existe um patch de segurança disponível para essas vulnerabilidades, os ataques de dia zero oferecem aos invasores a oportunidade de realizar suas atividades maliciosas na rede da empresa visada.
Advanced Persistant Threats (APTs)
Os APTs são projetados para se infiltrar nos sistemas de uma organização por um período de tempo, evitando a deteção. Esses ataques usam várias técnicas em vários estágios e geralmente aparecem como pequenos eventos não relacionados que, se considerados individualmente, podem parecer inofensivos. Em alguns casos, os APTs podem empregar ameaças de Zero-Day como vetor de infecção, mas também exploram vulnerabilidades /
APTs são conhecidos por serem lançados e financiados por estados-nação e certas organizações. Eles têm como alvo organizações grandes e pequenas. O dano de um APT bem-sucedido pode ter um impacto severo nas empresas afetadas. O impacto pode incluir violações de dados, tempo de inatividade do sistema, danos à reputação da marca e várias taxas caras.
Intrusion Prevention System
O Intrusion Prevention System (IPS) é um componente da solução Threat Prevention. Enquanto o Firewall bloqueia o tráfego com base nas informações de origem, destino e porta, o IPS adiciona outra linha de defesa ao analisar o conteúdo do tráfego para verificar se é um risco para a rede.
O IPS protege os usuários de malware em sites legítimos, controla o uso da rede de aplicações selecionados e muito mais.
Configurações e Proteções IPS
O IPS Software Blade oferece prevenção contra intrusões pro-ativa e completa. Ele apresenta milhares de assinaturas e proteções comportamentais e preventivas para fornecer prevenção de intrusão completa para clientes, servidores, sistema operacional e outras vulnerabilidades. Seu mecanismo de deteção combina várias camadas de defesa para detetar e prevenir ameaças.
No R80.10, o IPS Software Blade é gerenciado pela política Threat Prevention. Como parte da política unificada de Threat Prevention, o IPS permite mais granularidade com vários perfis de proteção por gateway. As proteções IPS são aplicadas imediatamente no tráfego de rede quando uma política Threat Prevention é instalada nos Security Gateways. Os perfis Threat Prevention determinam quais proteções são ativadas.
Os perfis IPS podem ser importados e exportados usando o comando ips_export_import na CLI. Usando este comando, as configurações de perfil podem ser copiadas entre servidores de gerenciamento da mesma versão.
Cada perfil IPS contém um conjunto de proteções ativadas e instruções sobre o que o IPS fará quando a inspeção de tráfego corresponder a uma proteção ativada. A biblioteca de proteções IPS é constantemente atualizada para evitar ameaças emergentes. Security Gateways com IPS habilitado obterá as atualizações quando a política for instalada. Para visualizar as proteções mais recentes, navegue até as secções do Threat Tools e selecione IPS Protections.
Todas as proteções IPS têm marcações dinâmicas que permitirão aos perfis do Threat Prevention ativar ou desativar automaticamente as proteções marcadas por aspectos relevantes, como software afetado por protocolos e tipos de arquivo.
Security Gateways de versões anteriores de software que têm IPS e outras Threat Prevention Software Blades habilitados, terão sua política Threat Prevention dividida em duas layers diferentes. Por sua vez, a Layer IPS incluirá as proteções IPS Threat Cloud e todas as outras proteções IPS principais permanecerão como parte da instalação da Política de Controle de Acesso.
NOTA:
As configurações de violações de protocolo, como "agressive aging" e "HTTP non-compilat", são acessadas na secção Inspection Settings. Para visualizar esta secção, navegue até Manage & Settings > Blades.
Manutenção e Tunning do IPS 
IPS não é uma solução estática e requer tunnig e manutenção regular para que seja efetiva contra ameaças em evolução. Abaixo uma visão geral de como manter IPS:
· Verificar se há recurso de CPU suficiente para habilitar IPS.
· Atualize o pacote IPS, para garantir que o Security gateway está atualizado como as assinaturas mais recente.
· Defina a ação padrão do IPS pata Prevent, para habilitar a máxima proteção da rede.
· Defina a ação padrão IPS das novas proteções baixadas para Prevent.
· Clone o Recommend Porfile para criar uma cópia de backup. Certifique-se de que todas as alterações sejam feitas no perfil clone. Os requisitos de segurança para diferentes segmentos na rede geralmente dependem dos tipos de tráfego e objetos de rede especificados para cada segmento. Para implementação em um Multi-Domain Server ou vários gateways, considere a criação de políticas IPS separadas e execute essas etapas para cada segmento.
· Durante o processo inicial, ative o modo Troubleshooting.Nesse modo, o IPS inspeciona, mas não bloqueia o tráfego exclusivo da rede. Mesmo se todas as proteções estiverem definidas como Prevent, o gateway só deteta possíveis ameaças e gera logs para o tráfego.
· Use a opção Follou Up para ajudar na análise e ajuste de novas proteções no futuro.
· Atribua o perfil ativo aos gateways aplicáveis e configure o gateway para ignorar a inspeção IPS quando estiver sob Heavy Load. Isso é para garantir que a análise IPS não afete o tráfego na rede.
· Instale a política nos gateways, porque as políticas não são implantadas automaticamente.
· Depois de instalar a política, o IPS começará a inspecionar o tráfego e a gerar logs. Colete os registros de pelo menos uma ou duas semanas e, em seguida, analise os registros para decidir quais proteções executar no modo Protector Detect e quais requerem mais ajustes e análises.
· Desative o modo Troubleshoting para IPS Software Blade para proteger a rede.
· Altere as configurações para Updates Policy, Configure Updates para as proteções baixadas recentemente e defina como Detect. Quando novas proteções IPS são implantadas, elas são definidas para o modo Detect.
· Limpe os flags de acompanhamento e as flags baixados recentemente para todas as proteções que são revisadas durante o processo de ajuste.
· Ajuste as novas proteções IPS baixadas duas vezes por mês e procure mudanças no comportamento das já ajustadas.
· Monitore o desempenho do Security Gateway e defina as configurações aplicáveis para fornecer a melhor segurança e desempenho de rede.
Geo-Protection
A Geo-Protection reforça ou monitora o tráfego com base nas fontes ou no país de destino.
As informações do país são determinadas comparando o endereço IP no pacote com o banco de dados IP-to-country. Endereços IP privados são sempre permitidos, a menos que sejam especificados explicitamente como bloqueados no outro lado da conexão. As conexões de controle CheckPoint (CCP), por exemplo aquelas entre Security Gateways e Security Management Server (SMS), são sempre permitidas, independentemente da política de Geo-protetion.
Você deve ter um contrato IPS válido e uma Licença Software Blade para cada Security Gateway que aplica a Geo-Protetion.
Geo Policy
Database de Endereço de IP por País
O banco de dados Ip-to Country é baixado para o Security Gateway de um data center da CheckPoint. Para certificar-se de que o banco de dados está atualizado, o Security Gateway deve estar conectado à Internet. Se o Security Gateway requer um proxy para acessar a Internet, o proxy deve ser definido no SmartDashboard.
Log Aggregation por País
Por padrão, os logs de Geo-protection são agregados, o que significa que uma única entrada de log é gerada por intervalo de agregação, para cada país que faz parte da Política para Países Específicos. Logs relacionados a outros são agregados a uma única entrada de log.
É possível desligar a agregação de log por país. Nesse caso, um log é criado para cada conexão rastreada. Desativar a agregação de log por país pode aumentar significativamente o número de logs gerados e aumentar o uso da CPU no Security Gateway.
Antivirus
O Antivirus Software Blade da CheckPoint protege a rede de ataques de malware, como worms, backdoors, vírus e cavalos de tróia. Usando a inteligência de ameaças do ThreatCloud, o Antivirus geralmente lida com ameaças que entram na rede da organização. Ele verifica arquivos de entrada como arquivos do PowerPoint, Word ou Excel em busca de assinaturas maliciosas. Em seguida, ele atualiza o repositório ThreatCloud para qualquer malware detectado recentemente encontrado no sistema.
Além de monitorar e classificar arquivos, o Antivirus também bloqueia o acesso a sites com conexões conhecidas de malware. O Security Gateway usa seus mecanismos de cache para verificar URLs. Se o Security Gateway não puder verificar o URL, o Antivirus Blade enviará a URL ao ThreatCloud para verificação. Se for considerado malicioso, o Antivirus bloqueia o acesso ao URL antes que qualquer dano ocorra.
Anti-Bot
Um bot é um malware que usa mecanismos furtivos para permanecer oculto das soluções antivírus. Eles podem chegar a um computador como um anexo de e-mail infectado ou como resultado de um drive-by download de um site malicioso.
Assim que a infecção ocorre, o bot assume o controle do computador conectando-se a um servidor Command & Control (C&C) e aguarda instruções de atacantes que podem executar rotinas remotamente. Essas rotinas incluem roubo de dados, distribuição de spam e outras atividades que consomem recursos e largura de banda significativos do computador. Os atacantes também usam o computador controlado por bot para atacar e infectar outros computadores, criando um botnet. O Anti-Bot tenta evitar danos bloqueando as comunicações do servidor C&C.
A Software Blade de Anti-Bot identifica máquinas infectadas por bot usando o mecanismo ThreatSpect de várias camadas para analisar o tráfego de rede. ThreatSpec é uma tecnologia de descoberta que possui feeds de atualização atualizados do ThreatCloud. O engine é instalado no Gateway e executa três tarefas importantes:
· Um bot é um malware que usa mecanismos furtivos para permanecer oculto das soluções antivírus. Eles podem chegar a um computador como um anexo de e-mail infectado ou como resultado de um download drive-by de um site malicioso.
· Assim que a infecção ocorre, o bot assume o controle do computador conectando-se a um servidor Command & Control (C&C) e aguarda instruções de atacantes que podem executar rotinas remotamente. Essas rotinas incluem roubo de dados, distribuição de spam e outras atividades que consomem recursos e largura de banda significativos do computador. Os atacantes também usam o computador controlado por bot para atacar e infectar outros computadores, criando um botnet. Um anti-bot tenta evitar danos bloqueando as comunicações do servidor C&C.
· Executa verificação de reputação para verificar os endereços de IP e as zonas de soltar de sites C&C conhecidos com atualizações em tempo real de uma lista de endereços. Security Gateways são constantemente atualizados com a lista mais recente. No entanto, o mecanismo ThreatSpec pode consultar o ThreatCloud para obter mais atualizações. O mecanismo ThreatSpect também armazena em cache essas informações para minimizar o tempo para implantar atualizações.
· Analisa as assinaturas de rede de mais de 2.000 famílias de bot que foram detetadas anteriormente. ele combina o comportamento do tráfego com padrões conhecidos de comportamento de bot e bloqueia a comunicação com os sites C&C. Isso garante que nenhuma informação sensível seja roubada ou vazada.
· Pesquisa atividades suspeitas monitorando o tráfego de e-mail de saída e os padrões de comunicação. por exemplo, ele analisa o correio de saída para identificar o spam enviado pela organização. Ele também monitora se um computador participa de ataques Denial of Service (DoS).
Sandboxing
Sandboxing é uma solução preeminente usada para capturar ataques Zero-Day e APTs. Ele permite que um arquivo seja hospedado e executado em um ambiente seguro, separado da rede. O arquivo é então observado em busca de rotinas suspeitas. Se o arquivo exibir qualquer tipo de comportamento malicioso, ele será impedido de ser liberado na rede. Se for seguro, o arquivo será liberado para a rede. Atualmente, existem dois tipos de sandbox. A nível de SO e a nível de CPU.
Sandboxing a Nível de SO
Também conhecido como sandboxing tradicional, o sandboxing a nível do SO emula um sistema operacional padrão em um ambiente isolado para executar um arquivo de triagem. Isso garante que os arquivos suspeitos sejam isolados com segurança da rede de produção da empresa
O sandbox simula o arquivo como se o usuário real o abrisse e o monitora em busca de rotinas maliciosas. Se o arquivo mostrar qualquer comportamento suspeito, a sandbox atualiza o ThreatCloud para compartilhamento de inteligência contra ameaças e exclusão do arquivo.
Métodos Tradicionais de Evasão do Sandbox
Atacantes criaram váriastáticas para evitar a deteção pelo sandbox. Algumas destas técnicas conhecidas são:
· Atrasar o lançamento de uma carga útil, em que o código malicioso é executado minutos, horas, dias ou oito anos após o arquivo ter sido aberto.
· Pesquisar indicadores de máquina virtual, como verificação de chave de registo, processos em execução ou tamanho de disco para identificar um ambiente de sandbox.
· Verificação de atividades de interação humana que são difíceis de replicar em um ambiente virtual, incluindo rolagem de página e cliques do mouse.
· Impressão digital do sistema operacional para identificar sistemas, serviços e configurações de hardware e software que podem estar disponíveis para exploração.
Sandboxing a Nível de CPU
Sandboxing a nível da CPU aborda as limitações do sandboxing tradicional, executando a inspeção no nível da CPU para monitorar qualquer indicação de um método de exploração executado nos códigos de instrução da CPU (sets). Essa solução tira vantagem do fato de que, embora os invasores tenham muitas vulnerabilidades e malware para escolher, eles podem usar apenas alguns métodos de exploração.
A imagem abaixo mostra um cenário típico de ataque no nível da CPU:
Quatro Estágios de um ataque a nível de CPU.
1. Encontrar vulnerabilidade - uma ou mais vulnerabilidades são descobertas no código do sistema operacional ou em aplicativos amplamente usados, como navegadores de Internet e leitores de PDF. Potencialmente, pode haver milhares de vulnerabilidades de software em um sistema. Ao explorar qualquer uma dessas vulnerabilidades, os invasores injetam sua lógica no sistema e disparam um ataque.
2. Usando um método Exploit - as explorações permitem que a lógica injetada manipule o sistema de destino e execute o código malicioso. Isso requer a superação dos controles de segurança integrados implementados pelo sistema operacional e pela CPU, como Data Execution Prevention (DEP) e Address Space Layout Randomization (ASLR). Este é o estágio em que o sandbox no nível da CPU examina os arquivos em busca de um método de exploração e o analisa antes que o shellcode seja executado.
3. Executando um Shellcode - Um Shellcode é uma pequeno payload, geralmente embutido em um arquivo ou página da web. Depois de aproveitar um ou mais métodos de exploração, o invasor então implanta o shellcode na memória executável ou engana o sistema para executá-lo. Recuperando o malware real, o shellcode o “instala” no sistema infectado.
4. Executar o Malware - a execução do malware conclui a infecção. Este é o estágio em que o sandboxing tradicional descobre se um arquivo mostra alguma rotina suspeita. No entanto, é nesta fase que as técnicas de evasão geralmente se manifestam, como quando um arquivo atrasa a execução de suas rotinas na tentativa de se esconder da sandbox.
Proteção SandBlast Zero-Day CheckPoint 
A Proteção SandBlast Zero-Day é a solução CheckPoint contra ataques Zero-Day, APT e ameaças similares. É complementado com um conjunto de ferramentas de visibilidade de ataque, como a visualização Logging and Monitoring do SmartConsole e SmartEvent. Essas ferramentas auxiliam na perícia e ajudam a revelar como o malware detectado teria se comportado se tivesse sido permitido para execução.
A Checkpoint oferece soluções de tecnologia SandBlast para configurações de rede privada e nuvem pública. Para proteger os sistemas do usuário final, o CheckPoint expande a proteção SandBlast com o Agente SandBlast.
Componentes SandBlast 
SandBlast tem vários componentes funcionais que trabalham juntos para garantir que os ataques sejam evitados em tempo real. Esses componentes incluem:
· Threat Emulation
· Threat Extraction
· Threat Cloud
· Mail Agent Transfer
SandBlast Threat Emulation
O mecanismo Threat Emulation é o componente sandbox do SandBlast. Ele protege a rede contra ataques avançados e de Zero-Day, executando a inspeção de arquivos no nível da CPU e do sistema operacional. Threat Emulation hospeda o arquivo em um ambiente sandbox e examina-o no nível da CPU para qualquer indicação de atividade de exploração. Essa inspeção impede que o arquivo execute qualquer uma de suas rotinas, especialmente aquelas que tentam escapar da deteção.
SandBlast Threat Extraction
O engine Sandblast Threat Extraction examina arquivos de documentos e remove qualquer conteúdo ativo do documento, enquanto Threat Emulation executa o arquivo no seu ambiente seguro. 
SandBlast Threat Cloud
Os conteúdos ativos incluem objetos como JavaScript, macros e links, que os cibercriminosos podem usar para inserir seu código malicioso.
Enquanto o Threat Emulation executa e inspeciona arquivos, o Threat Extraction fornece aos usuários um documento limpo e reconstruido usando apenas elementos seguros. Isso garante a continuidade dos negócios e a produtividade do usuário final sem comprometer a segurança.
Threat Extraction é normalmente usado apenas para emails de entrada; no entanto, ele também pode ser usado para enviar e-mails. Ele suporta tipos de arquivo de documento amplamente usados, como PDF, e documentos do MS Word.
Ambos, Threat Extraction e Threat Emulation funcionam juntos para proteger redes em produção enquanto garantem que os processos de negócios continuem normalmente. Entretanto, cada componente trabalha de maneira diferente.
A tabela a Seguir detalha diferenças entre Threat Extraction e o Threat Emulation:
	Threat Extraction
	Threat Emulation
	Remove preventivamente possível conteúdo malicioso.
	Deteta ameaças pro-ativamente
	Sempre entrega um arquivo.
	Entrega o arquivo se não encontrar ameaças.
	Trabalha com arquivos MS Office e PDF.
	Trabalha com arquivos MS Office, PDF, executáveis e arquivos compactados.
	Entrega a versão PDF do arquivo original ou formato original com remoção de conteúdo ativo.
	Entrega o arquivo com o conteúdo original
	Leva menos de um segundo para completar.
	Leva alguns minutos para completar ( menos de 3 minutos)
	Presume que todo o conteúdo é potencialmente malicioso,
	Deteta ameaças e fornece um relatório detalhado das ameaças descobertas.
	Desativa qualquer funcionalidade ativa em documentos, independentemente de sua intenção.
	Oferece funcionalidade total se nenhuma ameaça for detetada.
Threat Cloud
CheckPoint Threat Cloud é a plataforma back-end para troca de inteligencia para todos os produtos e serviços CheckPoint. Esta plataforma consolida big data, feeds externos, e aprendizado compartilhado de várias fontes tais como:
· Assinatura e dados de reputação de diferentes sistemas CheckPoint.
· Fontes de inteligência externos, junto com agentes SandBlast e dados de consumidores e endpoint.
· Dados e pesquisas do Vulnerability Research e Incident Response Teams da CheckPoint.
A nuvem de ameaças garante que o SandBlast esteja atualizado com informações para ajudar a proteger a rede de uma organização contra as ameaças mais recentes.
Mail Transfer Agent
A funcionalidade Mail transfer Agent (MTA) nos Security Gatewys CheckPoint garantem que uma emulação completa ocorra sem nenhuma interupção aos negócios, particularmente no fluxo de email. Habilitar o MTA previne a possibilidade de timeout do servidor de email durante a emulação e gerencia a emulação do tráfego SMTP. MTA completa e fecha a conexão com o servidor de origem de email e envia o arquivo para emulação.
Com MTA habilitado, o gateway gerencia o tráfego SMTP via porta 25 e mantém emails externos com anexos potencialmente maliciosos. Após a conclusão da emulação, o MTA envia o e-mail para o servidor na rede interna. O processo detalhado é mostrado abaixo:
Workflow da Funcionalidade MTA
1. O MTA atua como um servidor SMTP, recebendo e-mail do remetente e fechando a conexão após o e-mail completo e o anexo serem recebidos,
2. O MTA retém o e-mail até que Threat Extraction reconstrua uma cópia limpa do anexo.
3. O MTA envia o anexo ao ambiente do sandbox do Threat Emulation para inspeção.
4. O MTA armazena o anexo original no Security Gateway e modifica o e-mail anexando uma cópia limpa do anexo, junto com umlink para o anexo original.
5. O MTA então encaminha o e-mail modificado para o servidor de e-mail, que o envia ao destinatário pretendido.
NOTA:
Para habilitar a funcionalidade do MTA no Security Gateway, ative o pacote Threat Prevention Software Blade que inclui Antivirus, Anti-Bot e Threat Extraction ou Threat Emulation.
SandBlast Appliances
Os appliances SandBlast podem ser implementados de duas formas:
· Inline ou Prevent - Como um Mail Transfer Agent (MTA) e como parte do fluxo de tráfego da web.
· Detect Only - Uma porta SPAN para receber uma cópia do tráfego.
Um dispositivo SandBlast inclui o Anti-Bot, Antivirus, Threat Emulation e Threat Extraction. No entanto, é recomendável usar o dispositivo exclusivamente para sandbox no nível do SO e deteção do nível da CPU.
As organizações que preferem não permitir o envio de arquivos para fora da rede corporativa ou aquelas que possuem uma grande arquitetura de rede centralizada que exige alto desempenho e baixa latência, podem optar por implantar uma opção de nuvem privada SandBlast. As arquiteturas de solução variam dependendo de casos como:
· Um dispositivo SandBlast inclui o Anti-Bot, Antivirus, Threat Emulation e Threat Extraction. No entanto, é recomendável usar o dispositivo exclusivamente para sandbox no nível do SO e deteção do nível da CPU.
· Clientes com CheckPoint Security Gateways executando R77 ou superior e com o pacote Next Generation Theatre Prevention (NGTP) ativado.
· Clientes com gateways CheckPoint abaixo de R77 ou nenhum pacote NGTP, ou com gateways de terceiros.
· Clientes que estão avaliando o SandBlast antes de instalá-lo.
Prevent Mode
Quando um dispositivo SandBlast é implementado no modo Prevent, o tráfego (ou um arquivo anexado) é enviado ao dispositivo antes que ele tenha permissão para entrar na rede interna. Esta implantação requer que o recurso MTA no Security Gateway esteja ativado.
O modo Prevent também é recomendado para cenários de Proof-of-concept (POC) em que o cliente está usando um firewall de terceiros ou uma versão mais antiga do software CheckPoint. Os clientes sem o pacote Next Generation Threat Prevention (NGTP) também se beneficiariam com esse tipo de implementação.
SandBlast Appliance em Prevent mode
O Workflow detalhado do appliance SandBlast na arquitetura do modo prevent:
1. O atacante envia um email com um arquivo anexado.
2. O Security Gateway com MTA habilitado retém o email.
3. Threat Extraction reconstrui uma cópia segura do arquivo anexado, e encaminha para o servidor de email. O destinatário recebe o email e uma cópia segura sem nenhum atraso.
4. Threat Emulation encaminha o arquivo anexado para Sandboxing a nível do SO e deteção no nível da CPU no SandBlast Appliance.
5. O SandBlast Appliance inspeciona o arquivo. Se o arquivo for considerado malicioso, o SandBlast atualizará o ThreatCloud com as informações. O arquivo é marcado como infectado e excluído da área de retenção do MTA do Check Point Security Gateway.
6. Se o dispositivo SandBlast determinar que o arquivo é inofensivo, o arquivo original será liberado para o servidor de e-mail.
Detect Only Mode
Para usuários que desejam realizar uma avaliação primeiro, o dispositivo SandBlast pode ser configurado para Detect Only Mode ou implantação de porta SPAN para monitorar ataques Zero-Day. Neste cenário, o tráfego duplicado é enviado para o SandBlast enquanto o tráfego real entra na rede interna, passando pelo Security Gateway. O uso do recurso MTA não é necessário nesta implantação.
Appliance SandBlast no Detect Only Mode
A arquitetura SandBlast em Detect Only Mode funciona da seguinte maneira:
1. Um invasor envia um e-mail com um anexo.
2. O CheckPoint Security Gateway ou um gateway de terceiros usa um espelho ou porta TAP para duplicar o tráfego de rede, enviando-o para o SandBlast.
3. O gateway realiza uma inspeção de segurança tradicional e permite que o tráfego entre na rede.
4. O usuário recebe o e-mail original sem nenhum atraso..
5. O Threat Emulation encaminha o arquivo anexado ao SandBlast para sandbox a nível do sistema operacional e deteção no nível da CPU. Se o arquivo for considerado malicioso, o SandBlast atualiza o Threat Cloud com o novo malware e o administrador do sistema é notificado sobre a infecção.
SandBlast Cloud
SandBlast Cloud executa sandboxing a nível de sistema operacional e deteção de nível de CPU em uma infraestrutura na nuvem pública controlada pela CheckPoint. Esta solução não requer nenhum novo hardware e é ideal para usuários que desejam usar seus gateways existentes, têm uma rede globalmente distribuída ou têm alto uso de aplicativos baseados em nuvem ou Software-as-a-Service (SaaS). O fluxo de trabalho detalhado da arquitetura SanBlastCloud é o seguinte:
1. O atacante envia um email com um arquivo anexado.
2. O Security Gateway com MTA habilitado retém o email.
3. Threat Extraction reconstrui uma cópia segura do arquivo anexado, e encaminha para o servidor de email. O destinatário recebe o email e uma cópia em PDF segura sem nenhum atraso.
4. Usando o serviço MTA, o Threat Emulation encaminha o e-mail ao SandBlast Cloud para sandbox a nível do sistema operacional e deteção a nível da CPU.
5. Se for identificado como malware Zero-Day, o SandBlast Cloud atualiza o ThreatCloud com as novas informações. O arquivo é marcado como infectado e excluído da área de retenção do MTA no Security Gateway.
6. Se o Sandblast determinar que o arquivo é inofensivo, ele será liberado para o servidor de e-mail.
Arquitetura SandBlast Cloud
SandBlast Cloud proporciona proteção contra ataques Zero-day para organizações em transição para aplicações baseadas na nuvem. O SandBlast Cloud incluí os seguintes elementos de segurança:
· Antivirus - Aproveita pro-ativamente as assinaturas do antivírus para proteger contra malware em arquivos anexados.
· URL Reputation - Deteta e bloqueia URLs maliciosos dentro do corpo do email.
· Threat Extraction - Entrega copias seguras reconstruidas dos documentos para os usuários enquanto inspeciona o arquivo original para potenciais ameaças.
· Threat Emulation - Encaminha os anexos de arquivo de e-mail de entrada, incluindo arquivos oriundos de URLs dentro de e-mails, para a sandbox para emulação. Ele bloqueia e deteta o arquivo se verificado como malicioso, ou um componente de um ataque do Zero-Day.
O SandBlast Cloud pode ser implementado em Detec mode, Prevent Mode ou Hybrid.
SandBlast Cloud em Detect Mode
No Detect mode, os emails que chegam vão direto para caixa de entrada sem nenhuma interferência, enquanto os arquivos anexados são enviados para o SandBlast Cloud para serem inspecionados. Este modo é o ideal para introduzir a visibilidade das ameaças enquanto gradualmente se implementa a solução.
SandBlast Cloud in Prevent Mode
No Prevent Mode, os emails de entrada são direcionados para uma pasta de quarentena temporária no Office 365 para isolar os emails de entrada da caixa de entrada do usuário. Isso garante que emails contendo anexos, conteúdos e URLs maliciosos não cheguem aos usuários finais.
No caso de um falso positivo, no qual um usuário determina que o e-mail é de uma fonte confiável, o e-mail e o conteúdo podem ser recuperados da pasta de quarentena.
Implementação Hybrid (híbrida)
Organizações com um Eschange Server local e CloudOffice 365 podem usar as seguintes opções para um desenvolvimento híbrido:
· ExchangeMail - use o CheckPoint SecurityGateway com licença NGTP e use o SandBlastCloud ou o dispositivo para ThreatEmulation.
· Microsoft Office 365 - inscreva-se no Checkpoint SandBlast security as a service.
Para consolidar o registo e fazer com que ambas as soluções enviem registros para o mesmo servidor SmartLog ou SmartEvent local, os usuários podem configurar o Log Transfer Agent (LTA) no painel CheckPoint SandBlast Cloud.
Exchange Server as MTA Agent
Usar um agente Exchange Server como um agente MTA é a melhor opção para administradores que desejam simplificar o design de retenção de correspondência durante a implementação do SandBlast.Isso permite que eles usem seu Exchange Agent existente para manter todos os e-mails corporativos, enquanto o CheckPoint SandBlast os certifica como seguros.
SandBlast Agent
O SandBlast Agent expande a proteção do SanBlast para os sistemas dos usuários finais, tais como desktops e laptops. Foi “desenhado” para defender dispositivos endpoint e navegadores web.
Se um malware entra no sistema de um usuário final, o SandBlastAgent usa sua versão local do Anti-bBot para detetar e conter essas infeções. Procura por qualquer comunicação Command and Control (C&C) que seja enviada dentro da rede. Para prevenir o malaware de se espalhe dentro da rede, o SandBlast Agent bloqueia toda comunicação do computador afetado e coloca em quarentena os arquivos infetados.
Forensics Analysis
O agente SandBlast apresenta análise forense automatizada que gera relatórios e diagnósticos abrangentes de eventos de segurança para uma resposta mais rápida contra ataques. Ele mostra detalhes da ameaça, como método de chegada, fluxo de ataque, impacto nos negócios e hosts infetados.
SandBlast Agent Workflow
Para criar este report, o SanBlast efetua o que segue:
1. O SandblastAgent coleta dados forenses continuamente no terminal em uma área resistente à violação. Isso fornece visibilidade total da atividade durante todo o ciclo de vida do ataque e causar sobrecarga mínima. Os dados são armazenados por um período de 30 dias por padrão, mas podem ser ajustados. Como o agente regista apenas eventos, ele requer menos de 1% dos recursos da CPU e 1 GB de armazenamento.
2. Um relatório de incidente pode ser acionado por vários eventos, incluindo entrada do SandBlast Agent, Threat Emulation, Threat Extraction e outros Software Blades habilitados.
3. Os dados forenses brutos são analisados usando algoritmos avançados. O SandBlast Agent solicita automaticamente os logs dos endpoints envolvidos.
4. Por fim, o SandBlast Agent gera uma visão completa dos ataques, incluindo ponto de entrada, impacto nos negócios e fluxo de ataque completo. O relatório de incidente é enviado ao SmartEvent.
Além de fornecer relatórios abrangentes de ameaças, o agente SandBlast recomenda informações acionáveis que podem ajudar na implementação de medidas de remediação.
Como a análise forense ocorre automaticamente, as equipes de resposta de segurança não precisam gastar horas criando as informações desde o início. O SandBlast Agent permite que essas equipes trabalhem com eficiência e lidem com as ameaças à medida que elas surgem.
SandBlast Agent Forensic Analysis
Implementação SandBlast
A SandBlast oferece negócios em implementação com base nas necessidades, estrutura e requisitos de negócios individuais. Você pode usar um dispositivo SandBlast dedicado, onde ThreatEmulation e ThreatExtraction são feitos em um ambiente de nuvem privado e seguro ou combinado com SandBlast Cloud.
O proteção CheckPoint SandBlast Zero-Day pode ser implementada como:
· Public Cloud Service - SandBlast Cloud.
· Private Cloud - SandBlast Appliance.
· Hybrid Solution - SandBlast Appliance e Cloud.
Public Cloud Service
No SanBlast Cloud ou Public Cloud Service, o sandbox no nível do sistema operacional e a deteção no nível da CPU são feitos em uma infraestrutura de nuvem pública (SandBlast Cloud), que pertence e é operada pela Checkpoint com data centers distribuídos globalmente. Não há necessidade de instalar novo hardware no local. O SandBlasst pode estar instalado e funcionando em poucos minutos.
É possível escolher para qual local da nuvem pública os arquivos devem ser enviados para deteção. Caso não esteja de acordo com os regulamentos de sua empresa, pode-se usar a solução de nuvem privada (Private Cloud). No entanto, isso significa que você precisará ter um dispositivo dedicado no local e os arquivos não sairão da empresa para verificação. A alteração da localização da nuvem pode ser feita por meio do comando tecli.
Private Cloud
Na solução de Private Cloud, o sandboxing a nível do sistema operacional e a deteção no nível do CPU são feitos no dispositivo Checkpoint SandBlast e implantados em uma nuvem privada - dentro da rede do cliente. A opção do Appliance SandBlast é melhor para organizações que têm uma política contra o envio de um arquivo para fora da rede corporativa. Um Appliance SandBlast possui as Blades Antivírus, Anti-Bot, Threat Extraction e Threat Emulation; no entanto, é altamente recomendável usá-lo apenas para sandbox no nível do sistema operacional e detecção no nível da CPU.
Hybrid Solution (SandBlast Appliance an Cloud)
Em uma Hybrid Solution, sandbox no nível do sistema operacional e detecção no nível da CPU são realizadas em conjunto em ambas infraestruturas, Private e Public Cloud. Os administradores podem escolher quais arquivos emular localmente no Appliance SandBlast ou na SandBlast Cloud (pública).
Essa configuração é ideal para empresas com uma arquitetura distribuída, em que a maioria de seus funcionários trabalha em um ambiente da sede regional ou global, enquanto outros trabalham em vários escritórios satélite. Com uma solução híbrida, a organização pode implantar um Appliance SandBlast em sua sede e oferecer suporte a escritórios satélites usando o SandBlast Cloud.
Em uma solução híbrida, as tarefas de prevenção de ameaças são distribuídas da seguinte forma:
· Os Checkpoint Security Gateways executam funções NGTP tradicionais (Anti-BOT, Antivirus e Anti-Spam) e também atua como um MTA para reter emails.
· Threat Extraction pode acontecer no Security Gateway ou no Appliance SandBlast.
· O Threat Emulation com sandboxing no nível do sistema operacional e detecção no nível da CPU ocorre no Appliance SandBlast ou na SandBlast Cloud.
Uma arquitetura distribuída é uma maneira eficiente de utilizar a solução CheckPoint SandBlast. No entanto, ele traz o desafio de provisionar e gerenciar vários MTAs. O CheckPoint User Center pode ajudar os clientes com essas arquiteturas de segurança complexas.
SandBlast Mobile
SandBlast Mobile identifica ameaças em dispositivos móveis por usar algoritmos baseados no dispositivo, rede e nuvem. Uma vez que uma ameaça é detetada, desencadeia uma resposta automática para manter os dados do dispositivo em segurança.
SandBlast Mobile pode analisar comportamento através de diversos vetores de ataque, nomeadamente:
· OS-Level Exploits - Estes exploits tem como alvo o sistema operacional dos dispositivos móveis. Sandblast mobile examina o dispositivo por qualquer sinal de fraqueza, tais como vulnerabilidades de versões Open SSL (para Android) ou certificados CA, proxy, ou configuração VPN (para Apple).
· Mobile Application Malware - São códigos maliciosos escondidos em aplicações.
· Network Attacks - São ataques que ocorrem em conexões de rede. SandBlast Mobile deteta ataques Man in the Middle (MiTM) em Wi-Fi hotspots públicos por validar a integridade de uma conexão SSL. Ele também verifica a segurança das conexões usando um honeypot baseado em nuvem que deteta se um agente malicioso usa um ataque MiTM para interromper uma conexão.
· SMS Phishing - Também conhecido como Smishing, este vetor de ataque usa sistemas de Short Message Service (SMS) para enviar mensagens de texto para persuadir os usuários de dispositivos móveis a divulgar informações pessoais, como senhas, CPF e detalhes de cartão de crédito. A solução SandBlast Mobile pode detetar golpes de phishing de SMS examinando as mensagens SMS de entrada em busca de URLs maliciosos.
Além de proteger destes vetores, o SandBlast Mobile emprega sua própria sandbox dinâmica baseada em nuvem para examinar e revelar as vulnerabilidades e explorações ocultas em aplicativos móveis. Ele também coloca na whitelist aplicativos confiáveis que mostram comportamentos tipicamente associados a ameaças móveis. Para colocar esses aplicativos na whitelist, ele correlaciona os dados de análise de risco com fatores agregados, como reputação do desenvolvedor do aplicativo, número de downloads e origem do aplicativo. isso permite que os usuários finais baixem osaplicativos de que precisam sem a intervenção da equipe de segurança da empresa.
O SandBlast Mobile é capaz de análises de código avançadas, capturando automaticamente e aplicando engenharia reversa para expor o código e desconstruir fluxos para análise semântica. Isso ajuda a identificar padrões e comportamentos suspeitos.
O SandBlast Mobile também determina pontuações de risco para dispositivos, que são atualizadas regularmente assim que novas descobertas são descobertas. Essa análise contínua fornece às organizações uma imagem atualizada e precisa das ameaças móveis em sua rede, bem como informações detalhadas sobre o que está sendo feito para mitigar esses riscos.
Componentes do SandBlast Mobile
O SandBlast Mobile tem quatro componentes dedicados que trabalham constantemente juntos para proteger os dispositivos móveis e seus dados. A comunicação constante entre estes componentes garante que você seja informado de qualquer atividade suspeita e ameaças ocorrendo no dispositivo. Os componentes são:
· SandBlast Mobile Protect Application
· Behavioral Risk Engine
· SandBlast Mobile Dashboard
· SandBlast Mobile Gateway
Componentes do SandBlast Mobile
The SandBlast Mobile Protect Application
SandBlast Mobile Protect é um aplicativo móvel leve que reúne dados e ajuda a analisar ameaças ao dispositivo móvel. O aplicativo monitora o sistema operacional móvel, as informações do aplicativo e as conexões de rede. Ele também fornece dados para a solução móvel Threat Prevention, que é usada para identificar comportamento suspeito ou malicioso. o aplicativo examina indicadores de risco críticos encontrados nos dados que coleta. Ele não coleta ou examina dados confidenciais, como conteúdo ou arquivos.
Para minimizar o uso de banda e recursos do dispositivo, o SandBlast Mobile Protect efetua algumas de suas analises no próprio dispositivo, enquanto as analises que requerem uso intensivo de recursos são realizadas na nuvem.
Aplicativo SandBlast Mobile Protect
O Behavioral Risk Engine
O Behavioral Risk Engine (BRE) baseado na nuvem recebe informação enviada pelo aplicativo SandBlast Mobile Protect, o qual incluí rede do dispositivo, configuração, integridade do sistema operacional, e metadata relacionada aos aplicativos instalados no dispositivo. Ele aproveita esses dados para realizar uma análise aprofundada de ameaças móveis. Essa análise ajuda a detetar e monitorar possíveis atividades duvidosas no dispositivo.
O BRE gera uma pontuação de risco com base no tipo e na gravidade da ameaça. A pontuação de risco determina se e qual atenuação é necessária para manter o dispositivo e seus dados protegidos. Assim que uma ameaça é identificada, ele aciona o aplicativo SandBlast Mobile Protect para notificar o usuário final sobre o nível de risco e as possíveis ações de mitigação.
O Sandblast Mobile Dashboard
O dashboard baseado na nuvem do SandBlast Mobile ajuda você a gerenciar e monitorar os dispositivos e as políticas. Ele é configurado como uma instância por cliente.
Este painel pode ser integrado a uma solução existente de MobileDevice Management/Enterprise Mobility Management para aplicação automatizada de políticas em dispositivos em risco. Quando integrado, o MobileDevice Management/Enterprise Mobility Management serve como um repositório no qual o painel sincroniza dispositivos e identidades registados.
Usando o painel, você pode registrar novos dispositivos usando informações pessoais, como nome de usuário, endereço de e-mail e número de telefone. As informações pessoais são processadas pelo painel e também podem ser armazenadas no painel.
The SandBlast mobile Gateway
O gateway SandBlast Mobile baseado em nuvem é uma arquitetura multilocatária para a qual os dispositivos móveis são registados. Ele lida com todas as comunicações da solução com dispositivos móveis registados. O gateway também armazena elementos de dados, como o identificador exclusivo do dispositivo registado e certificados de aplicativos que podem ser visualizados por instância do cliente no painel da organização. As informações pessoais não são processadas ou armazenadas no gateway.
SandBlast Mobile Workflow
A solução e os componentes da SanBlastMobile Theat Prevention protegem os dispositivos móveis de malware avançado, spyware, vírus e outras ameaças. Abaixo está um fluxo de trabalho detalhado de como os componentes se juntam:
SandBlast Mobile Components Workflow
1. O aplicativo SanBlast Mobile Protect deteta mudanças em aplicativos ou conexões de rede com possível vulnerabilidade MiTM.
2. O SanBlast Mobile Protect envia artefactos criptografados para o gateway SandBlast Mobile usando SSL.
3. O gateway recebe dados do dispositivo. A lista de aplicativos de processo de gateway é comparada a Application Risk Assessment conhecido com base em application_id.
4. O gateway agrega artefactos de aplicativo para identificação e análise. Ele recupera a cópia do aplicativo online ou do dispositivo se não estiver disponível online.
5. O BRE inicia a análise para identificar o tipo de risco e avaliar a gravidade do risco.
6. O BRE atribui uma pontuação de risco ao application_id específico.
7. Os resultados da análise e os metadados do aplicativo são armazenados no banco de dados BRE. O BRE envia uma pontuação de risco e application_id para o gateway.
8. O gateway avalia risco, pontuação e application_id. Se for malicioso, ele envia um aviso ao The SanBlast MobileDashboard.
9. O painel envia um alerta para o SanBlast Mobile Protect. O painel também alerta o Mobile Device Management/Enterprise Mobility Management da empresa, desde que estejam configurados para isso.