Olá caros leitores dessa coisa aqui!
Depois de viajar pela história das gravações, dos discos e de outras fonografias, hoje vamos falar de outra história: a história da segurança digital. Ou, para sermos mais exatos, a eterna corrida entre quem inventa uma nova maneira de invadir, derrubar, roubar ou sequestrar um sistema e quem precisa descobrir uma nova maneira de impedir a desgraceira.
No início, muitos ataques pareciam experiências, brincadeiras de gosto duvidoso ou demonstrações de habilidade. Com o tempo, o negócio virou indústria: apareceram quadrilhas especializadas, mercados clandestinos, aluguel de botnets, venda de credenciais, extorsão por ransomware e ataques tão grandes que um servidor sozinho não tem sequer como receber todo o tráfego, quanto mais analisá-lo.
As defesas também evoluíram. Vieram os antivírus, os firewalls, os sistemas de detecção de intrusão, os filtros de aplicação, os mecanismos antibruteforce, os serviços antiddos, a autenticação multifator, os sistemas de análise de comportamento e uma sopa de siglas capaz de derrubar um administrador antes mesmo que o invasor faça isso,aaa.
O problema é que, no meio dessa evolução, algumas empresas passaram a cometer um erro perigoso: contrataram uma excelente muralha externa e concluíram que já não precisavam proteger a própria porta. Colocam o site atrás de uma Cloudflare da vida ou de outro serviço semelhante, ativam algumas opções no painel e passam a agir como se firewall local, atualização, antivírus ou antimalware, monitoramento, controle de acesso e cópia de segurança fossem coisas do passado.
Não são.
Quando o ataque ainda precisava pegar carona num disquete
Os primeiros programas autorreplicantes surgiram quando as redes ainda eram pequenas e computador conectado era uma raridade. Nos computadores pessoais das décadas de 1980 e 1990, os vírus se espalhavam principalmente por disquetes, infectando arquivos executáveis ou o setor de inicialização.
O ataque daquela época tinha uma limitação quase simpática quando comparada à velocidade atual: ele precisava viajar fisicamente. Alguém colocava o disquete numa máquina, executava alguma coisa ou inicializava o computador com ele inserido e pronto: estava feita a entrega em domicílio. O vírus podia então contaminar outros disquetes e seguir sua peregrinação de computador em computador.
Isso não quer dizer que as redes estivessem livres. Em 2 de novembro de 1988, o Morris Worm se espalhou pela ainda pequena Internet e infectou milhares de máquinas em poucas horas, deixando muitas delas inutilizáveis até que fossem desconectadas e reparadas. O caso é lembrado pelo FBI como o primeiro grande ataque à Internet e mostrou cedo uma característica que depois se tornaria fundamental: um programa não precisava esperar o usuário levá-lo de um computador a outro; podia procurar sozinho a próxima vítima. A história pode ser conferida no artigo The Morris Worm, do FBI.
Nascia ali, para o grande público, a diferença prática entre um vírus e um worm. O vírus geralmente se prende a um arquivo ou depende de alguma ação para se espalhar. O worm explora a rede e tenta se propagar por conta própria. Na vida real, claro, as categorias se misturam: um mesmo malware pode chegar por e-mail, explorar uma falha, instalar um trojan, abrir uma “porta dos fundos” e ainda transformar a máquina num robô controlado remotamente.
A Internet cresceu, e a desgraceira ganhou banda larga
Quando vieram a popularização da Internet, o correio eletrônico e a web, a distribuição dos ataques deixou de depender do disquete esquecido no drive. Anexos maliciosos, macros em documentos, páginas comprometidas, programas piratas e falsos instaladores passaram a alcançar milhares ou milhões de pessoas.
O vírus clássico continuou existindo, mas ganhou companhia:
- Worms, que procuram outras máquinas e se espalham automaticamente;
- Trojans, que fingem ser programas legítimos para o usuário abrir a porta por conta própria;
- Spywares e infostealers, feitos para roubar informações, senhas, cookies e sessões autenticadas;
- Rootkits, que tentam esconder a presença do invasor e manter acesso privilegiado;
- Ransomwares, que criptografam ou roubam dados para extorquir a vítima;
- Botnets, redes de computadores, servidores, roteadores, câmeras e outros aparelhos comprometidos e controlados à distância.
Também cresceram os ataques que nem precisam instalar um vírus no computador da vítima. Entram nessa turma a força bruta contra senhas, o uso automatizado de credenciais vazadas, a exploração de serviços desatualizados, as falhas de autenticação, a injeção de SQL, o cross-site scripting, a engenharia social e o bom e velho phishing — aquele golpe que troca de roupa de tempos em tempos, mas continua tentando convencer alguém a entregar voluntariamente a chave da casa.
Ataque digital, portanto, não é sinônimo de vírus. Um servidor pode ser invadido sem que um arquivo malicioso tradicional seja gravado nele. Uma senha reutilizada, uma extensão vulnerável, um painel administrativo exposto ou uma configuração errada podem ser suficientes.
Do computador sequestrado ao exército de cafeteiras
Outro salto veio com os ataques de negação de serviço. Num ataque DoS, o objetivo é consumir os recursos de um servidor, serviço ou enlace até que os usuários legítimos não consigam mais utilizá-lo. No DDoS, o primeiro D significa distributed: o tráfego vem de muitos pontos ao mesmo tempo.
É aí que entram as botnets. Em vez de um único computador atirar pacotes contra o alvo, milhares de máquinas comprometidas fazem isso juntas. E, com a Internet das Coisas, o exército passou a incluir câmeras, gravadores de vídeo, roteadores, televisores, sensores e qualquer outra geringonça conectada com senha padrão e firmware abandonado.
A botnet Mirai mostrou isso de forma espetacular em 2016: infectava dispositivos de Internet das Coisas tentando combinações padrão de usuário e senha e os transformava em robôs para ataques distribuídos. Uma das ações associadas a ela atingiu a Dyn e afetou o acesso a vários grandes serviços. A explicação da Cloudflare sobre a Mirai mostra como aparelhos aparentemente inocentes podem virar soldados de um ataque sem que seus donos sequer percebam…
Hoje um DDoS pode tentar saturar a conexão, esgotar tabelas de estado, abusar de protocolos ou imitar acessos legítimos na camada da aplicação. É por isso que a defesa contra ataques volumétricos realmente precisa de infraestrutura distribuída e capacidade muito maior do que a do servidor protegido. Não há regra de firewall local que faça caber dez caminhões de tráfego numa garagem para um Fusca.
A evolução do antivírus: da lista de procurados ao comportamento suspeito
Os primeiros antivírus comerciais trabalhavam principalmente com assinaturas: sequências conhecidas que permitiam reconhecer um arquivo contaminado. Era como entregar ao porteiro uma pasta com fotografias dos criminosos já identificados. Se o rosto estivesse na lista, ele barrava. Se fosse um criminoso novo ou suficientemente disfarçado, podia passar.
As assinaturas continuam importantes, mas as soluções modernas acrescentaram heurística, análise de comportamento, reputação em nuvem, aprendizado de máquina e resposta no endpoint. Em vez de perguntar apenas “este arquivo está na lista?”, o sistema também observa perguntas como “por que este processo está tentando alterar centenas de documentos?”, “por que ele quer criar persistência?” ou “por que está acessando credenciais e iniciando conexões incomuns?”. A própria Microsoft explica essa mudança na documentação sobre monitoramento de comportamento do Microsoft Defender.
Em ambientes corporativos, surgiram ainda as soluções EDR, capazes de registrar atividades, correlacionar eventos, ajudar na investigação e reagir a comportamentos suspeitos. Mas nem o melhor antivírus é uma bênção papal aplicada ao servidor. Se estiver desatualizado, mal configurado, sem monitoramento ou cheio de exceções para “não atrapalhar”, vira apenas um ícone tranquilizador no painel.
A evolução do firewall: fechar portas, entender conexões e olhar a aplicação
O firewall também evoluiu. Os filtros de pacotes mais simples analisavam informações como endereço, protocolo e porta. Depois vieram os firewalls com inspeção de estado, capazes de acompanhar as conexões e distinguir melhor um pacote esperado de outro que apenas finge pertencer a uma conversa já estabelecida. A publicação Guidelines on Firewalls and Firewall Policy, do NIST, explica essa diferença entre filtragem e inspeção de estado.
Mais tarde, firewalls de aplicação, proxies e WAFs passaram a examinar o protocolo usado pela aplicação. Um WAF olha especialmente para o tráfego HTTP e tenta identificar padrões de ataques contra sites e APIs, como injeção de SQL e cross-site scripting. A OWASP define o WAF justamente como um firewall para aplicações HTTP, normalmente colocado diante dos servidores como proxy reverso.
Percebam a diferença: um WAF não é simplesmente uma versão “melhor” do firewall do sistema operacional. Eles atuam em lugares e problemas diferentes. O firewall da rede ou do host decide quais serviços e origens podem estabelecer conexões. O WAF analisa as requisições destinadas à aplicação web. Um não demite o outro.
IDS, IPS, antibruteforce, registros e outras camadas
À medida que os ataques ficaram mais complexos, tornou-se necessário não apenas bloquear, mas também detectar, registrar, correlacionar e responder.
Os sistemas IDS procuram sinais de intrusão e alertam. Os IPS podem agir para interromper atividades suspeitas. Ferramentas antibruteforce acompanham tentativas repetidas de acesso e bloqueiam a origem. Sistemas de logs e SIEM reúnem eventos para que uma sequência aparentemente inocente deixe de parecer inocente quando vista como um todo. Monitoramento de integridade acusa mudanças inesperadas em arquivos. Segmentação impede, ou pelo menos dificulta, que a invasão de uma máquina se transforme num passeio turístico por toda a rede.
Quando comecei a lidar mais diretamente com servidores, em 2011, eu já usava firewall, antibruteforce, ddosdeflate, ClamAV com Maldet, cópias de segurança e outros recursos. Nenhuma dessas ferramentas, sozinha, resolvia tudo. A idéia era justamente que uma cobrisse parte do espaço que a outra não cobria. E, antes de levar uma mudança para o servidor, testar numa máquina virtual com snapshot sempre foi uma forma muito mais civilizada de evitar um revertério.
Esse princípio ganhou um nome bonito, embora a idéia seja antiga: defesa em profundidade. A OWASP explica a defesa em profundidade como a utilização de várias camadas, de modo que a falha de uma não produza imediatamente o comprometimento total do sistema.
Quando a muralha virou serviço
Com ataques cada vez maiores, fez todo o sentido colocar redes globais entre o usuário e o servidor. Serviços como Cloudflare, Akamai, Fastly, Imperva e outros podem distribuir conteúdo, absorver ataques volumétricos, esconder o endereço do servidor de origem, filtrar robôs, limitar requisições e aplicar regras de WAF numa escala que a maioria das empresas jamais conseguiria montar sozinha.
Isso é bom. Muito bom.
Seria absurdo sugerir que uma pequena ou média empresa tentasse absorver sozinha um ataque de centenas de gigabits ou terabits por segundo. O serviço externo existe justamente porque certos problemas precisam ser enfrentados antes que o tráfego chegue ao enlace do cliente. Se a conexão já foi saturada, o firewall local pode escrever uma carta de protesto, mas ela também não vai conseguir sair pela rede,aaa.
A terceirização de uma camada da segurança é racional. O erro começa quando se terceiriza mentalmente a responsabilidade inteira.
O muro do terceiro não protege uma porta deixada aberta
Imaginemos a Cloudflare como uma grande muralha diante de um prédio. Ela controla boa parte do fluxo, barra multidões suspeitas e recebe o impacto de ataques que derrubariam o portão da empresa. Só que, atrás dessa muralha, o prédio continua tendo portas, janelas, funcionários, computadores, fechaduras, documentos e uma sala de servidores.
Se a porta dos fundos está aberta, a altura do muro da frente deixa de ser o principal assunto.
No uso mais comum, quando se ativa o proxy da Cloudflare para um site, protege-se principalmente o tráfego web que realmente passa por ela. Isso não significa automaticamente que SSH, banco de dados, e-mail, painel de hospedagem, APIs em outros endereços e serviços esquecidos foram protegidos. A Cloudflare possui produtos capazes de estender a proteção a outros cenários, mas eles precisam ser contratados, projetados e configurados. O simples fato de o DNS exibir a nuvenzinha laranja não lança um “feitiço anti-Voldemort” sobre todas as portas do servidor, aaa…
Há ainda um problema básico: se alguém descobrir o IP real do servidor de origem e ele aceitar conexões vindas de qualquer lugar, o atacante pode tentar acessá-lo diretamente e contornar toda a proteção colocada no proxy.
E aqui aparece a melhor testemunha possível para a tese deste artigo: a própria Cloudflare. Em sua documentação sobre como proteger o servidor de origem, a empresa recomenda esconder e, quando necessário, trocar o IP de origem, revisar registros DNS que possam revelá-lo, restringir conexões, permitir apenas os endereços necessários e monitorar a saúde do servidor. Também oferece recursos como Tunnel e Authenticated Origin Pulls.
Na documentação de Authenticated Origin Pulls, a explicação é ainda mais direta: sem esse controle, quem descobrir o IP de origem pode enviar requisições diretamente e contornar as proteções da Cloudflare. Ou seja: nem a Cloudflare acha que basta apontar o DNS para ela e seguir o baile.
O que continua podendo dar errado
Mesmo quando o IP de origem está bem protegido e só aceita tráfego vindo do proxy, o trabalho não acabou. A camada externa reduz enormemente o risco, mas há ataques que chegam em tráfego aparentemente permitido ou nem passam por ela.
- Uma vulnerabilidade na aplicação pode ser explorada por uma requisição que o WAF não reconheça como maliciosa;
- Uma falha de lógica pode permitir que um usuário faça algo que tecnicamente parece válido, mas não deveria ser autorizado;
- Credenciais roubadas podem dar ao criminoso acesso legítimo a um painel, VPN, e-mail ou conta administrativa;
- Um plugin, tema, pacote ou componente comprometido pode introduzir código malicioso por uma atualização;
- Um arquivo enviado por um usuário pode carregar malware para dentro do ambiente;
- Um serviço não protegido pelo proxy pode ser atacado diretamente;
- Uma máquina interna comprometida pode atacar o servidor de dentro da rede;
- Uma configuração errada pode reabrir uma porta, expor um painel ou publicar uma cópia de segurança;
- Uma invasão já consumada pode gerar conexões de saída, alterar arquivos, roubar dados e se mover lateralmente sem que o filtro da entrada web resolva o problema.
Um WAF também não corrige magicamente código vulnerável. Ele pode bloquear padrões conhecidos, reduzir a exposição e até funcionar como “remendo virtual” enquanto a correção verdadeira é preparada. Mas o remendo não deve virar parte permanente da parede porque ninguém quer chamar o pedreiro…
Firewall local não é enfeite de painel
O servidor de origem deve ter firewall — ou um controle de rede equivalente — com política restritiva. Em vez de deixar tudo aberto e bloquear apenas o que já causou problema, a lógica deve ser permitir somente o necessário.
Se o site precisa receber conexões web apenas da rede do provedor de proteção, o firewall pode limitar as portas correspondentes a essas origens. O SSH pode ficar acessível somente por VPN, Tailscale, rede administrativa ou endereços específicos. O banco de dados, salvo necessidade muito bem justificada e protegida, não deveria estar passeando publicamente pela Internet. Painéis administrativos precisam de restrição, autenticação forte e, sempre que possível, uma camada adicional de acesso.
É importante lembrar que “firewall instalado” e “firewall configurado” são duas situações diferentes. Um firewall que permite tudo cumpre uma função muito parecida com a de um segurança que abre a porta, deseja boa noite ao invasor e ainda indica onde fica a sala dos cofres.
Antivírus e antimalware também não ficaram obsoletos
Outro exagero comum é afirmar que servidor Linux não precisa de antivírus ou antimalware. A resposta correta depende do serviço, dos dados e do risco, mas dispensar a análise sem sequer avaliar o ambiente é preguiça, não arquitetura.
Um servidor de hospedagem, e-mail, compartilhamento ou upload pode armazenar arquivos destinados a máquinas Windows, scripts maliciosos, webshells e conteúdo contaminado mesmo que o malware não tenha sido criado para infectar o próprio Linux. Ferramentas como ClamAV, Maldet, monitoramento de integridade e análise de comportamento cobrem problemas diferentes. Elas precisam ser escolhidas e configuradas conforme a carga de trabalho; não instaladas apenas para produzir um relatório bonito.
Também vale o caminho inverso: ter antivírus não autoriza deixar o sistema desatualizado, executar tudo com privilégios excessivos ou ignorar os registros. Segurança não é juntar produtos até formar uma coleção de ícones verdes.
Cópia de segurança é a última porta — e precisa abrir
Quando todas as camadas falham, a organização precisa conseguir responder e recuperar. O atual modelo do NIST organiza a segurança em seis funções: governar, identificar, proteger, detectar, responder e recuperar. A publicação NIST SP 800-61 Rev. 3 reforça que prevenir é apenas parte do trabalho; detectar incidentes, contê-los, erradicá-los e restaurar o serviço também fazem parte do ciclo.
É aqui que entram cópias de segurança separadas, protegidas e testadas. Backup permanentemente montado com permissão de escrita pode ser criptografado junto com os dados principais. Snapshot ajuda muito em diversas situações, mas não substitui uma cópia independente. E backup que nunca teve a restauração testada é, no máximo, uma esperança compactada.
O guia StopRansomware, da CISA, recomenda manter cópias críticas offline, criptografadas e testadas regularmente. Não é excesso de zelo: muitos ransomwares procuram justamente os backups acessíveis para apagá-los ou criptografá-los antes de anunciar o sequestro.
Uma arquitetura mínima sem “setealém tecnológico”
Não existe receita idêntica para todas as empresas, mas uma proteção minimamente responsável costuma combinar várias destas medidas:
- Manter inventário dos servidores, serviços, domínios, portas e responsáveis;
- Atualizar sistema operacional, painel, servidor web, aplicações, plugins e dependências;
- Usar firewall de rede e de host com regra de negar por padrão e liberar somente o necessário;
- Restringir o servidor de origem ao proxy, usar mTLS, túnel ou outro mecanismo adequado quando possível;
- Proteger acessos administrativos com chaves, autenticação multifator e privilégio mínimo;
- Separar serviços e redes para limitar o estrago de um comprometimento;
- Aplicar WAF, limitação de requisições, proteção contra robôs e mitigação antiddos;
- Usar antimalware, análise de arquivos e monitoramento de integridade conforme a carga de trabalho;
- Centralizar logs, criar alertas úteis e garantir que alguém realmente os veja;
- Manter cópias de segurança independentes e testar a restauração;
- Ter um plano de resposta: quem isola, quem comunica, quem recupera e quem decide;
- Revisar periodicamente tudo isso, porque a configuração segura de ontem pode ser a porta esquecida de amanhã.
A Cloudflare ou qualquer outro fornecedor pode participar de várias dessas camadas. Pode oferecer uma infraestrutura fantástica, inteligência de ameaças, WAF, antiddos, controle de acesso e túneis. Mas alguém dentro da empresa ainda precisa decidir o que será protegido, fechar o que não deve estar exposto, corrigir o servidor, cuidar das credenciais, analisar os alertas e saber restaurar os dados.
Terceirize a muralha, não a responsabilidade
A história da segurança digital ensina uma coisa bastante simples: toda defesa absoluta acaba encontrando um ataque que passa por outro caminho. Foi por isso que saímos do antivírus baseado apenas em assinatura para a análise de comportamento; do filtro simples de pacotes para a inspeção de estado e os firewalls de aplicação; do servidor isolado para redes globais de mitigação; e da idéia de “impedir tudo” para um ciclo que também inclui detectar, responder e recuperar.
Serviços como a Cloudflare são uma parte valiosa dessa evolução. O erro não está em utilizá-los. O erro está em olhar para o muro do terceiro e, encantado com a altura dele, retirar a fechadura da própria porta.
Segurança terceirizada pode ampliar capacidade, distribuir tráfego e trazer conhecimento especializado. Responsabilidade terceirizada produz cegueira. A empresa continua responsável pelo servidor de origem, pelos dados, pelos acessos, pelas atualizações, pelos registros, pelas cópias de segurança e pelas decisões tomadas depois que o painel do fornecedor ficou verde.
Portanto, coloque o site atrás de uma boa rede de proteção, use WAF, CDN e antiddos, esconda o IP de origem e aproveite tudo o que esses serviços oferecem. Mas mantenha firewall na porta, controle quem entra, monitore o que acontece lá dentro e tenha como reconstruir a casa se alguma coisa der errado.
Porque o muro pode ser do terceiro.
A porta continua sendo sua.
Um abraço… e até o próximo, quando também vamos navegar pela história — só que, desta vez, pela história do rádio! E depois… Boom! Vão precisar ler o artigo seguinte para descobrir,aaa…
Fernando
Fernando
Deixe um comentário