Relatório anual de segurança e disponibilidade de rede da Qrator Labs



Temos uma tradição no Qrator Labs - no começo, e fevereiro definitivamente não é o fim, todos os anos publicamos um relatório sobre o ano anterior.

Como qualquer entidade perene, é cercada por muitas histórias relacionadas. Por exemplo, já se tornou um presságio "bom" quando, no início de janeiro, outro ataque DDoS chega às nossas páginas corporativas, o que não temos tempo para entender no relatório. 2020 foi metade da exceção - conseguimos descrever o vetor de ataque (amplificação TCP SYN-ACK), mas foi para nós, no qrator.net, que o convidado veio (e não um) apenas em 18 de janeiro, mas imediatamente com os convidados: 116 Gbps a 26 Mpps.

Vale confessar que recontar os eventos do ano passado é um gênero específico. Portanto, decidimos no processo de reflexão focar no que acontecerá - principalmente com nossa equipe e produto - este ano, para que não se surpreenda ao ler sobre nossos planos de desenvolvimento.

Começaremos com dois dos tópicos mais interessantes para nós no ano passado: amplificações SYN-ACK e “otimizações” de BGP.

Amplificação TCP SYN-ACK e outros protocolos


O crescimento do mercado de IoT, entre outras coisas, significa que os invasores podem explorar dispositivos vulneráveis, se desejarem, criando uma largura de banda de ataque significativa - como aconteceu no meio do ano em que o protocolo WSDD foi usado para causar danos visíveis. O protocolo Apple ARMS, usado para obter um coeficiente de amplificação da ordem de 35,5, também foi visível em ataques à rede de filtragem do Qrator Labs.

Durante 2019, o público também aprendeu sobre novos amplificadores (PCAP) e também viu pessoalmente o vetor de ataque conhecido envolvendo o TCP - SYN-ACK. A principal diferença entre esse método e a amplificação UDP típica é que o vetor SYN-ACK não usa uma resposta maior que a solicitação - em vez disso, ele apenas tenta responder à solicitação TCP várias vezes, criando um coeficiente de amplificação perceptível. Como as nuvens públicas na Internet respondem a pacotes com falsificação do endereço de origem, ataques envolvendo o vetor de amplificação SYN-ACK se tornaram uma das ameaças mais graves da rede. O apogeu aconteceu quando um importante provedor de hospedagem em nuvem , Servers.com, recorreu ao Qrator Labscom um pedido de ajuda para neutralizar ataques DDoS, incluindo o vetor SYN-ACK.

Bastante interessante é o fato de que o método de reação mais usado no passado na forma de despejar todo o tráfego UDP, que praticamente neutraliza a maior parte dos ataques usando amplificação, não ajuda a neutralizar o vetor SYN-ACK. As empresas menores de Internet têm enormes dificuldades em neutralizar essas ameaças, uma vez que requer o uso de medidas abrangentes para combater ataques DDoS.


Embora a amplificação TCP SYN-ACK não seja nova, até agora ela permaneceu um vetor de ataque relativamente desconhecido. Um invasor envia pacotes SYN para todos os serviços TCP públicos na Internet, substituindo o endereço de origem pelo endereço da vítima, e cada um desses serviços responde várias vezes na tentativa de estabelecer uma conexão - geralmente de 3 a 5. Por um longo período, esse vetor de ataque foi considerado sem sentido, e somente em julho de 2019 vimos que os invasores foram capazes de gerar largura de banda de ataque suficiente para abalar até infraestruturas de rede muito grandes e distribuídas. Isso é especialmente incomum, dado o fato já mencionado da ausência de uma “amplificação da resposta” como tal e o uso apenas da possibilidade de reconexão inerente ao protocolo em caso de falha. Para aqueles,qualquer pessoa interessada em outros protocolos com "recursos" semelhantes pode apontar para o protocolo QUIC, que já fornece ao servidor a opção de responder à solicitação do cliente com uma resposta ampliada (embora o protocolo preliminar também "recomende" não enviar uma resposta mais que três vezes o tamanho da solicitação).

A amplificação deixou de ser uma ameaça com proporções de cerca de 100x - é óbvio que 3-5x é o suficiente hoje. A solução para esse problema é quase impossível sem eliminar o fenômeno do tráfego "falsificado" como categoria - um invasor não deve poder simular o identificador de rede de alguém e inundá-lo com tráfego de fontes de conteúdo legítimo. O BCP38 (um conjunto de práticas melhores e geralmente aceitas para configurar redes e resolver situações problemáticas) não funciona, e os criadores de novos protocolos de transporte - como o QUIC - avaliam mal o perigo representado mesmo por recursos de amplificação muito pequenos. Eles estão do outro lado.

