Firewalls e DNS

Quando me mudei para Nova York para trabalhar nas Nações Unidas, cheguei com uma missão bem específica: tomar conta dos firewalls. Havia dois datacenters, cada um com seu conjunto de equipamentos, e um terceirizado que cuidava de tudo. Não demorou para eu descobrir o “truque” que ele usava para não ter problemas: ele deixou os firewalls sem nenhuma regra. O firewall estava lá, piscando as luzinhas, mas deixava passar absolutamente tudo. Sempre que alguém reclamava que o firewall estava atrapalhando algum sistema, ele dizia com convicção que não era o caso. E estava certo. Se o firewall não fazia nada, não podia ser o culpado.

Começamos então o trabalho de mudar aquele cenário, o que era complicado porque aquele ambiente improvisado foi acumulando tech debt por anos. A melhor oportunidade veio quando montamos dois novos datacenters na Europa. Compramos firewalls novos e eu decidi fazer tudo direito desde o início: política de default deny, regras explícitas para cada serviço, nada passando sem ser declarado. Como partimos do zero, até que funcionou, apesar de muitas reclamações de colegas que não estavam acostumados com isso e nem tinham ideia das portas que suas aplicações usavam. Depois disso, era preciso fazer o mesmo nos firewalls antigos de Nova York, que estavam inseridos numa rede com muitos legados.

A rede de Nova York era um Frankenstein. Em algum momento no passado haviam movido o datacenter de lugar e tentaram reconstruir tudo do zero, mas quando o prédio antigo precisou ser esvaziado às pressas, abandonaram a ideia de colocar tudo na rede nova e simplesmente ligaram o resto do jeito que estava na rede antiga. O resultado foi uma mistura caótica de tecnologias e gambiarras. Dentro da equipe havia um engenheiro vietnamita, extremamente detalhista, que tinha desenhado um mapa completo da rede. Quando ele me mostrou o diagrama, aquilo virou o mapa da mina: a partir desse momento, esse virou o mapa oficial da rede. Depois começamos a planejar a reestruturação: remover partes legadas, consolidar tudo no ambiente novo e reescrever regras de firewall de forma organizada.

Compramos um software (Tufin) para analisar os logs e descobrir quais regras eram mais ou menos usadas. Criamos regras completamente abertas para todas as máquinas existentes e definimos um default deny para todo o resto. Assim, estabelecemos que qualquer máquina nova só entraria em produção com suas regras definidas desde o início. Para os serviços existentes, fomos observando as portas que eles usavam e definimos novas regras com base nessas observações. Depois de um tempo, quando tivemos confiança de que tínhamos mapeado todas as portas, ligamos a regra geral de default deny rede por rede, até estarem todas incluídas. Essa mudança gerou uma grande resistência por parte de outros times, a ponto de me dizerem que eu é quem deveria saber quais portas abrir pois eu era responsável pelo firewall. Aí, eu tinha de explicar que saber as portas de rede que a aplicação usa faz parte do trabalho de administrar uma aplicação. Nessa parte tivemos apoio da chefia e do CISO e conseguimos resistir à pressão.

Em 2012, completavam-se 20 anos da Conferência das Nações Unidas sobre Meio Ambiente e Desenvolvimento (Rio 92). Para marcar a data, a ONU organizou a Rio+20, uma nova conferência voltada à discussão de temas ambientais e à avaliação dos avanços desde 1992. Como parte da preparação, uma equipe de seis ou sete pessoas da área de informática foi enviada ao Rio de Janeiro para cuidar da infraestrutura de TI do evento, enquanto o restante de nós permaneceu em Nova Iorque com a responsabilidade de dar suporte remoto ao time em campo. O meu time, especificamente, ficou encarregado de estabelecer e manter uma VPN entre a ONU e a infraestrutura montada no Riocentro. Para isso, entramos em contato com o provedor de rede da conferência e começamos a alinhar os aspectos técnicos com o engenheiro responsável, que, curiosamente, não era brasileiro, mas português — reflexo de uma época em que a economia brasileira estava suficientemente aquecida para atrair profissionais de Portugal.

