Kaspersky NGFW no Projeto "NUVEM": Implantação e Configurações Iniciais [Parte 2]

Na primeira parte do artigo sobre o KNGFW, exploramos como montar o circuito de gerenciamento, conectar os componentes e obter uma base funcional. No entanto, nessa etapa, o NGFW ainda permanece como um "hardware corretamente montado". Ele está pronto para operar, mas por si só ainda não protege nada.

Neste artigo, começa a parte mais interessante: o momento em que o dispositivo começa a "ganhar vida". Regras reais são implementadas, o tráfego flui não mais em modo de teste, mas em modo de produção, e o próprio sistema se transforma de um conjunto de componentes em um elemento completo da infraestrutura.

A partir daqui, o material será o mais prático possível. Primeiro, montaremos a configuração básica: rede, acessos, NAT, logging, integrações. Tudo o que sustenta o trabalho diário. Em seguida, passaremos aos módulos de segurança e à tarefa para a qual o NGFW é implementado.

Configuração do KNGFW: Configuração Básica, Integrações e Módulos de Segurança Essenciais

Após a implantação do circuito de gerenciamento, os dispositivos são adicionados ao sistema, os templates são preparados e a lógica de cluster é colocada em operação, podemos passar para a próxima grande etapa — a configuração direta do KNGFW. É aqui que a solução começa a ser percebida não apenas como um nó de hardware, mas como um firewall de rede completo, integrado à infraestrutura e pronto para a operação diária.

Esta seção pode ser logicamente dividida em duas partes. Primeiro, faz sentido percorrer a configuração básica, sem a qual o trabalho adicional com o dispositivo será incompleto: parâmetros de rede, políticas de filtragem, NAT, integração com SIEM externo, logging e monitoramento. Este é o alicerce sobre o qual toda a lógica de proteção da solução será construída.

O próximo passo são os principais módulos de segurança que estão disponíveis no KNGFW na fase atual de desenvolvimento do produto. Aqui, é importante enfatizar separadamente que o KNGFW é amplamente percebido como uma solução baseada em perfil, ou seja, a lógica de proteção é construída não apenas nas próprias regras de acesso, mas também em conjuntos de perfis de segurança que são então vinculados às políticas de rede. Essa abordagem é bem conhecida por aqueles que já trabalharam com NGFWs modernos: primeiro, os próprios perfis são criados e configurados, depois são combinados com regras de filtragem e aplicados aos cenários de tráfego necessários.

Configuração Básica do KNGFW

Antes de passar aos mecanismos de proteção, é importante levar a configuração operacional básica do dispositivo a um estado de funcionamento. Na prática, é esta etapa que determina o quão confortavelmente o KNGFW viverá na infraestrutura no futuro, ou seja:

• quão previsivelmente as regras serão aplicadas;
• como será a publicação de serviços;
• para onde irão os eventos de segurança;
• como o suporte da solução será organizado em geral.

Simplificando, aqui estamos configurando não "ciberproteção em sua forma pura", mas a camada sem a qual a própria proteção não poderá funcionar totalmente em um ambiente de produção. Portanto, em primeiro lugar, vale a pena percorrer consistentemente a parte de rede, as regras do firewall, NAT, logging e integração com sistemas de monitoramento e análise de eventos.

Após a conclusão da implantação, o trabalho principal é transferido para a interface de gerenciamento centralizada.

É aqui que os objetos, zonas, regras de filtragem, políticas NAT, perfis de segurança e parâmetros de interação com sistemas externos serão criados.

Configuração de Roteamento e NTP

Com o roteamento, tudo é bastante claro aqui: nesta etapa, as rotas são definidas nos templates através das quais o KNGFW alcançará redes externas e segmentos de serviço internos, incluindo o circuito de gerenciamento, a camada de backend e os sistemas de monitoramento.

De um ponto de vista prático, este é um ponto importante por dois motivos:

• Primeiro, é do roteamento correto que depende a disponibilidade do KSC, KNBE e todos os sistemas externos com os quais o KNGFW deve interagir.
• Em segundo lugar, problemas neste nível muitas vezes parecem "o template não funciona", "os eventos não chegam" ou "o backend não se conecta", embora a causa real esteja na conectividade e na tabela de rotas.

Junto com o roteamento, é lógico configurar o NTP imediatamente. À primeira vista, isso parece um detalhe secundário do sistema, mas em operação, a hora em um dispositivo de rede é a base para logs corretos, correspondência de eventos, operação do SIEM, análise de incidentes e suporte técnico normal. Se a hora no NGFW divergir do resto da infraestrutura, a investigação até mesmo de incidentes simples leva rapidamente a trabalho manual desnecessário.

Portanto, é melhor não adiar o NTP "para depois", mas incluí-lo imediatamente na configuração básica. Na prática, isso significa que, mesmo antes de passar para as regras de segurança, o dispositivo já deve ter:

• conectividade de rede correta para fontes NTP;
• um esquema de roteamento claro para tráfego de gerenciamento e serviço;
• tempo sincronizado, que será usado em logs de sistema e segurança.

Configuração de Rede e Objetos

O próximo passo é preparar as entidades de rede que serão usadas em regras e perfis. Isso inclui objetos de endereço, grupos de objetos, serviços, zonas de segurança, interfaces.

O significado desta etapa é simples: quanto mais cuidadosamente a base de entidades for montada aqui, mais fácil será manter a política de firewall no futuro. Se você concordar desde o início com uma estrutura clara de objetos, nomenclatura de zonas e lógica de serviços, a configuração subsequente será lida muito mais facilmente e as próprias alterações serão feitas de forma mais previsível.

É neste nível que a conveniência da operação é estabelecida. Ou seja, no futuro, o engenheiro não trabalhará mais com "endereços IP e portas brutos", mas com objetos compreensíveis e grupos lógicos, a partir dos quais as regras de acesso e as políticas de segurança são então montadas.

Configuração de Zonas

Depois que as interfaces básicas e os objetos de rede são preparados, é necessário configurar as zonas. Na operação prática, este é um dos elementos-chave da configuração, porque são as zonas que se tornam a base para as regras do firewall, políticas NAT e parte da lógica de proteção.

Simplificando, uma zona é uma associação lógica de interfaces com a mesma função na política de segurança. Essa abordagem é conveniente porque permite construir regras não a partir de uma porta física específica, mas a partir de uma função de rede compreensível: por exemplo, uma zona externa, uma zona interna, DMZ, um segmento de gerenciamento ou sub-redes tecnológicas separadas. Como resultado, a política se torna mais legível, é dimensionada mais facilmente e não requer reconstrução constante quando interfaces individuais são alteradas.

Na prática, é melhor não perceber esta etapa como uma formalidade. Se as zonas forem montadas de forma imprecisa desde o início, isso quase sempre se reflete em toda a configuração: as regras se tornam menos transparentes, o NAT começa a ser lido pior e a lógica de acesso entre os segmentos perde rapidamente a clareza. Portanto, é melhor aderir imediatamente a um esquema simples e reproduzível: um segmento semântico - uma zona com um nome compreensível e uma função previsível na política.

Na próxima etapa, são as zonas que se tornam uma das principais entidades de suporte para configurar as regras de FW. Portanto, é conveniente considerá-las como uma camada intermediária, mas muito importante, entre a configuração básica de rede e a própria política de segurança.

Políticas de Firewall (FW)

Depois de preparar os objetos, você pode passar para a política de rede clássica - as regras do firewall. Aqui, tudo é organizado de forma bastante familiar: a origem e o destino, zonas, serviços, ação da regra, bem como parâmetros de logging e vinculação de mecanismos de proteção adicionais são determinados.

Do ponto de vista da lógica, o KNGFW é uma camada importante, porque é através dela que os perfis de segurança são então "conectados". Ou seja, a regra do firewall aqui não apenas desempenha o papel de um clássico allow/deny, mas também se torna um ponto de aplicação da lógica de proteção. Por exemplo, inspeção SSL, IDPS, verificação antivírus e outros módulos.