As redes precisam de uma maneira confiável de descartar ou pelo menos limitar o tráfego falsificado - e essa ferramenta deve ter informações suficientes sobre a legitimidade da fonte de solicitação. As redes em nuvem pertencentes a empresas como Amazon, Akamai, Google e Azure hoje são um alvo quase ideal para amplificação de TCP - elas possuem muito hardware poderoso que pode satisfazer quase todos os objetivos do invasor.



É difícil eliminar as consequências de tais ataques na Internet moderna. Como já mencionado, os frontends e backends modernos de aplicativos e bibliotecas usados ​​para criá-los são mutuamente integrados. O uso dos recursos de soluções de software de código aberto localizadas dentro de nuvens grandes em sua própria pilha de desenvolvimento pode levar a sérios problemas como resultado de um ataque usando a amplificação SYN-ACK da mesma nuvem. Repositórios quebrados e arquivos de configuração que não são atualizados como resultado do bloqueio (devido a um endereço falso da origem da solicitação, seu endereço) do lado do provedor de serviços em nuvem é uma situação em que ninguém deseja estar. Em 2019, enfrentamos essa situação várias vezes, lidando com reclamações de empresas afetadas,descobriram dependências críticas inimagináveis ​​pela primeira vez durante sua existência e desenvolvimento.

É necessário um maior desenvolvimento do protocolo BGP para usá-lo na luta contra a falsificação na pilha de protocolos TCP / IP. As tabelas de roteamento são fundamentalmente diferentes das tabelas de sub-rede, e precisamos ensinar a rede a isolar e descartar rapidamente um pacote ilegítimo - em outras palavras, fornecer autenticação no nível da infraestrutura de rede. Deve-se prestar atenção não ao “endereço de destino”, mas ao “endereço de origem” para corresponder às informações contidas na tabela de roteamento.


BGP - "otimizadores"


Os incidentes BGP estão sempre em andamento. De acordo com a escala atual de magnitude de incidentes na rede, vazamentos de rotas e interceptações de sub-redes anunciadas que se espalharam o suficiente carregam o principal perigo na extensão da propagação e no tempo necessário para eliminar as conseqüências. Talvez isso se deva ao fato de que o desenvolvimento do componente de rede em si foi muito mais lento que o resto do mundo no desenvolvimento de novo hardware e software. Por um longo tempo, isso foi verdade - é hora de abandonar essa herança. É necessário investir tempo e dinheiro em software e hardware de rede, bem como em pessoas que configuram filtros BGP.

Os incidentes de 2019 que envolvem otimizadores de BGP mostraram que as estatísticas de BGP em que todos confiam têm muitos problemas. O fato é que, no anúncio do BGP recebido do par, é possível alterar quase todo o conteúdo antes de ser anunciado novamente - o protocolo é muito flexível. É exatamente isso que o otimizador usa: prefixos de rede maiores ou menores, juntamente com filtros inativos e a opção de prefixo local. Se alguém desagregar o prefixo em dois menores, geralmente vencerá a competição pelo direito de transmitir tráfego. Os otimizadores seguem a rota correta e anunciam sua parte menor - de maneira bem direta. E funciona dividindo as grandes partes da Internet.

Os otimizadores de BGP existem porque um grande número de empresas deseja controlar o fluxo de tráfego de saída automaticamente, sem pensar no tráfego como tal. Aceitar rotas que não deveriam existir é um grande erro, porque não existem rotas no ponto de origem.

Muitos textos foram escritos para 2019, inclusive pela nossa empresa., sobre os riscos da "otimização do BGP". No caso da Verizon, é claro, criar uma nova política de filtragem para cada novo consumidor do serviço é desagradável. E também é sabido que a Verizon não possui filtros, pois utilizou centenas de rotas problemáticas do próprio cliente do AS396531, que é um "esboço" - um sistema autônomo com uma única conexão. Além disso, a gigante das telecomunicações também não tinha um limite de sub-rede para essa conexão. Não houve sequer uma verificação básica da presença de outros operadores de nível 1 a caminho do consumidor (esse tipo de verificação é iniciado por padrão e não requer suporte ou alteração).


Na imprensa, esse incidente, incluindo Verizon e Cloudflare, foi discutido com bastante vigor. Além da possível ação da Verizon, muitos observaram os benefícios do RPKI e um registro máximo estrito no ROA. Mas e quanto a maxLength? É sabido que, com uma verificação rigorosa da duração máxima da gravação, todos os anúncios com uma indicação de sub-redes menores ficam incorretos ao verificar o ROA. Também é conhecido que existe uma política para redefinir caminhos inválidos. Há também um rascunho no IETF, indicando que maxLength deve ser igual ao comprimento do prefixo da rede.

