SS - 12 - Ataques de negação de serviço

Neste exato momento, uma câmera de segurança instalada no teto de um armazém, um roteador doméstico acumulando poeira no canto de uma sala de estar, ou até uma babá eletrônica no quarto de uma criança, podem estar disparando um ataque brutal contra a infraestrutura de um banco internacional.

E o mais bizarro é que os donos desses aparelhos não fazem a menor ideia de que os dispositivos deles viraram armas de guerra, né? Nenhuma ideia. Tipo, zero. E essa é a realidade na internet moderna. A gente tem essa expectativa geral de que a infraestrutura digital é um ambiente super cirúrgico, sabe? Onde um pacote de dados viaja pacificamente do ponto A ao ponto B. Aham, uma rodovia super organizada. Exato.

Mas por trás dessa ilusão de ordem, existe um campo de batalha invisível focado em esgotar recursos. E é por isso que quando a tela do aplicativo do banco congela, ou quando aquele e-commerce gigantesco sai do ar bem no meio de uma promoção, raramente há um cabo desconectado.

Ou um estagiário que esbarrou na tomada, como o pessoal gosta de brincar. Pois é. Na esmagadora maioria das vezes, o que a gente está vendo é o resultado de um ataque de negação de serviço. Os famosos ataques DOS e DDOS. Isso mesmo. E o objetivo da nossa inversão de hoje é justamente abrir o capô dessa guerra invisível.

A gente vai desconstruir a mecânica desses ataques, entender as consequências financeiras e operacionais que causam tanto estrago e analisar como a engenharia tenta manter tudo funcionando. E para guiar essa nossa discussão de uma forma bem estruturada, a gente vai usar as anotações da aula de segurança de sistemas do professor André Luiz Favaretto. É um material bem pragmático sobre essas ameaças.

É um roteiro excelente, sem puxar muito o saco, mas o material realmente disseca a anatomia do ataque em frentes muito claras para quem quer entender o lado técnico.

Sim, ele vai direto ao ponto. Mas o primeiro passo, antes de falar de técnica, é entender a motivação fundamental. O que exatamente está na mira de um ataque de negação de serviço? Na segurança da informação, a gente tem aquela tríade básica, que é confidencialidade, integridade e disponibilidade. Certo, os três pilares. Exato. E esse tipo de ataque mira única e exclusivamente no terceiro pilar.

A disponibilidade, ou seja, a garantia de que o serviço, o sistema ou até o dado possa ser acessado no momento exato em que a pessoa precisa usar. Perfeito. O ataque não está focado em quebrar a criptografia para roubar números de cartão de crédito. Ele não quer roubar nada. Ele foca em destruição de acesso.

E o mecanismo primário para destruir esse acesso, pelo que o material do professor Favarito mostra, é o esgotamento de recursos finitos.

Porque a internet parece infinita para quem usa, né? Mas a infraestrutura física e lógica tem limites bem rígidos. A gente está falando da capacidade do link de rede, da memória RAM de um servidor, dos ciclos de processamento da CPU, ou até do espaço na tabela de conexões de um firewall. O atacante mapeia onde está o gargalo mais frágil e direciona toda a pressão para romper esse limite.

A consequência óbvia de romper esse limite é aquela famosa tela de erro, o site totalmente fora do ar. Mas, lendo a análise, fica claro que a indisponibilidade total nem sempre é o pior cenário para as empresas. Nossa, de jeito nenhum. Muitas vezes, o impacto financeiro mais devastador vem da degradação contínua.

A famosa lentidão. Isso. A página não cai de vez, mas ela demora, sei lá, três minutos para processar um único clique. E essa degradação é um veneno lento para as operações corporativas. Porque quando um serviço fica intermitente, os usuários legítimos ficam frustrados e começam a tentar recarregar a página repetidas vezes. O famoso botão de F5 sem parar. E, ironicamente, isso aumenta ainda mais a carga sobre a infraestrutura que já está sobrecarregada pelo ataque.

É um efeito bola de neve, né? E o custo para a empresa vai muito além da perda direta daquela venda momentânea. Tem um impacto muito forte na perda de confiança. Com certeza. Clientes e parceiros comerciais passam a questionar a estabilidade tecnológica da instituição. Pensa comigo. Se o seu aplicativo do banco não abre na hora que você precisa pagar uma conta no mercado, você não vai pensar, ah, eles estão sofrendo um DDOs.