Do ponto de vista da pessoa que configura tudo, isso é conveniente. A política de acesso básica e a segurança não vivem separadas, mas são montadas em um esquema operacional unificado. Ao mesmo tempo, as próprias regras permanecem compreensíveis e legíveis, especialmente se os objetos, zonas e serviços forem preparados com cuidado com antecedência.

NAT e Publicação de Serviços

O próximo bloco obrigatório é o NAT. Na operação diária, geralmente é responsável por publicar serviços internos em redes externas ou por traduzir o tráfego de saída quando usuários e sistemas acessam a Internet.

No KNGFW, as configurações de NAT são praticamente as mesmas que em outros dispositivos de rede. Para publicar serviços internos, o DNAT é usado: o endereço ou interface externa, o serviço necessário e o nó interno para o qual o tráfego deve ser transferido são definidos.

Para acesso de saída, o SNAT padrão ou mascaramento é usado, dependendo do esquema de endereçamento e da lógica de saída para a rede.

É importante que o NAT aqui não seja considerado isoladamente do resto da política. Na prática, a publicação ou tradução de saída quase sempre é verificada em conjunto com as regras de firewall, zonas e serviços. Portanto, ao diagnosticar, você precisa observar não apenas se o tráfego é permitido pela própria regra FW, mas também qual regra NAT acabou sendo aplicada a ele.

Integração com SIEM e Monitoramento

Um bloco importante separado na configuração básica é a integração do KNGFW com o SIEM. No mundo real, esta não é uma opção adicional, mas uma parte obrigatória da introdução da solução à operação normal. Sem ele, o firewall pode e irá processar o tráfego corretamente, mas permanecerá "cego" do ponto de vista do suporte, investigação e controle do que está acontecendo.

Portanto, quero mostrar como a transmissão de logs e eventos de segurança do KNGFW para um SIEM externo é organizada. Normalmente, no início, o maior interesse é representado por eventos do sistema, logging de regras de firewall, acionamentos de módulos de proteção e eventos relacionados a mudanças críticas no estado do dispositivo.

É importante separar os eventos do sistema e os eventos de segurança.

• Os eventos do sistema descrevem o estado do próprio KNGFW: operação de serviços, mudanças de configuração, estado de interfaces, cluster e outros componentes de serviço.
• Os eventos de segurança já se referem ao processamento de tráfego: acionamentos de regras FW, IDPS, inspeção SSL/TLS, antivírus, DNS Security e outros mecanismos de proteção.

Simplificando, os eventos do sistema respondem à pergunta "o que está acontecendo com o dispositivo?", e os eventos de segurança - à pergunta "o que está acontecendo com o tráfego e como o KNGFW está reagindo a ele?"

Monitoramento do Estado do Dispositivo

Além de enviar eventos de segurança para um SIEM externo, é útil fechar imediatamente a segunda tarefa operacional - monitorar o estado técnico do próprio dispositivo. Implementamos esta parte usando o Zabbix. Se o SIEM é mais responsável pela análise de logs e eventos de segurança, então o Zabbix neste esquema é conveniente precisamente como uma camada de monitoramento diário. Ele permite rastrear a saúde do nó, o estado das interfaces, a carga e a imagem operacional geral.

É conveniente que o template de monitoramento para o Zabbix esteja incluído na entrega da solução, portanto, não é necessário coletar toda a lógica de monitoramento do zero aqui. Isso simplifica significativamente o início. O conjunto básico de métricas e entidades para monitoramento já foi preparado pelo fornecedor e só precisa ser aplicado corretamente em seu sistema. Graças a isso, conectar o KNGFW ao Zabbix parece claro e não requer nenhuma integração não padrão.

Do ponto de vista técnico, a própria configuração também não causa dificuldades, pois é construída em um esquema bastante familiar através do SNMP. Ou seja, os parâmetros de acesso SNMP são preparados no lado do KNGFW, após o qual o dispositivo é adicionado ao Zabbix usando o template de monitoramento padrão.