O Cloudflare segue as melhores práticas. No entanto, há um pequeno problema. A Verizon não suporta a política de redefinição para rotas inválidas. Talvez ele não tenha tido nenhuma verificação RPKI. Como resultado, todas as rotas com sub-redes menores se espalham ainda mais, embora estejam incorretas do ponto de vista da validação da origem da rota e atraiam todo o tráfego para si. Ao mesmo tempo, apesar do status Inválido, o Cloudflare não podia anunciar as mesmas rotas, pois seus fornecedores as descartavam como incorretas.

Um vazamento de rota pode ser eliminado simplesmente manipulando o atributo AS_PATH no formato: ASx AS396531 ASx (em que ASx é o número do sistema de origem autônomo) durante a criação do anúncio - isso ajudará a evitar vazamentos usando o mecanismo de detecção de loop enquanto o problema é resolvido de outras maneiras. Embora cada vez com essa manipulação seja necessário manter essas políticas em mente.

Na maioria das vezes na vida real, o método padrão é usado - a reclamação. O que resulta em horas extras de espera. A comunicação pode ser dolorosa e não podemos culpar o Cloudflare por isso - eles fizeram tudo o que podiam, dadas as circunstâncias.


Qual é o resultado? Às vezes nos perguntam como é difícil usar o BGP para organizar algo ruim. Suponha que você seja um vilão novato. É necessário conectar-se a uma grande operadora de telecomunicações, o que é ruim nas configurações de filtro. Em seguida, selecione qualquer destino e escolha seus prefixos de rede anunciando suas partes menores. Além disso, não esqueça de descartar todos os pacotes de transporte público. Parabéns! Você acabou de criar um buraco negro na Internet para todo o tráfego de trânsito desse serviço através do seu provedor. A vítima perderá dinheiro real devido a tal negação de serviço e, possivelmente, sofrerá perdas significativas de reputação. Demora pelo menos uma hora para encontrar as causas desse incidente e é necessária uma hora paratrazer tudo de volta ao normal - desde que tal situação não seja intencional e haja boa vontade de resolução entre todos os participantes.

Em março de 2019, houve outro caso , que não associamos à otimização do BGP. No entanto, também merece atenção.

Imagine que você é um provedor de transporte público anunciando sub-redes de seus próprios clientes. Se esses clientes tiverem vários provedores, e não você, você receberá apenas parte do tráfego deles. Mas quanto mais tráfego, maior o lucro. Portanto, você decide anunciar sub-redes menores dessas redes com o mesmo atributo AS_PATH para obter todo o tráfego para essas redes. Com o dinheiro restante, é claro.

O ROA ajudará neste caso? Talvez sim, mas apenas se você decidir não usar o maxLength e não tiver registros ROA com prefixos cruzados. Para algumas operadoras de telecomunicações, essa opção não é viável.

Se falarmos sobre outros mecanismos de segurança BGP, o ASPA não ajudaria nesse tipo de interceptação, porque AS_PATH pertence ao caminho correto. Atualmente, o BGPSec é ineficiente devido à falta de suporte e à capacidade restante de realizar ataques de downgrade.

Ainda existe um motivo para aumentar a lucratividade devido ao recebimento de todo o tráfego de sistemas autônomos com vários fornecedores e à ausência de qualquer meio de proteção.


O número total de loops estáticos na rede.

O que ainda pode ser feito? O passo óbvio e mais radical é revisar as políticas de roteamento atuais. Isso o ajudará a dividir o espaço de endereço nas menores partes possíveis (sem interseções) que você gostaria de anunciar. Assine um ROA apenas para essas rotas usando a opção maxLength. A validação de ROV atual pode salvá-lo de um ataque assim. Mas, novamente, alguns não podem se dar ao luxo de usar apenas as menores sub-redes.

Usando o Radar.Qrator, você pode acompanhar esses eventos. Para fazer isso, precisamos de informações básicas sobre seus prefixos. Você pode estabelecer uma sessão BGP com um coletor e fornecer informações sobre sua visibilidade da Internet. Também apreciamos positivamente aqueles que estão prontos para nos enviar uma tabela de roteamento completa (visualização completa) - isso ajuda a rastrear a extensão dos incidentes, mas para seu próprio benefício e começando a usar a ferramenta, uma lista de rotas é suficiente apenas para seus prefixos. Se você já tem uma sessão com o Radar.Qrator, verifique se está enviando rotas. Para detecção e notificação automáticas de ataques no seu espaço de endereço, essas informações são necessárias.