Não, você vai pensar esse banco é ruim, vou trocar de banco amanhã. Exatamente. E isso gera uma crise interna imediata na empresa. As equipes de engenharia, os desenvolvedores de produto, o pessoal de operações de TI, todo mundo precisa abandonar os projetos estratégicos.

Para montar uma sala de guerra. Isso. O custo de resposta à incidente simplesmente explode, todo mundo trabalhando sob extrema pressão, horas extras acumulando e muitas vezes a empresa precisa contratar serviços de mitigação de emergência de terceiros. Que devem cobrar taxas altíssimas, né? Já que não foi planejado antes.

Taxas absurdamente altas. O prejuízo operacional de um ataque prolongado é astronômico. Caramba! Bom, antes de entrar em como a defesa atua para evitar esse pesadelo, a grande questão é como os atacantes criam esse nível de estrago. Então, o material do professor Favaretto separa as táticas em três frentes principais de ataque.

Três frentes. Vamos começar pela primeira, um método da força bruta pura, que é o ataque volumétrico. Pelo nome, a estratégia é inundação, certo? Basicamente isso. Mas, espera aí. Por que os provedores de internet simplesmente não bloqueiam o endereço IP de onde esse volume gigantesco de tráfego está vindo?

Porque raramente vem de um lugar só, e é aí que a sigla DOS evolui para DDoS, com o primeiro D significando distribuído. Ah, o distribuído. Isso.

No ataque volumétrico, o objetivo é esgotar a largura de banda. Imagina a conexão de internet de um data center como se fosse um tubo de encanamento mesmo. Tá, um cano de água. Se a capacidade máxima desse tubo é de, digamos, 10 gigabits por segundo, o atacante tenta enviar 100 gigabits. Vai estourar o cano.

Exato, só que esse lixo digital não vem de um único computador. Ele vem de dezenas de milhares de origens simultaneamente ao redor do mundo. E aqui entram os protocolos específicos que o material menciona, né? Tem inundações via UDP e ICMP. Protocolos diferentes têm regras diferentes, como se funciona na mecânica da rede.

É que a internet usa protocolos diferentes para transportar dados dependendo do que você quer fazer. O TCP, que é o mais comum para navegar em sites, ele exige um acordo. Uma confirmação de que os dois lados estão prontos para conversar. Um aperto de mãos. Isso. Já o UDP é um protocolo de disparo rápido. Não tem confirmação de entrega. É o equivamento a você despachar milhares de cartões postais pelos correios sem colocar remetente e sem se importar se eles vão chegar ou não no destino.

Nossa, então é muito fácil gerar um monte de lixo. Muito fácil. O atacante gera pacotes UDP falsificados em massa. Esse tráfego inunda todo o caminho até o servidor, enchendo o tubo de internet antes mesmo que qualquer roteador interno da empresa consiga processar o que é requisição legítima e o que é ataque. Então uma saturação física do caminho mesmo.

Os pacotes legítimos tentam entrar, mas simplesmente não tem espaço nos cabos e nos roteadores de borda. Exatamente. O ataque volumétrico joga o jogo do tamanho, da força bruta. Mas o jogo muda completamente na segunda frente, né? O ataque de protocolo.

Porque se a ideia não é saturar a largura de banda, a mecânica precisa ser mais inteligente, mais sofisticada. Com certeza. O ataque de protocolo, que a gente também chama de exaustão de estado, explora uma vulnerabilidade no próprio design de como as redes conversam. Como assim? O alvo aqui não é o link de internet, o cano. O alvo são os equipamentos que gerenciam a infraestrutura, como os firewalls, os balanceadores de carga e o sistema operacional dos servidores.

Entendi. O exemplo clássico que o material do Favaretto traz é o SimFluge, que foca em derrubar aquele protocolo TCP que a gente acabou de mencionar que precisa do acordo. Tá, deixa eu tentar visualizar isso. Se o TCP exige um acordo entre as partes antes de transmitir os dados de fato, o ataque deve acontecer exatamente nesse momento de estabelecer o acordo, né?

Perfeito, você pegou a ideia. A conexão legítima TCP funciona em três etapas. É o que chamamos de Handshake de três vias. O aperto de mãos. Isso. O cliente envia um pacote SING, que significa sincronizar.

