Jefferson, 
21 de julho de 2018, 
Ontem um cliente empresarial me chamou dizendo que não tinha acesso ao Hotmail em nenhuma máquina da empresa apesar de ter internet normalmente. Ao chegar, constatei que o acesso parava ao tentar chegar à tela de login no endereço login.live.com. A primeira coisa que tentei foi mudar os servidores DNS da máquina para os da Google mas não surtiu efeito. Então eu tentei um ping para esse endereço e vi que até obtinha o endereço IP, mas o ping falhava. Então conclui que não deveria ser problema de DNS.
Liguei para o suporte técnico do provedor de acesso e a solução dada por eles me surpreendeu: mudar o servidor DNS para o da Cloufdflare. Eu estava cético, mas como ele disse que tinha testado em pelo menos dois outros clientes, eu testei assim mesmo. E funcionou.
Eu comentei com o técnico do provedor que isso era bizarro e ele admitiu que também não entendia a razão e o analista deles estava estudando o problema.
Aqui tive uma tentativa de DDOS em meu DNS local. Não sei dizer ao certo se foi um DDOS ou uma tentativa de infectá-lo. Também tive problemas de direcionamentos para DNSs externos na rede interna, para tentar fazer as máquinas cairem em golpes. Desde então, tenho redirecionado TODO E QUALQUER pedido de DNS da rede na porta 53 para o DNS do OPENDNS (mesmo que nas máquinas esteja configurado um DNS qualquer, mesmo o google, o pedido vai para o OPENDNS). Faço isso no gateway com o iptables, e além de não precisar mais de DNS local, das máquinas locais não usarem DNSs quaisquer, ainda passo pelo filtro de conteúdo do OPENDNS (Pornô, etc. Afinal, é uma rede comercial, e os funcionários não precisam acessar isso no serviço).
Mas onde quero chegar? Simples. O problema deve ser no provedor SIM. Além de possivelmente estar com o DNS comprometido, ainda deve ter um filtro do que for para o DNS do google, para o mesmo DNS comprometido…
Obrigado pelo comentário. Eu não sabia que era tão fácil assim redirecionar consultas DNS. De envenenamento de DNS eu sabia há muito tempo mas na minha inocência eu estava achando que ao fixar o servidor DNS na minha máquina eu estaria protegido de um ataque MITM desse tipo.
Só para ter uma ideia, com apenas 1 comando:
iptables -t nat -I PREROUTING -p udp –dport 53 -d ! $meu-servidor-dns -j DNAT –to-destination $meu-servidor-dns
Recomendo você verificar com o comando do DOS nslookup para onde REALMENTE tá indo seus pedidos. Pode ajudar. Pelo linux o comando dig também pode demonostrar algo interessante…
O nslookup consegue detectar isso? Meu primeiro palpite seria que o nslookup também seria enganado pelo redirecionamento.
Por exemplo, este texto mostra o pasao a passo de um DNS poisoning por meio de ARP spoofing e fica claro que o nslookup não percebe a mudança. Sim, eu sei que o que esse comando iptables faz não é ARP spoofing.
Eu esqueci de acrescentar que o gateway da empresa já estava configurado com os servidores DNS da Google quando o problema ocorreu, por isso eu ter configurado isso manualmente na máquina foi inócuo.
Também esqueci de mencionar que em pelo menos duas máquinas https://bankline.itau.com.br/ também não funcionava. Eu só não estou convicto de que é parte do problema porque a gerente financeira afirmou ter feito pagamentos no itaú no mesmo período. Mas pode ser que ela tenha usado um acesso pessoa jurídica com outro URL. Se for esse o caso então ganha força a sugestão de Marcel de que, além do provedor estar redirecionando DNS, seu servidor estar “mexido”.
Além disso, login.live.com realmente não responde a ping (testado aqui em casa), por isso o fato de eu ter constatado que não respondia também foi inútil.
Outra coisa a acrescentar é que (aqui e agora) login.live.com redireciona para ipv4.login.msa.akadns6.net que por sua vez resolve para vários endereços IP diferentes na faixa 131.253.61.x, tanto usando os servidores da Google quanto o da Cloudflare.