Repetimos - se uma situação semelhante for detectada, você pode tentar neutralizá-la. A primeira abordagem é o auto-anúncio de caminhos com prefixos de sub-redes menores. No próximo ataque a esses prefixos - repita. A segunda abordagem é punir o invasor negando o acesso do sistema autônomo aos seus caminhos. Conforme descrito anteriormente, isso é obtido adicionando o número do sistema autônomo do invasor ao AS_PATH de seus caminhos antigos, fazendo com que a proteção contra loops funcione.

Bancos




Em 2019, realizamos um estudo na Rússia , que mostrou que as instituições financeiras registraram um aumento na importância da segurança da informação e começaram a dar a esses investimentos uma prioridade mais alta.

Os bancos entrevistados identificam os danos financeiros e à reputação como as consequências mais graves das violações da segurança da informação.

A maioria das instituições financeiras pesquisadas considera as soluções híbridas o meio mais eficaz de combater os ataques distribuídos de negação de serviço.

A dinâmica dos últimos dois anos indica claramente que o campo da segurança da informação está crescendo em um ritmo enorme: nos últimos 2 anos, a maioria dos bancos aumentou o investimento em segurança da informação. A cibersegurança já se tornou visível no nível de gerenciamento da empresa. Os líderes empresariais estão começando a prestar mais atenção aos processos de implementação de políticas de segurança, e o cargo de Diretor de Segurança da Informação adquiriu uma nova função. Os gerentes de SI estão gradualmente se transformando em consultores importantes para os principais gerentes de organizações financeiras, introduzindo táticas de negócios e estratégias de segurança de acordo com as necessidades da empresa.

Comércio eletrônico




Um estudo semelhante foi realizado no campo do comércio eletrônico, onde descobrimos que os ataques DDoS continuam sendo uma ameaça significativa para o varejo russo, especialmente para o desenvolvimento de canais de serviços digitais. O número de ataques nesse segmento continua a crescer.

Em alguns segmentos do mercado, apesar de sua estabilização e consolidação geral, a confiança na limpeza dos concorrentes ainda é baixa. Ao mesmo tempo, grandes lojas online confiam na maior parte dos seus consumidores e não consideram os motivos pessoais dos clientes como uma causa séria de ataques cibernéticos.

Como regra, as empresas de médio e grande porte de comércio eletrônico aprendem sobre sua prontidão para ataques DDoS apenas na prática, passando um "teste de batalha". A necessidade de uma avaliação preliminar dos riscos na preparação do projeto está longe de ser reconhecida por todos, e menos empresas realmente fazem essa avaliação. Os principais motivos dos hackers, os entrevistados consideram o mau funcionamento da loja, bem como o roubo da base de usuários.

Em geral, o nível de maturidade do varejo nas abordagens para garantir a segurança cibernética está crescendo. Portanto, todos os entrevistados usam alguns meios de proteção contra DDoS e WAF.
Em outros estudos, está planejado incluir uma amostra representativa de pequenas empresas on-line entre os entrevistados e estudar em detalhes esse segmento de mercado, seus riscos e o nível atual de segurança.

DNS sobre HTTPS vs DNS sobre TLS


Um dos tópicos mais quentes de 2019 foi o debate sobre qual tecnologia o futuro reserva - DoH ou DoT. A contradição inicial se deve a diferenças significativas em diferentes legislaturas (GDPR da UE versus leis federais e estaduais nos EUA) e à concorrência no principal mercado de navegadores: Google Chrome e Mozilla Firefox, além do Apple Safari. Não estamos prontos para dizer se a introdução de alguma dessas tecnologias reduzirá o número de amplificadores na Internet. No entanto, com a opção DoT, isso parece mais possível do ponto de vista arquitetural, devido à criação de conexões seguras entre os resolvedores de DNS. Em relação a outras previsões, aguardaremos uma decisão que o mercado tomará.


As indústrias mais atacadas em 2019.

Vulnerabilidades de reconhecimento de TCP


Em junho de 2019, os primeiros detalhes sobre a existência de vulnerabilidades graves apareceram em algumas implementações da pilha de protocolos TCP / IP, conforme relatado pela Netflix . Presumivelmente, o problema foi originalmente descoberto no sistema operacional FreeBSD, após o qual nossa empresa recebeu confirmação da presença da mesma e de outras vulnerabilidades no Linux.

O mais perigoso CVE-2019-11477 (SACK Panic), que pode permitir que um invasor chame o kernel panic usando uma sequência de pacotes especialmente formados. Três outras vulnerabilidades podem levar ao consumo excessivo de recursos, o que pode resultar em negação de serviço.

Desabilitar a funcionalidade SACK pode levar a um aumento na latência; no entanto, isso protegerá os servidores de possíveis ataques de negação de serviço - uma diminuição temporária no desempenho do TCP / IP, segundo o Qrator Labs, é uma maneira razoável de neutralizar uma vulnerabilidade séria. Os patches que cobrem essas vulnerabilidades estão disponíveis há muito tempo e são recomendados para instalação.