É basicamente ele pedindo para abrir uma conversa. O servidor recebe isso, aloca um bloco na memória RAM para guardar os dados dessa futura conversa e responde com um SIM AC, confirmando que está pronto. Tá, ele diz recebi e estou pronto. Aí, por último, o cliente manda o ACK final e a transferência de dados começa de verdade. É bem formal, né? O cliente estende a mão, o servidor aperta e o cliente balança a mão de volta.

Exatamente. Mas o que o ataque de SIM Flood faz é enviar uma tempestade desses pedidos iniciais, os SIMs, usando endereços IP totalmente falsificados. Ah, entendi. O servidor recebe milhares de pedidos por segundo. Como ele foi projetado para cumprir as regras do protocolo bonitinho, ele aloca um pedaço da memória RAM para cada um desses pedidos e envia a confirmação de volta.

Só que ele está enviando a confirmação para o endereço falso. Isso. A confirmação vai para endereços de IP que não existem ou que nunca pediram nada. E aí, aquele passo final da confirmação, o ACK do cliente, adivinha? Nunca chega. Nossa. Então o servidor fica lá, com a mão estendida, segurando a conexão aberta e esperando uma resposta que não vem nunca.

Exatamente. É o que a gente chama de estado half-open ou semi-aberto. E como a tabela de conexões na memória do servidor ou do firewall tem um número máximo de espaços disponíveis... Ela simplesmente lota. Lota completamente. Quando a tabela atinge 100% de ocupação com essas conexões fantasma, o servidor para de aceitar novas requisições. Ele trava.

Trava. O link de internet pode estar completamente vazio, a CPU pode estar em 0% de uso, mas o serviço cai. O equipamento entrou em colapso puramente por exaustão de estado. Caramba, é brilhante e assustador. Então passamos do ataque volumétrico, que tenta entupir a rodovia inteira.

para o ataque de protocolo, que seria como mandar milhares de caminhões fantasmas pararem nas cabines de pedágio sem pagar, só para bloquear o fluxo de quem vem atrás. É uma ótima analogia. Bloqueia a infraestrutura sem precisar de tanto volume de dados. Só que ainda tem a terceira categoria.

o ataque de aplicação, que também é conhecido como camada 7. E a documentação que a gente está analisando sugere que esse é o mais perigoso e o mais difícil de detectar. Por quê? A grande dificuldade de detectar o ataque de camada 7 é que ele imita o comportamento humano quase à perfeição. Sabe, o ataque de protocolo e o volumétrico geram anomalias massivas na rede. É muito barulho. Dá para ver no gráfico facilmente. Exato.

Mas o ataque de aplicação, não. Ele usa o protocolo HTTP ou HTTPS normal. Ele completa aquele handshake do TCP perfeitamente, balança a mão direitinho. Ele navega pela criptografia sem dar erro.

Espera aí, espera aí. Se a conexão segue todas as regras de segurança e o pacote de dados está perfeitamente bem formado, um firewall tradicional de rede simplesmente deixa o tráfego passar, certo? Sim, ele deixa. O firewall olha para a porta 443 do HTTPS, vê que o certificado bate e abre as portas. Se ele é um tráfego aparentemente normal, como isso se torna um ataque de negação de serviço?

O truque está na assimetria de processamento.

Um firewall de rede avalia um envelope do pacote. Ele não lê a carta dentro dele. Então o tráfego passa. Mas o atacante não está pedindo para acessar a página inicial do site, que é levinha e entregue super rápido por um sistema de cache. Ah, o atacante envia uma solicitação para a área mais pesada da infraestrutura? Exato. O alvo vira o banco de dados interno ou as APIs complexas do servidor web.

Como ele faz isso na prática? Imagina uma função de busca em um sistema de relatórios financeiros bem complexo. O atacante programa um script que submete mil requisições por minuto, pedindo para o sistema cruzar dados de cinco anos atrás, aplicando um monte de filtros difíceis e exportando o resultado para um arquivo PDF. Nossa Senhora!

O link de internet da empresa nem sente essa quantidade de requisições, porque mil pedidos é um tráfego minúsculo na rede. Mas o servidor de banco de dados lá no back-end, ele sobe o uso da CPU para 100% instantaneamente, tentando calcular todas essas requisições super pesadas ao mesmo tempo. Para quem está ouvindo a gente visualizar melhor, é como se um grupo mal intencionado entrasse em um restaurante super movimentado.

