Proteção contra ataques DDoS
O SSG tem a funcionalidade de proteção contra ameaças cibernéticas externas, como ataques DDoS, como o TCP SYN flood. Esses ataques têm o objetivo de esgotar os recursos do servidor, tornando-o inacessível para usuários legítimos. Eles exploram um mecanismo de estabelecimento de conexão TCP conhecido como handshake de três vias/triplo.
Como funciona o ataque de inundação TCP SYN?
Primeiro, vamos dar uma olhada no mecanismo de conexão TCP:
- SYN (Sincronizar): O cliente envia um segmento SYN para o servidor, solicitando que uma conexão seja estabelecida.
- SYN-ACK (Synchronize-Acknowledge): O servidor responde ao cliente com um segmento SYN-ACK, confirmando o recebimento do SYN e solicitando uma confirmação do cliente.
- ACK (Acknowledge): O cliente envia um segmento ACK para o servidor confirmando o recebimento do SYN-ACK e a conexão é considerada estabelecida.
Em um ataque DDoS de inundação TCP SYN, o invasor envia várias solicitações SYN ao servidor de destino usando uma rede de um grande número de dispositivos infectados (de PCs e servidores a dispositivos de IoT e consoles de jogos), também conhecidos como botnet. Ao usar uma botnet, o invasor não precisa ocultar os endereços IP de cada dispositivo na rede.
O servidor responde a cada solicitação com um segmento SYN-ACK e aguarda uma confirmação ACK do cliente. Como nenhuma confirmação é recebida, o servidor mantém a conexão aberta por um determinado período de tempo (geralmente alguns segundos) até que o tempo limite expire. Como o número de conexões simultâneas é limitado, o servidor preenche rapidamente seu pool de conexões, tornando-o inacessível a usuários legítimos.
Proteção contra ataques DDoS de inundação TCP SYN com base em SSG: um estudo de caso prático
O sistema de proteção contra DDoS de inundação TCP SYN baseado em SSG é amplamente usado por data centers e provedores de nuvem. Vamos analisar como esse sistema foi organizado em um dos maiores data centers russos.
Para testar o complexo SSG, a seguinte configuração foi organizada na bancada de teste:
- RTR1 (roteador Juniper MX204) – usado como ASBR (roteador de borda de sistema autônomo).
- RTR2 (roteador Juniper MX204) – usado como roteador de acesso
- MPLS está configurado entre RTR1 and RTR2
- Client-1 (roteador Mikrotik RB951Ui 2HnD) – emula um host na Internet e atua como uma fonte de conexões legítimas.
- Client-2 (CRS305-Roteador 1G-4S+IN) – emula um cliente na rede do data center e atua como receptor de tráfego legítimo e ilegítimo (vítima).
- Client-1 and Client-2 são conectados aos roteadores por meio de switches (não mostrados nos diagramas para simplificar).
- A interface RTR1 à qual o Cliente-1 está conectado é considerada uma interface de Uplink
- As seguintes regras estão configuradas na RTR1 :
- flowspec redirect-to-next-hop – uma regra para redirecionar o tráfego de encaminhamento em direção à vítima por meio da interface de entrada do filtro.flowspec redirect-to-routing-instance – regra para redirecionar o tráfego de retorno da vítima por meio da interface de saída do filtro.
- flowspec redirect-to-routing-instance – uma regra para redirecionar o tráfego de retorno da vítima por meio da interface de saída do filtro.
- O complexo de proteção contra DDoS da VAS Experts SSG é usado para limpeza de tráfego, operando no modo L2.
Layout da rede na ausência de ataques ativos:
No momento em que o ataque começa, o tráfego legítimo é trocado entre o Cliente-1 e o Cliente-2.
O esquema do fluxo de tráfego no momento do início do ataque:
Após o início de um ataque de inundação TCP SYN do Perpetrador (host mal-intencionado) com diferentes endereços de origem falsificados, em cerca de 20 a 25 segundos, o tráfego, tanto legítimo quanto mal-intencionado, flui diretamente pelo roteador até a vítima.
Quando o tráfego de ataque excede os limites definidos na taxa de bits ou na taxa de pacotes, após cerca de 20 a 25 segundos, uma regra de redirecionamento para o próximo hop (manualmente ou anunciada por meio de automação e BGP) aparece no ASBR do RTR1, redirecionando o tráfego através da interface RTR1 para o SSG.
Esquema de passagem de tráfego no modo de proteção:
Se o ataque parar ou sua intensidade diminuir abaixo dos valores de limite, a regra do flowspec será removida (manualmente ou por meios de automação) e o tráfego deixará de passar pelo filtro.
Resultados do teste
A imagem real mostrou o redirecionamento bem-sucedido de todo o tráfego, tanto legítimo quanto mal-intencionado, destinado ao cliente vítima. Ao mesmo tempo, todo o tráfego mal-intencionado de ataques de inundação TCP SYN de até 360 Mbps foi bloqueado com êxito.
Tanto nos testes sintéticos quanto no tráfego real do produto, os serviços legítimos protegidos entre o cliente e a vítima funcionaram corretamente. No momento em que o tráfego foi transferido para o filtro, os serviços com conexões já estabelecidas continuaram a funcionar de forma estável.
Quando o tráfego foi removido do dispositivo, as sessões TCP relacionadas a recursos protegidos que foram estabelecidas por meio dele durante o ataque foram interrompidas. Já as sessões estabelecidas por meio do filtro, mas não relacionadas às portas protegidas, não foram interrompidas.
Monitoramento de atividade de vírus com base no QoE Analytics e na Kaspersky Lab
Feeds de dados de ameaças da Kaspersky e módulo de análise de tráfego de qualidade de experiência (QoE) do SSG do SSG foram combinados para criar uma solução altamente eficaz para analisar e combater as ameaças cibernéticas.
O Kaspersky Threat Data Feeds é um banco de dados estruturado, constantemente atualizado e volumoso de vários tipos de ameaças cibernéticas, como ataques DDoS, sites de phishing, redes de botnets, spam e outras influências maliciosas. Há 16 tipos de feeds no banco de dados, dos quais o SCAT lida com sete tipos principais:
- URL malicioso
- URL de phishing
- Botnet C&C
- Botnet Móvel
- Reputação de IP
- URL de ransomware
- Dados de URL de IoT
Usando rastreadores proprietários, armadilhas de spam e sistemas de monitoramento de botnet, o Kaspersky Threat Data Feeds testa, analisa e coleta dados sobre todas as ameaças cibernéticas conhecidas atualmente em uma única referência.
Para implementar uma solução colaborativa, uma cópia sincronizada do banco de dados de ameaças é hospedada em um servidor com estatísticas de comportamento do usuário. As estatísticas de comportamento do usuário no SCAT são então comparadas com o banco de dados de ameaças, permitindo que sejam tiradas conclusões sobre possíveis ameaças na rede do data center.
Benefícios da integração do Kaspersky e dos especialistas em VAS
- Identificação de usuários com atividade de vírus.
- Detecção de botnets em um estágio inicial.
- Determinação do grau de infecção da rede.
- Criar uma lista de ameaças identificadas e usuários infectados para o administrador da rede.
Quando a rede estiver infectada, o administrador da rede poderá resolver os problemas de forma rápida e eficiente com o SCAT:
- Restringir ou bloquear usuários usando políticas em dispositivos de rede.
- Baixar dados sobre usuários infectados para processamento por especialistas em suporte técnico.
Assim, a integração do Kaspersky Threat Data Feeds e da plataforma SSG da VAS Experts é uma ferramenta poderosa para monitorar e combater ameaças cibernéticas em redes de data centers. Graças à profunda sincronização dos dados sobre ameaças cibernéticas com as estatísticas comportamentais dos usuários, esse sistema oferece um alto nível de proteção, identificando rapidamente ameaças em potencial, como atividade de vírus e botnets, nos estágios iniciais. Isso permite que os administradores de rede respondam aos incidentes em tempo hábil, minimizando os riscos e evitando a disseminação de malware na rede. Portanto, a implementação dessa solução ajuda a melhorar a segurança nas redes corporativas e a reduzir os riscos associados a ataques cibernéticos.
Monitoramento da integridade da rede com módulo de análise de QoE
O monitoramento das condições da rede permite detectar, por exemplo, problemas com a disponibilidade de serviços para os usuários, como mau funcionamento ou sobrecarga de aplinks upstream, bem como a operação lenta ou a indisponibilidade de serviços sem conhecimento on-line especial.
Vamos considerar um caso real de aplicação do módulo de análise de QoE por um dos maiores data centers para monitorar o estado de sua própria rede e otimizar o roteamento do tráfego.
Descrição da conexão de QoE
O tráfego da infraestrutura virtual do cliente foi direcionado por meio do espelho para a porta BareMetal do servidor com o SSG. A tarefa do SSG era coletar estatísticas sobre o protocolo NetFlow v10, usando campos personalizados, incluindo informações de RTT e retransmissão para sessões TCP. As estatísticas coletadas foram alimentadas em uma máquina virtual onde o módulo de coleta de estatísticas do QoE Stor foi implantado.
Resultados do teste
Verificação se o compartilhamento de retransmissão corresponde às perdas configuradas manualmente no host.
Para o teste, foi usado um host no qual o Linux TC foi usado para definir parâmetros que descartam artificialmente 30% do tráfego de entrada na interface. Como resultado do teste, a análise de QoE mostrou 30% de retransmissões e os valores RTT correspondentes.
Melhorar a conectividade do host com o redirecionamento do tráfego
Um dos hosts estava sofrendo retransmissões em uma sessão TCP. Às 13:00, a rota de tráfego de saída para o prefixo problemático foi alterada, resultando no desaparecimento das retransmissões e em uma diminuição do RTT. Essas métricas também foram confirmadas pelas estatísticas obtidas do QoE.
Mudanças claras no caminho do tráfego podem ser vistas nas ilustrações abaixo.
Before
After
Assim, a funcionalidade do módulo QoE permite identificar gargalos na rede e pode ser usada para monitoramento a fim de identificar e lidar proativamente com áreas problemáticas em tempo hábil. Usando a API, é possível integrar o SSG a um sistema de monitoramento existente para controlar os momentos de degradação da conectividade na rede.