O futuro do roteamento BGP


No final de 2019, o Radar.Qrator é a maior plataforma global de coleta e análise de roteamento do BGP, com mais de 650 sessões estabelecidas.

A equipe do Radar.Qrator está trabalhando para melhorar a usabilidade e a confiabilidade do serviço, aprimorando o modelo de relacionamento BGP, que é a base de um serviço pago para monitorar um sistema autônomo em tempo real.

Em 2019, foram feitos grandes esforços para acelerar o processo de processamento de dados e a implementação do SLA, o que garante a qualidade do fluxo de dados analíticos. Hoje, o Radar é a maior plataforma analítica e coletor de BGP do mundo, com mais de 600 sessões estabelecidas, e esperamos usar os dados ao máximo para notificar os consumidores da parte paga do serviço sobre todos os eventos que ocorrem no roteamento de BGP sem demora.

O Radar.Qrator está crescendo mais rápido do que o esperado - tanto em termos de número de visitantes do site quanto de assinantes ao mesmo tempo. Em 2020, graças ao feedback dos clientes, várias melhorias significativas serão apresentadas ao mesmo tempo, uma dessas coisas será um novo armazenamento de incidentes para cada sistema autônomo.

Um dos problemas que encontramos foi o tempo de resposta esperado na interface da web Radar, acessível a todos os visitantes do site. Com o aumento da quantidade de dados, tornou-se necessário atualizar o modelo de armazenamento de dados e a arquitetura das solicitações do usuário. O radar deve poder enviar rapidamente todos os dados do período solicitado para qualquer visitante.


O esquema proposto para o mecanismo ASPA.

Também esperamos que durante este ano a ASPAse tornará RFC - um padrão de rede aprovado. A necessidade de uma solução mais ampla que a combinação de IRR / RPKI e mais leve que a solução BGPSec é óbvia para todos na indústria. Em 2019, ficou claro como uma configuração incorreta do BGP pode levar a vazamentos de rotas com consequências terríveis na forma de indisponibilidade de um grande número de serviços envolvendo os maiores provedores de serviços da Internet. Surpreendentemente, esses incidentes provaram mais uma vez que não há uma bala de prata que possa superar todos os cenários possíveis de seu desenvolvimento.

Os maiores provedores de Internet do mundo precisam apoiar o movimento inicial. Envolver grandes comunidades que podem ajudar a encontrar a fonte de desvio de rota é o próximo passo. Em termos simples, o ASPA é uma nova entidade que combina os recursos atuais de ROA e RPKI - implementa o princípio simples: "Conheça seu fornecedor". O proprietário do AS precisa conhecer apenas o upstream para implementar uma maneira confiável o suficiente para se proteger contra incidentes de roteamento BGP.

Como no caso do ROA, o ASPA permite filtrar rotas para qualquer conexão: com um provedor superior, um vizinho ou, é claro, um consumidor. A combinação de ROA e ASPA pode resolver a maior parte das tarefas de segurança de rede sem a necessidade de alterações fundamentais no próprio protocolo, filtrando ataques intencionais e erros relacionados ao fator humano. No entanto, também será necessário aguardar o suporte dos fabricantes de software e hardware - embora haja confiança de que o suporte ao código aberto não demorará a chegar.

Uma das principais vantagens do ASPA é que é uma ideia muito simples. Em 2020, está planejado concluir o trabalho em um projeto de protocolo e, se for bem-sucedido, a IETF e os co-autores do projeto chegarão a um consenso sobre a consolidação do status do protocolo.



Desenvolvimento atual e futuro da rede de filtragem Qrator

Lógica de filtragem


Nos dois anos anteriores, investimos quantidades significativas de tempo e esforço na melhoria da lógica de filtragem, que é a base do serviço de mitigação de ataques que fornecemos. Até o momento, eles já estão trabalhando em toda a rede, mostrando um aumento significativo na eficiência operacional e uma diminuição na carga na memória e no processador central nos pontos de presença. Novos filtros também permitem analisar solicitações de forma síncrona e fornecer uma variedade de tarefas JavaScript para verificar a legitimidade do visitante, melhorando a qualidade da detecção de ataques.

O principal motivo para atualizar a lógica de filtragem é a necessidade de detectar toda uma classe de bots desde a primeira solicitação. O Qrator Labs usa combinações de verificações com e sem memorização de estado e somente após a confirmação da legitimidade do usuário envia a solicitação para o servidor protegido. Portanto, é necessário que os filtros funcionem muito rapidamente - os ataques DDoS modernos passam com uma intensidade de dezenas de milhões de pacotes por segundo e alguns deles podem ser solicitações únicas e únicas.

