{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS a favor: como realizamos testes de estresse e carga","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nA Variti desenvolve prote\u00e7\u00e3o contra bots e ataques DDoS, al\u00e9m de realizar testes de estresse e carga. Na confer\u00eancia HighLoad++ 2018, falamos sobre como proteger os recursos contra diferentes tipos de ataques. Em resumo: isole partes do sistema, use servi\u00e7os em nuvem e CDN, e mantenha-se sempre atualizado. Mas sem empresas especializadas em prote\u00e7\u00e3o, voc\u00ea ainda n\u00e3o conseguir\u00e1 se proteger \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nAntes de ler o texto, voc\u00ea pode verificar os pontos-chave no site da confer\u00eancia<\/a><\/noindex>.
\nE se voc\u00ea n\u00e3o gosta de ler ou simplesmente quer assistir ao v\u00eddeo, a grava\u00e7\u00e3o da nossa apresenta\u00e7\u00e3o est\u00e1 abaixo, sob o spoiler.<\/p>\n

Grava\u00e7\u00e3o da apresenta\u00e7\u00e3o<\/b>

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Muitas empresas j\u00e1 sabem como realizar testes de carga, mas nem todas fazem testes de estresse. Alguns de nossos clientes acreditam que seus sites s\u00e3o invulner\u00e1veis porque t\u00eam um sistema de highload, que os protege bem contra ataques. N\u00f3s mostramos que isso n\u00e3o \u00e9 bem verdade.
\nCom certeza, antes de realizar os testes, obtemos a autoriza\u00e7\u00e3o do cliente, com assinatura e carimbo, e com a nossa ajuda um ataque DDoS n\u00e3o pode ser realizado contra ningu\u00e9m. Os testes s\u00e3o feitos no hor\u00e1rio escolhido pelo cliente, quando o tr\u00e1fego em seu recurso \u00e9 m\u00ednimo, e os problemas de acesso n\u00e3o impactam os clientes. Al\u00e9m disso, como sempre pode haver imprevistos durante os testes, mantemos contato constante com o cliente. Isso permite n\u00e3o apenas relatar os resultados alcan\u00e7ados, mas tamb\u00e9m fazer ajustes durante o teste. Ao final do teste, sempre elaboramos um relat\u00f3rio que aponta as defici\u00eancias encontradas e oferecemos recomenda\u00e7\u00f5es para corrigir as fragilidades do site. <\/p>\n

Como trabalhamos<\/h3>\n

\nAo realizar os testes, emulamos um botnet. Como trabalhamos com clientes que n\u00e3o est\u00e3o em nossas redes, para que o teste n\u00e3o termine no primeiro minuto devido a limites ou prote\u00e7\u00f5es ativadas, geramos carga n\u00e3o de um \u00fanico IP, mas de nossa pr\u00f3pria sub-rede. Al\u00e9m disso, para criar uma carga significativa, temos nosso pr\u00f3prio servidor de testes suficientemente potente.<\/p>\n

Postulados<\/h3>\n

<\/p>\n

Muito \u2014 n\u00e3o significa bem<\/b>
\nQuanto menor for a carga que conseguirmos levar o recurso \u00e0 falha, melhor. Se conseguirmos fazer com que o site deixe de funcionar com uma solicita\u00e7\u00e3o por segundo, ou at\u00e9 mesmo com uma solicita\u00e7\u00e3o por minuto, ser\u00e1 maravilhoso. Porque, por lei de Murphy, usu\u00e1rios ou atacantes acabar\u00e3o encontrando exatamente essa vulnerabilidade. <\/p><\/blockquote>\n

Uma falha parcial \u00e9 melhor do que uma total<\/b>
\nSempre aconselhamos a tornar os sistemas heterog\u00eaneos. E a separa\u00e7\u00e3o deve ocorrer no n\u00edvel f\u00edsico, e n\u00e3o apenas por meio de cont\u00eaineres. No caso de separa\u00e7\u00e3o f\u00edsica, mesmo que algo falhe no site, \u00e9 grande a probabilidade de que ele n\u00e3o pare completamente, e os usu\u00e1rios tenham acesso, pelo menos, a parte da funcionalidade.<\/p><\/blockquote>\n

A arquitetura correta \u00e9 a base da resili\u00eancia<\/b>
\nA resili\u00eancia do recurso e sua capacidade de suportar ataques e cargas devem ser planejadas na fase de design, de fato, na fase de esbo\u00e7ar os primeiros fluxogramas no caderno. Porque se erros fatais se infiltrar\u00e3o, corrigi-los posteriormente \u00e9 poss\u00edvel, mas muito dif\u00edcil.<\/p><\/blockquote>\n

N\u00e3o s\u00f3 o c\u00f3digo deve ser bom, mas tamb\u00e9m a configura\u00e7\u00e3o<\/b>
\nMuitos pensam que uma boa equipe de desenvolvimento \u00e9 garantia de resili\u00eancia do servi\u00e7o. Uma boa equipe de desenvolvimento \u00e9 realmente necess\u00e1ria, mas tamb\u00e9m deve haver uma boa opera\u00e7\u00e3o, um bom DevOps. Ou seja, s\u00e3o necess\u00e1rios especialistas que configurem corretamente o Linux e a rede, escrevam corretamente as configura\u00e7\u00f5es no nginx, ajustem limites e assim por diante. Caso contr\u00e1rio, o recurso funcionar\u00e1 bem apenas nos testes, mas em produ\u00e7\u00e3o, em algum momento, tudo poder\u00e1 quebrar.<\/p><\/blockquote>\n

Diferen\u00e7as entre testes de carga e de estresse<\/b>
\nOs testes de carga permitem identificar os limites de funcionamento do sistema. Os testes de estresse visam encontrar os pontos fracos do sistema e s\u00e3o usados para quebrar esse sistema e observar como ele se comporta durante a falha de algumas partes. Nesse processo, a natureza da carga geralmente permanece desconhecida para o cliente antes do in\u00edcio do teste de estresse.<\/p><\/blockquote>\n

<\/p>\n

Caracter\u00edsticas distintivas dos ataques L7<\/h3>\n

\nClassificamos os tipos de carga em cargas de n\u00edvel L7 e L3&4. L7 refere-se \u00e0 carga no n\u00edvel de aplica\u00e7\u00e3o, que geralmente \u00e9 entendida apenas como HTTP, mas aqui entendemos qualquer carga no n\u00edvel do protocolo TCP.
\nOs ataques L7 t\u00eam caracter\u00edsticas distintas. Em primeiro lugar, eles chegam diretamente ao aplicativo, ou seja, dificilmente podem ser refletidos por meio de medidas de rede. Esses ataques envolvem l\u00f3gica e, por isso, consomem de forma muito eficaz e com baixo tr\u00e1fego CPU, mem\u00f3ria, disco, banco de dados e outros recursos.<\/p>\n

Inunda\u00e7\u00e3o HTTP<\/h3>\n

\nEm qualquer tipo de ataque, \u00e9 mais f\u00e1cil criar a carga do que process\u00e1-la, e isso tamb\u00e9m \u00e9 verdade para o L7. O tr\u00e1fego do ataque nem sempre \u00e9 f\u00e1cil de distinguir do tr\u00e1fego leg\u00edtimo, e na maioria das vezes isso pode ser feito pela frequ\u00eancia, mas se tudo for planejado adequadamente, \u00e9 imposs\u00edvel, com os logs, entender onde est\u00e1 o ataque e onde est\u00e3o as requisi\u00e7\u00f5es leg\u00edtimas.
\nComo primeiro exemplo, vamos considerar um ataque de Inunda\u00e7\u00e3o HTTP. O gr\u00e1fico mostra que, geralmente, esses ataques s\u00e3o muito poderosos; no exemplo abaixo, o n\u00famero pico de requisi\u00e7\u00f5es superou 600 mil por minuto.<\/p>\n

\"DDoS
\n
\nA Inunda\u00e7\u00e3o HTTP \u00e9 a forma mais simples de gerar carga. Normalmente, uma ferramenta de teste de carga \u00e9 utilizada, como o ApacheBench, e s\u00e3o definidos a requisi\u00e7\u00e3o e o alvo. Com essa abordagem simples, h\u00e1 uma grande probabilidade de esbarrar no cache do servidor, mas isso \u00e9 f\u00e1cil de contornar. Por exemplo, adicionando linhas aleat\u00f3rias \u00e0 requisi\u00e7\u00e3o, o que for\u00e7ar\u00e1 o servidor a sempre entregar uma p\u00e1gina atualizada.
\nN\u00e3o devemos esquecer do user-agent no processo de cria\u00e7\u00e3o de carga. Muitos user-agents de ferramentas de teste populares s\u00e3o filtrados por administradores de sistemas, e nesse caso a carga pode simplesmente n\u00e3o chegar ao backend. \u00c9 poss\u00edvel melhorar significativamente o resultado inserindo no pedido um cabe\u00e7alho mais ou menos v\u00e1lido de um navegador.
\nApesar da simplicidade, os ataques de Inunda\u00e7\u00e3o HTTP tamb\u00e9m t\u00eam suas desvantagens. Em primeiro lugar, s\u00e3o necess\u00e1rias grandes pot\u00eancias para gerar carga. Em segundo lugar, esses ataques s\u00e3o muito f\u00e1ceis de detectar, especialmente se originam de um \u00fanico endere\u00e7o. Como resultado, as requisi\u00e7\u00f5es come\u00e7am imediatamente a ser filtradas, seja por administradores de sistemas, seja at\u00e9 mesmo no n\u00edvel do provedor. <\/p>\n

O que procurar<\/h3>\n

\nPara reduzir o n\u00famero de requisi\u00e7\u00f5es por segundo sem comprometer a efici\u00eancia, \u00e9 necess\u00e1rio usar um pouco de criatividade e explorar o site. Assim, n\u00e3o apenas o canal ou o servidor podem ser sobrecarregados, mas tamb\u00e9m partes espec\u00edficas da aplica\u00e7\u00e3o, como bancos de dados ou sistemas de arquivos. Al\u00e9m disso, pode-se procurar por \u00e1reas no site que realizam c\u00e1lculos pesados: calculadoras, p\u00e1ginas com sele\u00e7\u00e3o de produtos, entre outros. Por fim, muitas vezes h\u00e1 um script PHP no site que gera a p\u00e1gina a partir de v\u00e1rias centenas de milhares de linhas. Esse script tamb\u00e9m sobrecarrega significativamente o servidor e pode se tornar um alvo de ataque.<\/p>\n

Onde procurar<\/h3>\n

\nQuando escaneamos um recurso antes de realizar testes, primeiramente olhamos para o pr\u00f3prio site. Buscamos diversos campos de entrada, arquivos pesados - basicamente, tudo o que pode causar problemas ao recurso e desaceler\u00e1-lo. Aqui, ferramentas simples de desenvolvimento no Google Chrome e no Firefox ajudam ao mostrar os tempos de resposta da p\u00e1gina.
\nTamb\u00e9m escaneamos subdom\u00ednios. Por exemplo, se h\u00e1 uma loja online, abc.com, e ela possui um subdom\u00ednio admin.abc.com. Provavelmente, este \u00e9 o painel de administra\u00e7\u00e3o com autentica\u00e7\u00e3o, mas se o submetermos a carga, isso pode causar problemas ao recurso principal.
\nO site pode ter um subdom\u00ednio api.abc.com. Provavelmente, este \u00e9 um recurso para aplicativos m\u00f3veis. O aplicativo pode ser encontrado na App Store ou Google Play, configurando um ponto de acesso especial, manipulando a API e registrando contas de teste. O problema \u00e9 que muitas vezes as pessoas pensam que tudo que est\u00e1 protegido por autentica\u00e7\u00e3o \u00e9 invulner\u00e1vel a ataques de nega\u00e7\u00e3o de servi\u00e7o. Supostamente, a autentica\u00e7\u00e3o \u00e9 o melhor CAPTCHA, mas n\u00e3o \u00e9 assim. Criar 10-20 contas de teste \u00e9 simples, e ao faz\u00ea-lo, obtemos acesso a funcionalidades complexas e n\u00e3o expostas.
\nNaturalmente, observamos o hist\u00f3rico, o robots.txt e o WebArchive, ViewDNS, buscando vers\u00f5es antigas do recurso. \u00c0s vezes acontece que os desenvolvedores lan\u00e7aram, digamos, mail2.yandex.net, mas uma vers\u00e3o antiga, mail.yandex.net, permanece. Este mail.yandex.net deixa de ser suportado, n\u00e3o recebe recursos de desenvolvimento, mas continua consumindo o banco de dados. Consequentemente, utilizando a vers\u00e3o antiga \u00e9 poss\u00edvel explorar efetivamente os recursos do backend e tudo o que est\u00e1 por tr\u00e1s da estrutura. Claro, isso n\u00e3o acontece sempre, mas nos deparamos com situa\u00e7\u00f5es semelhantes com bastante frequ\u00eancia.
\nNaturalmente, analisamos todos os par\u00e2metros de solicita\u00e7\u00e3o, a estrutura dos cookies. Podemos, por exemplo, injetar um valor em um array JSON dentro do cookie, criar uma grande profundidade e fazer o recurso funcionar de forma desnecessariamente lenta.<\/p>\n

Carga na pesquisa<\/h3>\n

\nA primeira coisa que vem \u00e0 mente ao investigar um site \u00e9 sobrecarregar o banco de dados, uma vez que a pesquisa est\u00e1 presente na maioria deles e, infelizmente, quase todos a protegem mal. Por alguma raz\u00e3o, os desenvolvedores n\u00e3o prestam aten\u00e7\u00e3o suficiente \u00e0 pesquisa. Mas aqui vai uma recomenda\u00e7\u00e3o \u2014 n\u00e3o fa\u00e7a consultas semelhantes, pois voc\u00ea pode se deparar com o cache, assim como no caso de um ataque de inunda\u00e7\u00e3o HTTP.
\nFazer consultas aleat\u00f3rias no banco de dados tamb\u00e9m nem sempre \u00e9 eficaz. \u00c9 muito melhor criar uma lista de palavras-chave que se relacionam com a pesquisa. Voltemos ao exemplo da loja online: suponha que o site venda pneus de carro e permita definir o raio dos pneus, tipo de carro e outros par\u00e2metros. Portanto, combina\u00e7\u00f5es de palavras relevantes far\u00e3o o banco de dados operar em condi\u00e7\u00f5es muito mais complexas.
\nAl\u00e9m disso, vale a pena usar pagina\u00e7\u00e3o: \u00e9 muito mais dif\u00edcil para a pesquisa devolver a pen\u00faltima p\u00e1gina de resultados do que a primeira. Assim, com a pagina\u00e7\u00e3o, \u00e9 poss\u00edvel diversificar um pouco a carga.
\nNo exemplo abaixo, mostramos a carga na pesquisa. Pode-se ver que, desde o primeiro segundo do teste, com uma velocidade de dez solicita\u00e7\u00f5es por segundo, o site caiu e n\u00e3o respondeu.<\/p>\n

\"DDoS
\n<\/p>\n

E se n\u00e3o houver pesquisa?<\/h3>\n

\nSe n\u00e3o houver pesquisa, isso n\u00e3o significa que o site n\u00e3o contenha outros campos vulner\u00e1veis para entrada. Um desses campos pode ser a autentica\u00e7\u00e3o. Atualmente, os desenvolvedores gostam de criar hashes complexos para proteger o banco de logins de ataques de tabelas arco-\u00edris. Isso \u00e9 bom, mas tais hashes consomem grandes recursos de CPU. Um grande fluxo de tentativas de autentica\u00e7\u00e3o falsas leva \u00e0 falha do processador e, como resultado, o site para de funcionar.
\nA presen\u00e7a de v\u00e1rios formul\u00e1rios para coment\u00e1rios e feedback no site \u00e9 um motivo para enviar textos muito grandes ou simplesmente criar um fluxo massivo de dados. \u00c0s vezes, os sites aceitam arquivos anexos, incluindo no formato gzip. Nesse caso, pegamos um arquivo com tamanho de 1TB, o comprimimos com gzip para alguns bytes ou kilobytes e o enviamos para o site. Depois, ele \u00e9 descompactado e resulta em um efeito muito interessante. <\/p>\n

Rest API<\/h3>\n

\nGostaria de dedicar um pouco de aten\u00e7\u00e3o a servi\u00e7os que est\u00e3o se tornando populares, como o Rest API. Proteger um Rest API \u00e9 muito mais dif\u00edcil do que proteger um site comum. M\u00e9todos simples de prote\u00e7\u00e3o contra ataques de for\u00e7a bruta e outras atividades ileg\u00edtimas n\u00e3o funcionam para Rest APIs.
\nUm Rest API \u00e9 muito f\u00e1cil de ser comprometido porque acessa diretamente o banco de dados. Al\u00e9m disso, a interrup\u00e7\u00e3o de tal servi\u00e7o pode ter consequ\u00eancias graves para os neg\u00f3cios. O fato \u00e9 que o Rest API geralmente conecta n\u00e3o apenas o site principal, mas tamb\u00e9m o aplicativo m\u00f3vel e alguns recursos internos de neg\u00f3cios. Se tudo isso falhar, o impacto \u00e9 muito maior do que se apenas um site simples sa\u00edsse do ar. <\/p>\n

Carga em conte\u00fado pesado<\/h3>\n

\nQuando nos oferecem para testar algum aplicativo simples de uma p\u00e1gina, uma landing page ou um site de apresenta\u00e7\u00e3o, que n\u00e3o possuem funcionalidades complexas, procuramos por conte\u00fado pesado. Por exemplo, grandes imagens que o servidor fornece, arquivos bin\u00e1rios, documenta\u00e7\u00e3o em PDF \u2013 tentamos baixar tudo isso. Esses testes sobrecarregam o sistema de arquivos e congestionam os canais, tornando-os eficazes. Ou seja, mesmo que voc\u00ea n\u00e3o derrube o servidor baixando um grande arquivo em velocidades baixas, simplesmente estar\u00e1 congestionando o canal do servidor de destino, resultando em uma indisponibilidade.
\nNo exemplo deste teste, fica claro que \u00e0 velocidade de 30 RPS, o site parou de responder ou come\u00e7ou a retornar erros de servidor 500.<\/p>\n

\"DDoS
\n
\nN\u00e3o devemos esquecer da configura\u00e7\u00e3o dos servidores. Muitas vezes encontramos pessoas que compraram uma m\u00e1quina virtual, instalaram o Apache, configuraram tudo como padr\u00e3o, hospedaram um aplicativo PHP, e abaixo \u00e9 poss\u00edvel ver o resultado. <\/p>\n

\"DDoS
\n
\nAqui, a carga estava no diret\u00f3rio raiz e era de apenas 10 RPS. Esperamos 5 minutos, e o servidor caiu. De fato, n\u00e3o se sabe ao certo por que ele caiu, mas h\u00e1 uma suspeita de que ele simplesmente esgotou a mem\u00f3ria, por isso parou de responder.<\/p>\n

Baseado em Wave<\/h3>\n

\nNos \u00faltimos um ou dois anos, os ataques de onda se tornaram bastante populares. Isso se deve ao fato de que muitas organiza\u00e7\u00f5es compram determinados dispositivos para prote\u00e7\u00e3o contra DDoS, que exigem um certo tempo para acumular estat\u00edsticas antes de iniciar a filtragem do ataque. Ou seja, eles n\u00e3o filtram o ataque nos primeiros 30-40 segundos, pois est\u00e3o acumulando dados e aprendendo. Assim, durante esses 30-40 segundos, o site pode ser bombardeado a tal ponto que os recursos ficam offline por um longo per\u00edodo, enquanto todas as solicita\u00e7\u00f5es s\u00e3o processadas.
\nNo caso do ataque abaixo, houve um intervalo de 10 minutos, ap\u00f3s o qual uma nova e modificada onda de ataque chegou.<\/p>\n

\"DDoS
\n
\nOu seja, a prote\u00e7\u00e3o aprendeu, come\u00e7ou a filtragem, mas surgiu uma nova, completamente diferente onda de ataque, e a prote\u00e7\u00e3o iniciou o aprendizado novamente. Na pr\u00e1tica, a filtragem deixa de funcionar, a prote\u00e7\u00e3o se torna ineficaz e o site fica inacess\u00edvel.
\nOs ataques de onda s\u00e3o caracterizados por picos muito altos, podendo atingir cem mil ou um milh\u00e3o de solicita\u00e7\u00f5es por segundo, no caso de L7. Se falarmos sobre L3&4, pode haver centenas de gigabits de tr\u00e1fego, ou, respectivamente, centenas de mpps, se contarmos em pacotes.
\nO problema desses ataques est\u00e1 na sincroniza\u00e7\u00e3o. Os ataques v\u00eam de um botnet, e para criar um grande pico em um \u00fanico momento, \u00e9 necess\u00e1ria uma alta\u7a0b\u5ea6 de sincroniza\u00e7\u00e3o. E essa coordena\u00e7\u00e3o nem sempre \u00e9 alcan\u00e7ada: \u00e0s vezes, no final, obt\u00e9m-se um pico parab\u00f3lico que parece bastante fraco.<\/p>\n

N\u00e3o \u00e9 s\u00f3 HTTP<\/h3>\n

\nAl\u00e9m do HTTP no n\u00edvel L7, gostamos de explorar outros protocolos. Geralmente, um site comum, especialmente um servi\u00e7o de hospedagem comum, tem protocolos de e-mail e MySQL expostos. Os protocolos de e-mail s\u00e3o menos suscet\u00edveis a cargas do que os bancos de dados, mas tamb\u00e9m podem ser sobrecarregados de maneira eficaz, resultando em um CPU sobrecarregado no servidor.
\nConseguimos obter sucesso usando a vulnerabilidade SSH de 2016. Atualmente, essa vulnerabilidade foi corrigida pela maioria, mas isso n\u00e3o significa que n\u00e3o se possa deixar a carga em SSH. \u00c9 poss\u00edvel. Apenas \u00e9 enviada uma carga enorme de autentica\u00e7\u00f5es, e o SSH consome quase todo o CPU do servidor, fazendo com que o site fique lento mesmo com uma ou duas solicita\u00e7\u00f5es por segundo. Assim, essas uma ou duas solicita\u00e7\u00f5es nos logs n\u00e3o podem ser diferenciadas de uma carga leg\u00edtima.
\nMuitas conex\u00f5es permanecem relevantes, as quais abrimos em servidores. Antes, isso era comum no Apache, e agora o nginx tamb\u00e9m comete esse erro, uma vez que frequentemente \u00e9 configurado por padr\u00e3o. O n\u00famero de conex\u00f5es que o nginx pode manter abertas \u00e9 limitado, portanto, ao atingirmos esse n\u00famero, novas conex\u00f5es n\u00e3o s\u00e3o aceitas, e o site deixa de funcionar.
\nNosso cluster de teste possui poder de CPU suficiente para atacar o handshake SSL. De fato, como demonstra a pr\u00e1tica, bots tamb\u00e9m costumam fazer isso. Por um lado, \u00e9 evidente que n\u00e3o se pode prescindir do SSL, devido \u00e0s classifica\u00e7\u00f5es do Google, ranqueamento e seguran\u00e7a. Por outro lado, infelizmente, o SSL apresenta problemas relacionados ao uso de CPU. <\/p>\n

L3&4<\/h3>\n

\nQuando falamos sobre ataques nos n\u00edveis L3&4, geralmente nos referimos a ataques no n\u00edvel de canal. Essa carga \u00e9 quase sempre distingu\u00edvel da carga leg\u00edtima, a menos que seja um ataque SYN-flood. O problema dos ataques SYN-flood para os meios de defesa reside em seu grande volume. O m\u00e1ximo registrado em L3&4 foi de 1,5-2 Tbit\/s. Esse tr\u00e1fego \u00e9 extremamente dif\u00edcil de processar, mesmo para grandes empresas, incluindo Oracle e Google.
\nSYN e SYN-ACK s\u00e3o pacotes utilizados durante o estabelecimento de uma conex\u00e3o. Portanto, o SYN-flood \u00e9 dif\u00edcil de distinguir da carga leg\u00edtima: n\u00e3o est\u00e1 claro se \u00e9 um SYN que chegou para a instala\u00e7\u00e3o da conex\u00e3o ou parte de um flood.<\/p>\n

UDP-flood<\/h3>\n

\nNormalmente, os atacantes n\u00e3o possuem o mesmo poder que n\u00f3s, portanto, para realizar ataques, podem usar amplifica\u00e7\u00e3o. Ou seja, o atacante escaneia a internet e encontra servidores vulner\u00e1veis ou mal configurados que, por exemplo, em resposta a um \u00fanico pacote SYN, respondem com tr\u00eas SYN-ACK. Fingindo o endere\u00e7o de origem do servidor alvo, \u00e9 poss\u00edvel amplificar o poder, digamos, em tr\u00eas vezes, e redirecionar o tr\u00e1fego para a v\u00edtima.<\/p>\n

\"DDoS
\n
\nO problema das amplifica\u00e7\u00f5es est\u00e1 em sua dif\u00edcil detec\u00e7\u00e3o. Um dos exemplos mais recentes \u00e9 o famoso caso do memcached vulner\u00e1vel. Al\u00e9m disso, surgiram muitos dispositivos IoT e c\u00e2meras IP que tamb\u00e9m est\u00e3o predominantemente configurados por padr\u00e3o de forma inadequada, o que tem permitido que atacantes realizem ataques com mais frequ\u00eancia atrav\u00e9s desses dispositivos. <\/p>\n

\"DDoS
\n<\/p>\n

SYN-flood n\u00e3o \u00e9 um assunto simples<\/h3>\n

\nSYN-flood \u00e9, sem d\u00favida, o tipo mais interessante de ataque do ponto de vista do desenvolvedor. O problema \u00e9 que muitas vezes os administradores de sistemas utilizam bloqueio por IP como forma de prote\u00e7\u00e3o. Contudo, com esse bloqueio, n\u00e3o apenas os administradores que seguem scripts s\u00e3o afetados, mas tamb\u00e9m, infelizmente, alguns sistemas de prote\u00e7\u00e3o adquiridos por altos pre\u00e7os.
\nEsse m\u00e9todo pode se transformar em um desastre, pois, se os criminosos substitu\u00edrem endere\u00e7os IP<\/a>, a empresa bloquear\u00e1 sua pr\u00f3pria sub-rede. Quando o Firewall bloqueia seu pr\u00f3prio cluster, as intera\u00e7\u00f5es externas come\u00e7am a falhar, e o recurso fica inacess\u00edvel.
\nE conseguir bloquear a pr\u00f3pria rede n\u00e3o \u00e9 dif\u00edcil. Se houver uma rede Wi-Fi no escrit\u00f3rio do cliente, ou se a funcionalidade dos recursos for medida por meio de v\u00e1rias monitoriza\u00e7\u00f5es, pegamos o endere\u00e7o IP desse sistema de monitoramento ou do cliente Wi-Fi do escrit\u00f3rio e o utilizamos como origem. O recurso parece acess\u00edvel, mas os endere\u00e7os IP-alvo est\u00e3o bloqueados. Assim, a rede Wi-Fi da confer\u00eancia HighLoad, onde um novo produto da empresa \u00e9 apresentado, pode ser bloqueada, resultando em custos empresariais e econ\u00f4micos significativos.
\nDurante os testes, n\u00e3o podemos utilizar a amplifica\u00e7\u00e3o atrav\u00e9s do memcached com recursos externos, pois existem acordos para direcionar o tr\u00e1fego apenas para endere\u00e7os IP permitidos. Portanto, utilizamos a amplifica\u00e7\u00e3o atrav\u00e9s de SYN e SYN-ACK, onde o envio de um SYN \u00e9 respondido com dois ou tr\u00eas SYN-ACK, resultando em um aumento do ataque em duas a tr\u00eas vezes. <\/p>\n

Ferramentas<\/h3>\n

\nUma das principais ferramentas que utilizamos para carga no n\u00edvel L7 \u00e9 o Yandex-tank. Em particular, um Phantom \u00e9 usado como canh\u00e3o, al\u00e9m de haver v\u00e1rios scripts para gerar proj\u00e9teis e para analisar os resultados.
\nPara analisar o tr\u00e1fego de rede, usamos o Tcpdump, e para an\u00e1lise do servidor, o Nmap. Para criar carga nos n\u00edveis L3&4, utilizamos o OpenSSL e um pouco da nossa pr\u00f3pria magia com a biblioteca DPDK. A DPDK \u00e9 uma biblioteca da Intel que permite trabalhar com a interface de rede, desviando da pilha do Linux, aumentando assim a efici\u00eancia. Naturalmente, usamos a DPDK n\u00e3o apenas no n\u00edvel L3&4, mas tamb\u00e9m no n\u00edvel L7, pois ela permite criar um fluxo de carga muito alto, na faixa de milh\u00f5es de requisi\u00e7\u00f5es por segundo a partir de uma \u00fanica m\u00e1quina.
\nTamb\u00e9m utilizamos certos geradores de tr\u00e1fego e ferramentas especiais que desenvolvemos para testes espec\u00edficos. Se lembrarmos da vulnerabilidade no SSH, o conjunto mencionado n\u00e3o pode ser explorado. Se atacarmos o protocolo de e-mail, usamos utilit\u00e1rios de e-mail ou simplesmente escrevemos scripts para eles.<\/p>\n

\n

Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h3>\n

\nComo conclus\u00e3o, gostaria de dizer:<\/p>\n