Devido a isso, a solução é rapidamente integrada ao circuito de monitoramento existente e começa a retornar as métricas operacionais necessárias.

O valor prático aqui é que o monitoramento permite notar um problema antes que ele se transforme em um incidente de segurança completo ou falha de serviço. Por exemplo, degradação de link, estado instável da interface, aumento da carga, problemas com conectividade de serviço ou desvios na operação do cluster. É mais conveniente ver tudo isso precisamente no sistema de monitoramento, e não tentar coletar post factum de diferentes logs.

Portanto, recomendo perceber o Zabbix aqui não como "mais uma ferramenta adicional", mas como uma parte obrigatória da fiação operacional do KNGFW. Como resultado, a imagem se torna completa:

• O SIEM é responsável por eventos de segurança e logging;
• O Zabbix pela saúde do dispositivo, interfaces e telemetria operacional básica.

Nesta etapa, pode-se considerar que a preparação básica do KNGFW está concluída. Já montamos a parte de rede, configuramos zonas, roteamento, sincronização de tempo, preparamos regras de acesso, NAT, logging e circuito de monitoramento. Ou seja, o dispositivo neste momento já não se parece com um bancada de testes, mas como um elemento bastante normal da infraestrutura, que pode ser introduzido de forma significativa na operação.

Módulos de Segurança do KNGFW

Este bloco não é sobre conectividade de rede básica e fiação operacional, mas sobre os mecanismos através dos quais o KNGFW começa a desempenhar precisamente uma função de proteção. Na lógica atual da solução, eles são organizados de acordo com o modelo baseado em perfil: primeiro, os perfis de segurança são criados e configurados e, em seguida, esses perfis são vinculados às regras de acesso necessárias e aplicados ao tráfego correspondente.

Essa abordagem torna a configuração mais estruturada. A política de rede e a lógica de proteção não são misturadas em uma regra sobrecarregada, mas são divididas em dois níveis compreensíveis: as condições para a passagem do tráfego são descritas separadamente, os mecanismos para sua verificação e controle são descritos separadamente. Devido a isso, a configuração é mais fácil de ler, mais fácil de reutilizar e mais conveniente de manter no futuro.

Antes de passar para módulos separados, mostrarei brevemente onde os perfis de segurança estão localizados na interface e como esta seção de configuração se parece em geral.

Depois disso, você pode percorrer consistentemente os módulos que estão disponíveis no KNGFW na fase atual e são de maior interesse prático.

SSL/TLS Inspection

É lógico começar com a inspeção SSL/TLS, porque para muitos outros módulos - este é um elemento básico de visibilidade. Sem descriptografia, uma parte significativa do tráfego moderno permanece "não transparente" para o firewall, o que significa que o controle de aplicativos, parte da lógica de assinatura e uma inspeção mais profunda serão limitados.

No KNGFW, a inspeção SSL/TLS é construída através de configurações separadas na seção de políticas. Na prática, os parâmetros de descriptografia, certificados, regras de aplicação, bem como exceções são definidos aqui. Por exemplo, por categorias de sites ou domínios individuais.

Este é um ponto importante, porque a implementação da inspeção SSL quase sempre requer um equilíbrio cuidadoso entre a profundidade do controle e a estabilidade operacional: sem exceções, é fácil obter conflitos com recursos bancários, governamentais ou outros recursos sensíveis.

Abaixo, mostrei como as regras de inspeção SSL/TLS se parecem na interface do KNGFW, onde a própria regra de descriptografia é configurada. Vale a pena enfatizar que, como parte de tal regra, é necessário especificar explicitamente o serviço HTTPS (443/tcp). Este é um ponto fundamental, porque é graças a isso que a regra começa a ser aplicada ao tráfego necessário. Se esta etapa for ignorada, a lógica de descriptografia não funcionará da forma esperada.