Eles entram pacificamente pela porta da frente, sentam nas mesas e agem como clientes perfeitamente normais. Lemas. Isso. Mas aí todos eles pedem o prato mais complexo do menu, aquele que exige que todos os cozinheiros do restaurante trabalhem na mesma panela por duas horas seguidas. A porta do restaurante continua aberta, o salão tem espaço, mas a cozinha sofre um colapso total.

O cliente legítimo que tentar pedir uma simples água vai ter que esperar o dia inteiro. Perfeito! Essa analogia ilustra exatamente o conceito de assimetria que eu comentei. É pouquíssimo esforço do lado do atacante pedir o prato e um custo computacional massivo do lado do alvo, que é a cozinha preparando. É genial!

É, e a situação se torna ainda mais sombria com os ataques mistos, porque os agentes maliciosos modernos não escolhem uma técnica só. Eles combinam as três frentes simultaneamente. As três ao mesmo tempo?

Sim, eles lançam um ataque volumétrico gigante para gerar muito ruído e acionar todos os alarmes da equipe de rede. Enquanto isso, eles se enviam sim floods para tentar travar os firewalls que estão tentando limpar essa inundação. Uma distração pesada. Total.

E aí, enquanto os engenheiros estão lá na sala de guerra lutando contra essas frentes barulhentas, um ataque silencioso de camada 7 entra pelo tráfego que restou, vai direto para a cozinha e apaga o banco de dados. Uau.

É um ataque coordenado impressionante. Mas isso levanta uma dúvida muito forte. Se o ataque de aplicação se mascara como tráfego comum de usuários e ainda por cima vem misturado com ataques volumétricos, como é que uma infraestrutura consegue se defender sem acabar bloqueando clientes genuínos por acidente?

Esse é o grande desafio. Porque, pensa bem, se uma grande loja de e-commerce entra numa promoção de Black Friday, o fluxo de milhares de pessoas clicando e pedindo cálculos complexos no carrinho de compras pode parecer idêntico a um ataque de camada 7, não é?

Sim, parece idêntico se você olhar só para a parte técnica da rede. O primeiro passo para não bloquear o tráfego legítimo durante um pico de uso é correlacionar as métricas de rede com as métricas de negócio. Ferramentas automatizadas olhando só para a rede não têm contexto. O volume de pacote sobe assustadoramente, tanto numa Black Friday quanto sob um ataque.

Então, como o administrador separa o joio do trigo no meio desse caos todo? Analisando o funil de conversão. Em um pico de vendas legítimo, a taxa de requisições web sobe, sim. Mas junto com ela, também sobem as aprovações de cartão de crédito, os logins bem-sucedidos na plataforma e os itens adicionados ao carrinho. E as origens geográficas das conexões fazem sentido para o público-alvo daquela empresa.

Tem um resultado real para o negócio. Exato. Já em um ataque, os gráficos de rede disparam, mas as métricas de negócio ficam planas ou até caem. Há uma explosão de erros de servidor, aqueles famosos códigos 500 ou 503, e uma quantidade massiva de tráfego que vem de regiões ou de provedores completamente fora do escopo de atuação do negócio.

Faz muito sentido. Essa análise contextual é brilhante. Mas a defesa não pode depender de um humano olhando para um gráfico e decidindo na hora, né? É muito rápido. Impossível fazer isso na mão. Quais são as peças do arsenal de defesa da engenharia para automatizar essa separação e manter os sistemas vírus? O que o material traz sobre isso?

Bom, como a gente viu que o firewall de rede tradicional é cego para a complexidade da camada 7 e ele é inútil contra volumes maiores que o próprio link, a defesa precisa ser descentralizada. Ela tem que atuar em múltiplas camadas. Quais são as principais?

Uma das primeiras travas internas é o rate limiting, ou limite de taxa. O equipamento na borda da rede impõe um teto rígido de requisições. A regra define que, sei lá, um único IP só pode acessar a página de busca um número X de vezes por segundo. Se passar desse limite, a conexão é sumariamente derrubada. Basicamente isso. É como um segurança de boate deixando entrar apenas duas pessoas por minuto para evitar tumulto.