Em 2020, como parte desse processo, mudanças significativas também serão feitas no processo de “integração” do tráfego, ou seja, o início do trabalho com um novo serviço protegido. O tráfego de cada serviço é único à sua maneira e nos esforçamos para garantir que, não importa o que aconteça, os novos clientes recebam rapidamente a completa neutralização de todos os tipos de ataques, mesmo que o modelo não seja bem treinado. Como resultado, garantiremos uma inclusão mais suave da filtragem quando conectado sob ataque, e o início da filtragem será acompanhado por menos falsos positivos. Tudo isso é importante quando o serviço e as pessoas por trás dele estão no meio da luta pela sobrevivência sob ataques massivos de rede.


Distribuição dos ataques DDoS para 2019 por banda usada.

HTTP / 2


Os problemas com implementações do protocolo HTTP / 2 (vulnerabilidades de negação de serviço) foram resolvidos principalmente em 2019, o que nos permitiu ativar o suporte a esse protocolo dentro da rede de filtragem Qrator.

Agora, o trabalho está ativamente em andamento, a fim de fornecer proteção HTTP / 2 a cada cliente, completando um longo e profundo período de testes. Juntamente com o suporte ao HTTP / 2, o TLS 1.3 introduziu a possibilidade de usar o eSNI com a emissão automatizada de certificados de segurança Let's Encrypt.

Atualmente, o HTTP / 2 está disponível mediante solicitação como uma opção adicional.

Contêineres e Orquestração


As tendências atuais de conteinerização são pouco compatíveis com nossas abordagens de segurança. Isso significa que trabalhar com o Kubernetes precisa superar uma variedade de desafios. Segurança e acessibilidade estão entre as prioridades mais altas, o que não nos permite confiar em práticas comuns entre os que trabalham com o Kubernetes, antes de tudo, dar ao processo de orquestração controle total sobre o sistema operacional com todos os recursos - isso nos deixaria exclusivamente à mercê dos desenvolvedores e complementos do Kubernetes. Até o momento, o Kubernetes não possui todos os recursos necessários e alguns estão ocultos no estado “use como está, não há garantia” e não pode ser investigado em detalhes. Mas tudo isso não afasta os trabalhos adicionais sobre a implementação do Kubernetes no gerenciamento da rede de filtragem,gradualmente ajustando-o aos nossos requisitos e tornando-o uma parte bastante importante da infraestrutura interna.

O futuro do desenvolvimento e desenvolvimento de redes distribuídas e tolerantes a falhas requer a introdução de ferramentas apropriadas (CI / CD e testes automáticos fazem parte) e a capacidade de usá-lo para criar e gerenciar um sistema estável e confiável. Como a quantidade de dados aumenta apenas, os esforços de monitoramento devem aumentar após eles. A maneira mais natural de criar monitoramento é fornecer um método de comunicação seguro e facilmente observável para aplicativos. Acreditamos que o Kubernetes já provou sua versatilidade e aplicabilidade, e sua especialização adicional para as necessidades da infraestrutura que luta contra ataques DDoS é a realidade de trabalhar com qualquer solução de código aberto.


Alteração na duração média dos ataques DDoS de 2018 a 2019.

Yandex.Cloud e Ingress 2.0


Em 2019, juntamente com o Yandex.Cloud, apresentamos uma versão atualizada do nosso serviço para filtrar o tráfego de entrada - o Ingress, expandindo significativamente seus recursos de filtragem e configuração, fornecendo ao usuário final interfaces de gerenciamento claras. A nova versão do serviço já funciona na rede de filtragem do Qrator Labs, bem como na rede Yandex.Cloud.

A equipe do Yandex.Cloud percorreu um longo caminho conosco, combinando duas infraestruturas usando os nós físicos do Qrator Labs localizados dentro da infraestrutura do parceiro, trabalhando no tráfego.

Finalmente, após um período de testes detalhados, a nova versão do Ingress está pronta para uso. Com a ajuda da Yandex, conseguimos criar uma das melhores soluções para filtrar o tráfego de entrada, criado especificamente para as necessidades de serviços que geram muito conteúdo.

Também consideramos um grande sucesso que a nova versão do serviço seja intuitiva para o usuário final e permita que você configure com mais flexibilidade os parâmetros de filtragem.

Certificados TLS 1.3 e ECDSA