Depois que a própria regra de inspeção é criada, resta integrá-la à política de acesso real, ou seja, habilitar a descriptografia nas regras através das quais os usuários ou hosts acessam a Internet. Este é um passo importante. Enquanto o perfil não estiver vinculado a uma regra de acesso de trabalho, a inspeção não será realmente usada no tráfego real.

Em seguida, você pode passar para a verificação de desempenho mais simples e visual. Para fazer isso, basta abrir qualquer site e ver qual certificado o navegador vê. Se a inspeção SSL/TLS for aplicada corretamente. Será visível que o certificado foi substituído e o firewall atua como um proxy MITM.

Separadamente, verificamos as exceções para recursos bancários. Como pode ser visto no exemplo, depois de adicionar tal categoria à lista de exceções, o certificado não é mais substituído, ou seja, o tráfego é processado corretamente sem inspeção SSL/TLS.

Tudo o que foi feito acima é a base para um trabalho adicional com cenários de segurança "ricos". É ele que dá a oportunidade de ver o tráfego aplicado mais profundamente e aplicar a ele o resto dos mecanismos de controle não às cegas, mas com uma inspeção completa do conteúdo.

IDPS

Antes de passar para o próprio módulo, vale a pena indicar brevemente a mecânica geral. No KNGFW, as principais funções de proteção são configuradas através de perfis de segurança. É aqui que toda a lógica aplicada será coletada.

Para não sobrecarregar a análise, para familiarização, mostraremos este esquema em um perfil geral. Em seu exemplo, será mais fácil percorrer consistentemente cada módulo. E começaremos com o IDPS.

O IDPS é configurado com um perfil separado e, em seguida, vinculado às regras de filtragem correspondentes. Em nosso cenário, estávamos olhando não apenas para o fato do acionamento, mas também para o quão logicamente os eventos parecem no log e no SIEM.

O mais importante são os testes. Tentamos não "quebrar o bancada", mas verificar com cenários semelhantes aos reais:

• Tunelamento DNS (com base na ferramenta DNSlivery);
• vários cenários CVE no nível da camada web HTTP para verificar a parte da assinatura e a reação às tentativas de exploração.

Em nosso SIEM, cuja interação analisamos um pouco acima, isso se parecia com isto:

A impressão do módulo em geral permaneceu positiva. Ele é rapidamente colocado em operação, dá um resultado compreensível e já no início fecha a necessidade básica de proteção de assinatura de tráfego. Ao mesmo tempo, na operação prática, não tivemos flexibilidade suficiente. Acima de tudo, na parte de configuração de assinaturas, seleção de seu conjunto para cenários específicos e a capacidade de adicionar os seus próprios.

Ao mesmo tempo, o próprio vetor de desenvolvimento parece promissor aqui. Tanto quanto entendemos, o trabalho nesta parte já está em andamento e, em um futuro próximo, o produto deve ter uma configuração de assinatura mais flexível. Isso tornará o módulo visivelmente mais forte para cenários de operação mais maduros e em larga escala.

Antivirus

O módulo antivírus KNGFW é logicamente considerado como a próxima camada de proteção. Já não apenas no nível das interações de rede, mas também no nível dos próprios objetos transmitidos. Na operação real, isso é importante acima de tudo para cenários de download de arquivos, acesso web e verificação básica de conteúdo malicioso que passa pelo firewall.

O bloco antivírus no KNGFW verificamos tanto no modo de fluxo quanto no modo de objeto. As assinaturas são puxadas através do KSN, e em um cenário típico, este é precisamente o nível de "higiene básica" que você espera do NGFW. Arquivos maliciosos e recursos suspeitos devem ser cortados antes de atingir os hosts.

Toda a configuração também ocorre através do perfil deste módulo.

Para verificação, usamos o arquivo EICAR clássico. Na primeira vez, o NGFW bloqueia o download e, na segunda tentativa, exibe uma página de bloqueio (se a exibição da página estiver habilitada).