Mas espera, e se o ataque de aplicação não for massivo a ponto de bater nesse limite de taxa? Se o atacante for malicioso o suficiente para mandar apenas uma requisição letal, bem complexa, a cada 10 segundos, ele não bate no limite?

Muito bem observado. Nesses casos de ataques que chamamos de low and slow, que são lentos e de baixo volume, o limite de taxa falha mesmo. Aí a engenharia aplica o WAF, Web Application Firewall. É diferente do firewall normal? Muito diferente.

O WF é a ferramenta que inspeciona profundamente a camada 7. Ele literalmente decodifica o tráfego HTTPS, lê o conteúdo da solicitação HTTP por dentro, analisa os cabeçalhos, os cookies e os padrões da requisição em busca de assinaturas de comportamento malicioso. E ele bloqueia a tentativa antes que ela chegue no código da aplicação. Mas tem uma falha lógica aí, não tem?

O F e o controle de taxa são defesas que residem dentro da infraestrutura da empresa-alvo, o datacenter dela. Sim, ficam lá. Então, se um ataque volumétrico gigante de 500 gigabits vier na direção de um datacenter que só tem conexões de 10 gigabits...

o tubo principal vai estourar antes mesmo de um único pacote conseguir encostar no WAF interno. Como você vai limpar algo que é fisicamente maior que a sua própria porta de entrada? E é aí que a mágica acontece. Esse é o momento em que a defesa tem que sair das mãos da empresa local e vai para as nuvens. A infraestrutura usa o conceito de scrubbing centers, que são centros gigantes de lavagem de tráfego.

Lavagem de tráfego, como isso funciona? E a outro. Quando a empresa detecta que o ataque volumétrico vai derrubar o link primário dela, a equipe altera as rotas do BGP globalmente. Eles reescrevem o GPS da internet no meio do voo. Exatamente isso.

Eles anunciam para a rede mundial, atenção, todo o tráfego destinado à nossa rede deve agora fazer um desvio gigantesco para os data centers desta empresa de mitigação especializada. Uau! E esses scrubbing centers, essas empresas parceiras, possuem links de múltiplos terabits de capacidade. O ataque maciço bate nesses escudos externos gigantes.

Lá, eles usam algoritmos de inteligência artificial para absorver o impacto, descartar o lixo volumétrico, e aí eles enviam apenas as requisições limpas e legítimas de volta para o datacenter original, através de um túnel seguro. É um desvio de curso colossal só para garantir que a tempestade se dissipe no oceano e não atinge a cidade costeira. É incrível!

É a única forma de sobreviver a ataques massivos hoje em dia. E tem também as CDNs, as redes de distribuição de conteúdo. Elas operam com uma lógica parecida de diluição de impacto, não é?

Sim, só que as CDNs trabalham com o princípio da distribuição geográfica. Ao invés de você ter apenas um único servidor recebendo todo o tráfego mundial em um país, cópias do seu site são hospedadas em centenas de servidores espalhados pelo globo inteiro. Então, quando vem um ataque, ele é fisicamente distribuído e absorvido por servidores locais na borda da rede, o que impede que a força total do ataque chegue à origem central.

Então, analisando as engrenagens de todas essas defesas e ataques, as notas do professor sobre essa guerra cibernética entregam uma visão bem clara sobre a escalada do problema. Não basta apenas comprar um equipamento maior. Não, de forma alguma. É uma dança constante de observação de métricas, mitigação distribuída na nuvem, inspeção profunda de pacotes na camada 7 e desvios de rota na camada de rede.

O planejamento estrutural detalhado pelo material prova isso. A preparação antecipada e a redundância externa são fundamentais. A resiliência exige essas camadas todas trabalhando juntas e entender como cada uma atua de forma independente é vital para quem trabalha com engenharia de sistemas.

Com certeza. Mas sabe, tem um detalhe nas entrelinhas de tudo que a gente conversou até agora que acho que merece um aprofundamento final, especialmente sobre como os atacantes conseguem gerar aquele primeiro D do DDoS, o aspecto distribuído que a gente citou lá no começo.

Ah, a origem do tráfego. Exato. A questão de onde os soldados desse exército invisível vêm, as origens por trás dos ataques volumétricos monstruosos. Porque a imagem que a maioria da mídia vende para a gente é a de laboratórios secretos, cheios de hackers com capuz e supercomputadores trabalhando em conjunto em um porão. É, o clássico de Hollywood.