Depois que a VPN foi estabelecida, parecia que tudo estava funcionando bem, pelo menos à primeira vista. No entanto, pouco tempo depois, um dos engenheiros que estava no Rio, responsável pelos servidores Linux, começou a relatar instabilidades, descrevendo o problema como quedas frequentes da VPN. Quando fomos investigar, não encontramos nenhum indício direto de falha na conexão em si. O comportamento observado era mais sutil e, ao mesmo tempo, mais difícil de diagnosticar: as transmissões começavam com boa velocidade, mas, gradualmente, a taxa de transferência diminuía até praticamente zero. Inicialmente, a VPN foi apontada como a principal suspeita, o que nos levou a revisar configurações e discutir ajustes com o engenheiro português responsável pela infraestrutura de rede, mas, apesar de algumas alterações, o problema persistiu. Na prática, o problema nos acompanhou durante toda a conferência, sem que conseguíssemos chegar a uma causa raiz clara ou a uma solução definitiva.

A situação acabou sendo escalada até o centro de controle da Telemar, para verificar se havia algum problema na interconexão com a AT&T, que era a provedora utilizada pela ONU em Nova Iorque. Em um dos momentos mais curiosos desse processo, participei de uma chamada entre um engenheiro sênior da Telemar e um engenheiro da AT&T, atuando como intérprete, já que o representante brasileiro não falava inglês. Mesmo com esse esforço conjunto, a conversa não levou a nenhuma conclusão concreta, e seguimos sem uma explicação satisfatória para o problema.

Até hoje, eu desconfio que a origem do problema estava nos próprios servidores Linux no Rio de Janeiro. A degradação progressiva da taxa de transmissão sugere algo sensível à latência, um tipo de comportamento que costuma aparecer apenas em redes de longa distância, como a ligação entre Rio e Nova Iorque, e que dificilmente se manifestaria em testes locais, onde a latência é muito menor. Essa suspeita se fortaleceu quando descobrimos que o engenheiro responsável pelos servidores tinha o hábito de alterar parâmetros avançados e recompilar o kernel do Linux com frequência, o que pode introduzir efeitos colaterais difíceis de prever, especialmente em cenários de rede mais complexos e distribuídos.

Paralelamente a esse incidente, havia também um problema estrutural que se tornava evidente: os firewalls haviam sido negligenciados antes da minha chegada. Os equipamentos estavam rodando versões antigas de software, já fora de suporte, o que tornava impossível acionar o fabricante em busca de ajuda quando surgiam problemas mais complexos. Essa limitação aumentava ainda mais a dificuldade de diagnóstico em situações como essa, onde múltiplas camadas da infraestrutura poderiam estar envolvidas. Corrigir esse problema acabou se tornando uma das minhas prioridades, e fiz um esforço significativo para atualizar todos os sistemas e garantir que, pelo menos dali em diante, usássemos sempres versões atualizadas e suportadas.

Bem no início desse esforço, hoje uma consultoria externa que disse que deveríamos trocar todos os firewalls Checkpoint por produtos Palo Alto, que eram considerados os melhores nessa época. Eu fui contra e perguntei qual seria a justificativa para essa mudança. Me disseram que o principal motivo era que os firewalls da Palo Alto tinha sistemas de IDS embutidos. Eu fui contra a mudança e argumentei que a Checkpoint também tinha um IDS nos seus firewalls. Eu disse também que, como estávamos saindo do zero, não havia uma necessidade urgente de adotar o melhor produto do mercado e que implantar um módulo extra nos equipamentos existentes era muito mais rápido. Mas o ponto principal do meu argumento era que já tínhamos investido muito dinheiro e tempo no produto e que já tínhamos um time capacitado e um bom relacionamento com a empresa, o que fazia uma grande diferença na hora de resolver problemas. Eu terminei a minha fala dizendo que podíamos usar a verba que seria gasta na troca para comprar equipamentos Checkpoint de maior capacidade, melhorando o desempenho e aumentando a capacidade da rede. Tanto o CISO quanto o meu chefe aceitaram os meus argumentos e começamos e trabalhar na compra e substituição dos equipamentos.

A troca dos firewalls por equipamentos maiores foi um projeto de grande envergadura e que só terminou no meu último final de semana em Nova York, mas Issa estória vai ficar para outro capítulo mas esse período foi uma imersão profunda na infraestrutura de TI da ONU, naquelas partes que só aparecem quando quebra e todo mundo precisa de uma solução imediata. No fim das contas, eu senti diretamente o peso da palavra “produção”: não tem ensaio, não tem pausa, não tem segunda chance. O trabalho é ao vivo.