Pode-se ver que o módulo funciona de forma estável e previsível. Adicionalmente, verificamos as categorias de URL "malware" e "phishing" em páginas de teste e também obtivemos o resultado esperado.

Também não se esqueça das exceções. O perfil antivírus permite excluir a verificação para URL/IP específicos (dentro de limites razoáveis). Isso é útil quando existem repositórios internos confiáveis, integrações específicas ou serviços que sofrem de falsos positivos. Tais exceções ajudam a reduzir a carga e evitar surpresas para processos de negócios críticos.

O próximo passo na forma de integração da parte antivírus com o KATA Sandbox também vale a pena prestar atenção. Em nossa configuração, não chegamos a isso, mas em um circuito de nuvem, tal cenário parece promissor. Objetos suspeitos podem ser enviados para a sandbox para um veredicto comportamental e, com base nele, bloquear ou permitir.

DNS Security

Outro módulo importante é o DNS Security. À primeira vista, pode parecer mais "pontual" do que a inspeção SSL ou IDPS, mas na prática, ele fecha um cenário muito compreensível e aplicável na prática - controle de tráfego DNS e restrição de acesso a recursos maliciosos ou indesejáveis já na fase de resolução de DNS.

No KNGFW, este módulo também se encaixa organicamente no modelo geral de perfis de segurança. Ele permite inspecionar solicitações e respostas DNS e, dependendo da política, bloquear o acesso a recursos problemáticos ou redirecioná-lo para cenários de sinkhole.

A configuração levou literalmente alguns minutos: habilitar o DNS Security, definir a política de reação e especificar o endereço do sinkhole (se o redirecionamento for usado).

Na operação, o módulo funciona de forma bastante transparente. As principais questões geralmente se resumem a qual tráfego DNS estamos passando pelo NGFW (todos os resolvedores/clientes estão sujeitos à inspeção) e como queremos lidar com exceções para domínios internos.

WEB Control

Outra etapa importante é o controle web. Essencialmente, estamos falando de um mecanismo de filtragem de URL que permite gerenciar o acesso a recursos web indesejáveis, irrelevantes ou potencialmente arriscados. De um ponto de vista prático, esta é uma ferramenta conveniente não apenas para restringir o acesso básico a certas categorias de sites, mas também para um cenário mais cuidadoso, quando um aviso é mostrado primeiro ao usuário e, em seguida, uma decisão é tomada sobre a concessão de acesso.

Na prática, a configuração começa com a criação de um novo perfil de controle web na seção já familiar. Seu nome é definido aqui e, se necessário, o uso do KSN é habilitado para uma categorização mais precisa dos objetos. Depois disso, você pode passar para o conteúdo principal do perfil - ações para categorias de URL.

Como exemplo, você pode usar dois cenários bastante reveladores. Para a categoria de redes sociais, é conveniente definir uma ação de aviso. Neste caso, o usuário não é bloqueado imediatamente ao abrir um recurso, mas cai em uma página de aviso, onde pode tomar uma decisão consciente sobre continuar. Este é um cenário suave e bastante prático, quando o acesso não é estritamente proibido, mas o próprio fato de acessar tal categoria ainda é registrado e se torna visível nos logs.

Para a segunda categoria, por exemplo, procura de emprego, você já pode definir uma reação mais estrita e exibir uma página de bloqueio. Esta opção é adequada para aqueles casos em que o acesso a uma determinada classe de recursos deve ser totalmente restrito, sem a possibilidade de contornar através de uma página de aviso. Separadamente, é útil habilitar o logging para que os acessos a essas categorias entrem no log e possam ser analisados posteriormente no circuito geral de monitoramento.

Depois de preparar o próprio perfil, você não deve esquecer de incluí-lo no grupo de perfis de segurança, bem como adicionar a verificação de tráfego para a regra de saída para a Internet.

A verificação do funcionamento do módulo parece bastante simples. Por exemplo, ao abrir vk.com, se o site cair na categoria de redes sociais, o usuário é redirecionado para uma página de aviso. Nesta