No início de 2019, o Qrator Labs escreveu sobre o suporte ao TLS versão 1.3 enquanto desabilitava o SSL v.3. Devido à disponibilidade do serviço de neutralização de DDoS sem revelar as chaves de criptografia, foram feitas melhorias adicionais nesse esquema de filtragem, aumentando a velocidade e a confiabilidade da conversão de syslog. Vamos relembrar os resultados das medições de desempenho .
Tipo de assinaturaApertos de mão por segundo
ECDSA (prime256v1 / nistp256)3358,6
RSA 2048972,5

Como você pode ver, em um único núcleo da CPU Intel® Xeon® Silver 4114 a 2,20GHz (lançado no terceiro trimestre de 17), a diferença total entre o desempenho da ECDSA e a RSA geralmente aceita com um comprimento de chave de 2048 bits é 3,5 vezes.

Vejamos os resultados da execução do comando openssl -speed para ECDSA e RSA no mesmo processador.
Tipo de assinatura
placa
verificar
sinal / s
verificar / s
RSA 2048 bit
717 μs
20,2 μs
1393,9
49458,2
ECDSA de 256 bits (nistp256) 
25,7 μs
81,8 μs
38971,6
12227.1

Aqui podemos encontrar a confirmação de uma tese escrita anteriormente sobre como as operações computacionais de uma assinatura e sua verificação diferem entre ECC e RSA. Atualmente, armada com TLS 1.3, a criptografia baseada em curvas elípticas fornece um aumento significativo no desempenho do servidor com um nível mais alto de proteção em comparação com o RSA. Esta é a principal razão pela qual nós, da Qrator Labs, recomendamos e incentivamos fortemente os clientes que também estão prontos para usar os certificados ECDSA. Nas CPUs modernas, o ganho de desempenho a favor do ECDSA é de 5x.

Melhorias menores


Uma das inovações pequenas e discretas, mas importantes, durante o ano de 2019, foi a introdução do processo de verificação ativa do status do upstream. Se, por algum motivo, algo acontecer durante uma das conexões superiores de nosso cliente durante o ataque, o serviço de filtragem será o primeiro a saber sobre isso, deixando a conexão fora de operação até que o problema seja resolvido. Nisso, ele ajuda não apenas a monitorar erros e condições de tráfego, mas também a configurar uma interface especial de verificação de acessibilidade, que é feita em conjunto com o consumidor do serviço.

No final de 2019, uma grande atualização da interface do usuário do serviço de filtragem foi feita. E embora seja fornecida a possibilidade de usar a versão antiga da sua conta pessoal, novos recursos já estão sendo desenvolvidos na parte atualizada, o que fornece uma funcionalidade mais ampla, por exemplo, gerenciamento de certificados TLS.

Enquanto a versão antiga da conta pessoal usava a renderização do lado do servidor, a versão atualizada nas melhores tradições da web moderna é um aplicativo JavaScript executado em um cliente que se comunica com o servidor por meio da API REST. Essa abordagem permitirá que você forneça rapidamente novas funções ao usuário, oferecendo oportunidades mais profundas para configurações individuais de cada conta pessoal de um consumidor individual. Uma dessas coisas é a seção Analytics, onde é possível personalizar métricas individuais, cujo número aumenta constantemente.


Comparação dos dois principais grupos de classificação para ataques DDoS em 2019.

IPv6


O Qrator Labs está se preparando ativamente para começar a usar o IPv6 como parte dos serviços de filtragem de tráfego. Para qualquer empresa de segurança cibernética, essa transição não pode ser elementar. Devido à natureza dos ataques DDoS, a neutralização dos ataques à rede usando IPv6 requer uma mudança radical na abordagem, já que não é mais possível lidar com qualquer forma de “lista” ao lidar com um limite teórico de 2.128 endereços IP. E é apenas sobre TCP, sem considerar UDP.

Para nós, 2020 será o ano do IPv6. Com o esgotamento do espaço de endereço IPv4 livre, não há outra maneira de desenvolver uma rede que atenda aos requisitos futuros. Esperamos ser capazes de responder com eficácia a todos os desafios que enfrentamos na estrutura de neutralização de ataques IPv6. Antes de tudo, isso significa que poderemos anunciar a sub-rede IPv6 dos serviços de filtragem de consumidores usando nossa rede, enquanto oferecemos um serviço de cibersegurança de primeira classe.

Antibot


Em 2019, a indústria observou uma batalha feroz entre impressões digitais (identificação de visitantes) e tentativas de limitá-las. É compreensível o desejo dos proprietários e desenvolvedores de serviços da Internet de limitar ou separar solicitações de usuários legítimos das solicitações automatizadas de bots. Por outro lado, não há nada de estranho no desejo dos desenvolvedores de navegadores de proteger os usuários do software. Durante anos, o Qrator Labs lembrou ao mercado que, se alguma informação estiver disponível ao público e não for necessária autorização para recebê-la, a probabilidade de protegê-la da análise automatizada tenderá a zero. Ao mesmo tempo, lembramos aos proprietários do negócio digital que eles têm o direito de escolher o que fazer com as solicitações que chegam ao servidor. Uma abordagem proativa em determinadas situações ajuda a avaliar e identificar a ameaça.