Mas a realidade da arquitetura moderna de um ataque DDoS é sustentada por algo muito mais mundano, as famosas botnets.

O conceito de botnet é absolutamente central para entender o poderio destrutivo atual. Uma botnet é uma rede composta por centenas de milhares, às vezes milhões de dispositivos conectados à internet, que foram secretamente comprometidos. E agora eles respondem a um único servidor de comando e controle, que a gente chama de servidor C2.

E o invasor não precisa de super habilidades para isso, né? Ele explora vulnerabilidades super básicas, como senhas fracas ou portas que ficaram abertas em dispositivos sem a mínima segurança.

É muito simples. E aqui entra a ironia assustadora da explosão da internet das coisas, o IoT. Quando a gente fala de botnet hoje, não estamos falando de infecções em laptops de altíssimo desempenho de grandes corporações. Não mesmo. A grande maioria da força computacional que trava bancos globais e derruba sites de governos inteiros vem de aparelhos comuns, residenciais. Aparelhos que a gente tem em casa.

A proliferação desses dispositivos de baixo custo inundou o mundo de minicomputadores conectados à internet o tempo inteiro. Pensa numa câmera IP de segurança, um termostato inteligente conectado no Wi-Fi. Aquela lâmpada controlada por aplicativo. Exato. Ou os modens das próprias operadoras de internet que são fornecidos para o cliente, sem que ninguém nunca troque a senha padrão de administrador. Sabe aquele admin e admin? Clássico.

E nenhum desses aparelhos tem um software antivírus embutido. E quase nunca recebem atualizações de firmware dos fabricantes. O fabricante vende a lâmpada e esquece dela. Exatamente. O malware se instala nesses dispositivos de forma totalmente silenciosa. Ele cria uma ponte de comunicação com o servidor de comando e controle lá do atacante. E entra em estado de hibernação.

E o dono não percebe nada. Nada. A câmera continua filmando a entrada da garagem do usuário normalmente. A lâmpada inteligente continua acendendo e apagando pelo celular da pessoa. Nada aparece errado na superfície. Essa é a engenharia macabra do processo.

E aí o atacante que controla a botnet pode alugar esse exército gigantesco no mercado paralelo da Dark Web para quem quiser pagar. Sim, viram o serviço. GDOS as a Service. No momento designado, o servidor de comando emite um sinal único para um milhão de lâmpadas, câmeras e roteadores simultaneamente, dizendo enviem cinco pacotes SIM para este endereço IP específico agora.

Caramba! E cada dispositivo envia uma quantidade ínfima de tráfego, né?

É imperceptível para a rede doméstica do usuário. A internet da casa dele nem fica lenta. Não afeta o usuário local. Mas a soma desse esforço minúsculo repetido um milhão de vezes no mesmo milissegundo cria a onda de impacto capaz de dizimar o servidor-alvo em poucos segundos. Complexidade técnica de como um ataque funciona esconde um problema social muito mais profundo sobre a segurança da infraestrutura global. É louco pensar nisso.

Dispositivos que a gente compra para proteger e facilitar o controle das nossas próprias casas são convertidos, por negligência na sua arquitetura inicial de software lá na fábrica, em agentes de destruição. É um encerramento muito provocativo e essencial para quem está ouvindo a gente. As amenaças reais escalaram para fora dos data centers e agora residem silenciosamente nas nossas próprias salas de estar. A defesa das empresas precisa ser tão difusa e inteligente quanto a origem invisível desses ataques.

O que nos deixa com uma reflexão enorme sobre o ambiente que nos cerca o tempo todo. Da próxima vez que houver lentidão na fila do restaurante digital ou que a infraestrutura financeira que você usa parecer instável, vale a pena dar uma olhada para o termostato inteligente pendurado na sua parede. É, pode ser ele ocupado. Pois é.

O silêncio aparente das máquinas que gerenciam a nossa vida cotidiana pode ser apenas o pano de fundo de mais uma batalha gigantesca que está em curso agora mesmo pela garantia da disponibilidade da internet. Esta foi a nossa imersão de hoje, dissecando as artérias, as táticas e a resiliência por trás da negação de serviço. Que a curiosidade por essas engrenagens continue sempre afiada. Até a próxima! Até mais!