Sobre a Arbor
Falando um pouco de Arbor, a mesma nasceu nos EUA na cidade de Boston, dentro da universidade de Anarbor. Isso após um desafio feito pelo governo deste país no que desrespeito a um problema de negação de serviço em seus sistemas. Em 2000 a Arbor lançou o 1º produto no mercado que tratava os problemas de DDoS e DoS, este chamado de PeakFlow.
Peakflow
O PeakFlow é dividido, basicamente em 2 módulos, são eles:
SP - Esse cara faz o monitoramento dos roteadores e rotas do provedor ou telecom. Os roteadores (cores ou edges) enviam para o PeakFlow SP: Flow (Netflow, Jflow, etc), SNMP e as tabelas BGP. Com esses dados, temos todas as informações de tráfego do provedor ou telecom, como: rotas congestionadas, relacionamentos ente ASN’s, gargalos, consumo de link, conexões de peering, consumo de serviços e usuários. Isso ajuda muito a descobrir problemas de congestionamento, melhores empresas para se comprar Link para fazer aquisição, custo de links para usuários finais, possível implementação de caches como Google, Facebook ou Netflix dentro do provedor e etc. Com isso também fica fácil de identificar um ataque de negação de serviço volumétrico. Quando isso é detectado entra o segundo módulo do PeakFlow, este chamado de Peakflow TMS.
TMS - Este cara é um apliance que recebe o tráfego “sujo”, mitiga e reinjeta na rede o tráfego limpo. A grosso modo as tabelas BGP’s dos roteadores são alteradas e o PeakFlow TMS é colocado um “hop” a frente do roteador que está recebendo o ataque e com isso ele consegue limpar o tráfego e o próximo “hop” atrás do Peakflow TMS é o roteador do cliente que está recebendo o ataque. Abaixo uma imagem que fica mais claro como funciona esta limpeza.
O Peakflow é um produto voltado para provedor e telecom. Hoje grande operadoras do Brasil e do mundo tem Peakflow para fazer: Engenharia de Tráfego e limpeza dos seus links.
Em 2012, a Arbor viu que os ataques de negação de serviços ficaram muito mais sofisticados, ou seja, deixaram de ser “talagadas” de requisições que deixa o link congestionado, e passaram a ser mais sutis, ao ponto de pacotes muito pequenos (menores que 10 Mb as vezes) fazerem estragos muito grandes a serviços como HTTP, DNS, FTP, etc. Esses pacotes passam imperceptíveis por soluções que analisam Flow para descobrir comportamentos suspeitos. Principalmente em ambientes de provedores / telecom que utilizam o sistema de “amostragem de flow” para tornar ações de mitigação. Isso faz com que os clientes de provedores / telecom, recebam o ataque e tenham seus serviços comprometidos e indisponíveis.
Como sabemos a tríplice da segurança, conhecida como CID (Confidêncialidade, Integridade e Disponibilidade) passa a ter a perna da disponibilidade comprometida em ataques de negação de serviços. Equipamentos como Firewall, IPS e IDS tem a perna da disponibilidade comprometida por serem equipamentos que adotam tecnologias STATEFUL, ou seja, utilizam tabelas de estados para armazenar dados, ter informações e logo após tomar ações como : BLOQUEAR, onde nem sempre o a ação de bloquear é a solução ideal para ataques DDoS ou DoS, sento assim a ação de MITIGAR é a mais recomendada, pois esta ação reduz os índices de FALSO/POSITIVO de 60% a 70% (firewall, IPS e IDS - STATEFUL ) para 3% a 4% (STATELESS) em situações extremas de ataque. Sendo assim, Firewall, IPS e IDS são equipamentos voltados e desenhados para Integridade e Confidêncialidade (CID), eles fazem muito bem este papel mas quando diz respeito a disponibilidade… infelizmente são péssimos, pois eles acham que é melhor deixar o ambiente indisponível para a internet do que comprometido e ser invadido, típico de soluções que se preocupam com confidêncialidade e integridade. Existe alguns fabricantes que para não comprometer a disponibilidade, criam uma espécie de “bypass" para deixar o serviço disponível, porém desabilitam algumas funcionalidades de são responsáveis pela confidêncialidade e integridade.
Pravail APS
Baseado nesta mudança da forma de ataque e na CID (Confidêncialidade, Integridade e Disponibilidade), a Arbor, criou um produto chamado PRAVAIL APS, este ficando entre o roteador de borda e o firewall do cliente final do provedor / telecom. O Pravail APS é um equipamento focado na disponibilidade, ou seja, desenhado com arquitetura STATELESS, o que não compromete o próprio equipamento no que se refere a processamento e memória em situações extremas de ataque. Com “bypass” de hardware e software, ou seja o mesmo pode ser reiniciado ou até mesmo desligado da energia que não vai comprometer a disponibilidade física dos links de internet, isso é mais um item positivo para garantir 99,9% dos serviços acessíveis e disponível, com isso, fazendo que camadas de confidêncialidade e integridade façam seu papel de forma mais efetiva.
O Pravail APS vai agir mais na camada 7, nas aplicações e serviços disponibilizadas pelo cliente final do provedor / telecom. Ele irá ser mais ‘íntimo” dos servidores WEB, DNS, FTP, VOIP , estudando o comportamento destes serviços e criando “luvas” nos mesmos ao ponto de saber quando o acesso ou o pacote enviado a estes é suspeito ou um acesso lícito. Este tipo de arquitetura contribui para que o problema de FALSO/POSITIVO seja minimizado e muito. Por exemplo, digamos quem uma rede corporativa de computadores tenha algumas máquinas infectadas, e estas estão sendo escravas de um servidor de botnet que está progamado para derrubar o site de um grande varejista, por exemplo americanas.com. Digamos que a americanas.com não tem uma solução focada em disponibilidade e sim apenas em confidêncialidade e integridade (firewall, IPS, IDS, etc), esses equipamentos ao detectarem o IP de origem do ataque comandado pela botnet irá bloquear o mesmo, fazendo assim que usuários desta grande rede, que querem comprar no americanas.com sejam prejudicados, ou seja o número de falso positivo foi muito grande.
Uma solução focada em disponibilidade e STATEFUL não haverá este problema. Isso porque ela MITIGA o pacote e NÃO BLOQUEIA a origem, sendo assim… se um atacante, de uma estação origina um ataque e nessa mesma estão faz um acesso normal ao serviço, a segunda requisição que é a lícita chegará ao servidor e será respondida, porém a 1ª requisição, que é o ataque, será MITIGADA.
Abaixo a imagem da posição do PRAVAIL APS:
Porém vai existir uma situação em que nenhuma solução vai resolver o problema de ataque de negação de serviço: o ataque volumétrico, ou seja, o link do cliente é de 100 Mbps e está recebendo um ataque de 200 Mbps.
Aí entra o diferencial do PRAVAIL APS, lembra que estamos dentro do provedor / telecom? Exatamente isso! O Pravail APS emiti um sinal de “socorro” para o Peakflow, onde o mesmo através de sua arquitetura e utilizando BGP coloca-se um “hop” a frente do roteador do cliente, fazendo assim que o Peakflow TMS faça a mitigação em nuvem, dentro da operadora. O nome do protocolo que faz essa comunicação entre o provedor / telecom e o cliente, chama-se CLOUD SIGNALING.
O cenário da integração fica como abaixo:
Esse conjunto de soluções da Arbor garantem a disponibilidade do provedor / telecom e do datacenter que pode ser clientes dos mesmos.
Normalmente as operadoras resolverem o problema de DDoS dos seus clientes, vendem mais link ou o aumento temporário do mesmo para não deixar os serviços indisponíveis, porém isso não é uma solução definitiva e sim apenas um paliativo, um “apaga incêndio”.
Link falando um pouco do Pravail APS: https://youtu.be/8hT3D9flKIo
Link sobre o Peakflow SP TMS: https://youtu.be/fZm3JI1dS8w