Como os bots geram uma parcela crescente de tráfego, podemos esperar um momento futuro em que grandes serviços criarão interfaces especiais para bons bots, fornecendo informações legítimas. O restante será bloqueado. Mesmo agora, no início de 2020, pode-se argumentar que nem um usuário 100% legítimo poderá acessar imediatamente qualquer recurso na Internet - muitos não o permitirão se, digamos, você apenas alterar o agente do usuário do navegador para um arbitrário.

Dentro do Qrator Labs, o serviço de antibot está em desenvolvimento há vários anos e, em 2020, esperamos oferecê-lo aos nossos primeiros clientes como parte do serviço beta. Este serviço operará nos modos semi e automático, possibilitando identificar e definir regras de segurança em relação a várias solicitações automatizadas ou de saída de bots.


Equipamento


Depois de testar os novos processadores AMD, os funcionários responsáveis ​​da empresa ficaram tão intrigados que, no primeiro trimestre de 2020, a Qrator Labs encomendará um novo ponto de presença em Osaka, Japão, completamente construído nos processadores AMD. O PCI Express de 4ª geração, disponível nos processadores AMD, promete dobrar a largura de banda entre o CPU e a interface de rede. Durante o ano, o uso desse ligamento nos cenários mais estressantes será testado e avaliado. O canal entre a interface de rede e o processador gradualmente se torna um pescoço estreito, com um aumento na quantidade de dados transmitidos nas redes. A combinação de núcleos adicionais, um cache maior e a nova versão do PCI Express promete trazer um bom resultado.

Outro motivo para usar o CPU AMD é a necessidade de diversificar a arquitetura da rede, embora este seja o primeiro ponto de presença do Qrator Labs, construído inteiramente no novo processador.

Estamos realmente ansiosos pelo início do trabalho de novos equipamentos, cujo lançamento será relatado separadamente no início de 2020. Esperamos que a combinação de processadores AMD e placas de rede de alto desempenho usando o PCI Express 4 atenda aos nossos requisitos. O mercado asiático é um dos que mais cresce e gostaria de apreciar as perspectivas de neutralizar ataques DDoS com novos equipamentos no local.

Ao mesmo tempo, também é esperada a chegada de uma nova geração de processadores Intel - Ice Lake. Seu uso posterior em nossa infraestrutura dependerá em grande parte dos resultados de seus testes e comparações.

Além dos processadores, todo o setor espera o lançamento das placas de rede da série Intel 800. Em 2020, tentaremos encontrá-los aplicativos dentro da infraestrutura da rede de filtragem.

Com relação às opções - o Qrator Labs continua trabalhando com a Mellanox, que tem provado repetidamente ser um fornecedor e parceiro confiável.

Dizer isso não é fácil, mas, embora a Broadcom domine o mercado de equipamentos de rede, esperamos que a fusão com a NVidia dê à Mellanox uma chance de uma concorrência digna.

Futuras melhorias na rede de filtragem


Durante 2020, nossa empresa espera aprofundar significativamente sua parceria com fornecedores de uma ampla variedade de serviços e serviços, como Firewall de Aplicativos Web e Rede de Entrega de Conteúdo na rede de filtragem. Sempre tentamos integrar uma variedade de fornecedores à infraestrutura para fornecer as melhores combinações de serviços possíveis para os consumidores. Até o final de 2020, está planejado anunciar a disponibilidade de vários novos provedores de serviços em conjunto com o Qrator.

2019 também revelou uma série de perguntas sobre a proteção da tecnologia WebSockets. Sua prevalência e popularidade estão crescendo apenas, e a complexidade da proteção adequada não é reduzida. Em 2020, esperamos trabalhar com alguns de nossos clientes usando a tecnologia WebSockets para encontrar a melhor maneira de protegê-la, mesmo se enviarmos dados arbitrários (desconhecidos).

O que fazemos não é conhecimento e nem revelação. A empresa chegou a esse mercado mais tarde do que muitos concorrentes. A equipe faz grandes esforços para fazer algo único e funcional. Parte dessa oportunidade também reside no interesse genuíno dos funcionários da empresa em pesquisas acadêmicas e científicas nas principais áreas de esforço, o que nos permite estar preparados para eventos “repentinos”.

Desde que você leu até o final, aqui está o .pdf para distribuição . Não se esqueça da segurança da rede - e não a entregue a outras pessoas.

Source: https://habr.com/ru/post/undefined/


All Articles