Cyberfront: Ucrânia Propõe que ICANN Remova Domínios Russos

O site de Tecnologia TheRegister informa que, em resposta à invasão russa da Ucrânia na semana passada, Mykhailo Fedorov, vice-primeiro-ministro da Ucrânia, pediu na segunda-feira (28-3) à ICANN, todo-poderosa responsável pelo DNS [Domain Name System – Sistema de Nomes de Domínio], que desative os domínios de primeiro nível que tenham código de país associados à Rússia.

Imagem: Pexels

Em um e-mail [PDF], Fedorov pediu a Goran Marby, CEO da ICANN, que imponha sanções à Rússia, argumentando que o regime de Putin usou a infraestrutura da Internet para propagar seu esforço de guerra. Especificamente, ele pediu a revogação dos domínios “.ru”, “.”, “.su” e outros usados ​​pela Federação Russa, desligando os servidores raiz DNS que atendem à Federação Russa e contribuindo para a revogação dos certificados de segurança [TLD/SSL] emitidos para esses domínios.

“Todas essas medidas ajudarão os usuários a buscar informações confiáveis ​​em zonas de domínio alternativas, evitando propaganda e desinformação”, diz o e-mail de Fedorov. “Líderes, governos e organizações de todo o mundo são a favor da introdução de sanções contra a Federação Russa, uma vez que visam pôr fim à agressão contra a Ucrânia e outros países. Ajude a salvar a vida das pessoas em nosso país.”

Fazer isso bloquearia cerca de cinco milhões de domínios da internet global e afetaria significativamente a capacidade da Rússia de se comunicar online.

Em resposta a Prykhodko, Erich Schweighofer, professor da Universidade de Viena e participante da comunidade da ICANN, escreveu: “Nós sabemos e estamos atentos à situação muito difícil e perigosa. [A] União Européia irá apoiá-lo. No entanto, remover a Rússia da Internet não ajuda a sociedade civil desse país em sua luta para uma mudança democrática. A ICANN é uma plataforma neutra, não tomando uma posição neste conflito, mas permitindo que os Estados ajam de acordo – por exemplo, bloqueando o tráfego a um determinado estado.”

Antony Van Couvering, CEO da Top Level Domain Holdings, expressou apoio à ideia: “A neutralidade como resposta ao assassinato não é neutra. De que adianta uma ‘organização da sociedade civil’, se ela se recusa a proteger a mesma sociedade civil, muito menos fazer algo a respeito? Até os políticos acordaram. Até o governo alemão acordou. Até o governo suíço acordou! Enquanto isso, algumas pessoas na ICANN se contentam em repetir frases vazias sobre não se envolver porque isso não ajuda a sociedade civil em seu país. Isso é que é o tal de ‘um mundo, uma internet'”.

A reportagem do Register acrescenta que o registrador de domínio Namecheap* “aconselhou os clientes na Rússia a levar seus negócios para outro lugar, citando crimes de guerra”. No entanto, o CEO da Namecheap, Richard Kirkendall, esclareceu mais tarde que os domínios não foram bloqueados. Em vez disso, eles estão apenas “pedindo às pessoas que voluntariamente se mudem”.

Com tantos se unindo ao lado da Ucrânia (mesmo aqueles que tradicionalmente permanecem neutros em assuntos internacionais), pedir à ICANN que tome medidas contra a Rússia parece ser uma proposta razoável dadas as circunstâncias. Como um bônus, a provável diminuição no spam seria um alívio bem-vindo.

(*) Vox Leone também é cliente do Namecheap, e ficamos contentes com a decisão de R. Kirkendall

Cyberfront: Gigante Russo Kaspersky Tenta Manter a Neutralidade

A revista Motherboard deu conta, ontem (1/3), que no mesmo momento em que forças russas lançavam um ataque de foguetes em uma praça em Kharkiv, a segunda maior cidade da Ucrânia, matando e ferindo um número ainda desconhecido de pessoas, Eugene Kaspersky, CEO da empresa russa de segurança cibernética homônima, twittou singelamente que esperava que as negociações entre a Ucrânia e a Rússia levem a “um compromisso”.

Imagem: Pexels

A declaração resume a posição da empresa desde que a Rússia invadiu a Ucrânia há seis dias: a de uma tentativa de neutralidade em uma guerra onde ficar em silêncio ou em cima do muro significa estar implicitamente do lado das forças russas. Em outra declaração à Motherboard, na segunda-feira (28/3), a empresa disse que “como provedora de serviços de tecnologia e segurança cibernética, a empresa não está em posição de comentar ou especular sobre desenvolvimentos geopolíticos fora de sua área de especialização”.

A Kaspersky é uma das empresas russas mais conhecidas e há anos seu produto antivírus está entre os mais usados ​​no mundo. O software antivírus também coleta dados de telemetria para os pesquisadores da Kaspersky, que podem usá-los – alegadamente – para identificar e combater novas ameaças. Seus pesquisadores são alguns dos melhores do mundo, com sua Equipe de Pesquisa e Análise Global (Global Research & Analysis Team – GReAT) publicando regularmente pesquisas importantes sobre várias operações de malware de vários governos.

Notoriamente, a empresa foi a primeira a revelar a existência e detalhes de um grupo de hackers do governo dos EUA, que apelidou de Equation Group. A Kaspersky também pesquisou supostos hackers ligados ao governo russo.

O tweet de Eugene também traz outro assunto à tona novamente: quanto a Kaspersky, a empresa, é influenciada pelo governo russo, mesmo que indiretamente? É lícito supor que, como uma empresa russa que opera em Moscou sob as leis russas, ela pode sentir pressão para estar em linha com as questões russas.

A declaração na segunda-feira acrescentou que “a Kaspersky está focada em sua missão de construir um mundo mais seguro para governos e consumidores em todo o mundo. As operações comerciais da Kaspersky permanecem estáveis. A empresa garante o cumprimento de suas obrigações com parceiros e clientes – incluindo entrega e suporte de produtos e continuidade de transações financeiras. A equipe de gerenciamento global está monitorando a situação cuidadosamente e está pronta para agir muito rapidamente, se necessário.”

A Kaspersky pode não se sentir em posição de especular ou tomar uma posição sobre a invasão da Ucrânia. Mas com um comboio militar russo de 70 km de comprimento a caminho de Kyiv e com a perspectiva de mais ataques cibernéticos desempenhando um importante papel na invasão, a Kaspersky pode ser obrigada a escolher um lado.

Ucrânia: Notícias do Front

Vivemos tempos extraordinários. Os eventos correntes no leste europeu marcam “um tempo que [pelas suas peculiaridades] nunca foi vivido na história humana”, como disse Thomas L. Friedman no New York Times de hoje [Nunca Estivemos Aqui Antes].

Imagem: Pexels

Portanto é razoável que este blog, em princípio dedicado à ciência e à tecnologia, queira ter este registro histórico em suas páginas. Aqui falamos de sexo + tecnologia, arte + tecnologia, tudo + tecnologia. Vamos então usar a prerrogativa de poder tratar da gloriosa [slavnyy] guerra na Ucrânia, que praticamente é fruto da tecnologia, exibindo [para quem sabe ler] todos os excessos e absurdos de seu DNA social-midiático. Allez.

Um correspondente na Lituânia, nos círculos de Schneier on Security [link], dá conta da interessante nota abaixo nesta manhã de sábado. A origem e veracidade da informação só pode ser especulada, mas é compatível com os dados sobre a Rússia disponíveis a todos no Ocidente. Ponderei um tanto antes de postar, e concluo que a informação vale a pena. Aspas até o fim:

“Intel de um oficial ucraniano sobre uma reunião no covil de Putin nos Urais. Os oligarcas se reuniram nesse local para facilitar a contagem e garantir que ninguém fugisse ao encontro. Putin está furioso, ele pensou que a guerra toda seria fácil e tudo teria terminado em 1-4 dias.

Os russos não tinham um plano tático antes da invasão. A guerra custa cerca de US$ 2 bilhões por dia. Há foguetes para 3-4 dias no máximo, eles estão sendo usados com moderação. Eles não têm armas, as fábricas Tula e 2 Rotenberg não podem cumprir fisicamente os pedidos. Rifles e munição são o máximo que podem fazer.

As próximos lotes de armas russas só podem ser produzidas em um prazo de 3-4 meses – se tanto. Eles não têm matéria-prima. O que antes era fornecido principalmente pela Eslovênia, Finlândia e Alemanha agora está cortado.

Se a Ucrânia conseguir manter os russos afastados por 10 dias, os russos terão que entrar em negociações. Porque eles não têm dinheiro, armas nem recursos. No entanto, eles estão indiferentes quanto às as sanções.

Alpha Spec Ops [Operações Especiais] está perto de Kiev desde 18 de fevereiro. O objetivo era tomar Kiev e instalar um regime fantoche. Eles estão efetuando provocações contra civis inocentes – mulheres e crianças – para semear o pânico. Este é o seu trunfo.

Todo o plano da Rússia se baseia no pânico – que os civis e as forças armadas se rendam e Zelensky fuja. Eles esperam que Kharkiv se renda primeiro para que as outras cidades sigam o exemplo para evitar derramamento de sangue. Os russos estão chocados com a resistência feroz que encontraram.

Os ucranianos devem evitar o pânico! Os ataques com mísseis são para intimidação, os russos os disparam aleatoriamente para atingir “acidentalmente” edifícios residenciais para fazer o ataque parecer maior do que realmente é. A Ucrânia deve permanecer forte e devemos fornecer assistência!”

Jupyter Notebook: você um dia vai usar

JJupyter Notebooks

Sobre os Problemas com o Facebook & Cia

Um usuário [ramenporn], dizendo ser da equipe de recuperação de desastre do Facebook, postou esta nota no Reddit, hoje mais cedo:

Imagem: iStock

Como muitos de vocês sabem, o DNS para serviços FB foi afetado e isso é provavelmente um sintoma do problema real, que é o peering de BGP com roteadores do Facebook caiu, muito provavelmente devido a uma mudança de configuração que entrou em vigor pouco antes de as interrupções acontecerem (começaram por volta das 15h40 UTC). Há pessoas agora tentando obter acesso aos roteadores de peering para implementar correções, mas as pessoas com acesso físico estão sem contato com as pessoas que têm conhecimento de como realmente autenticar nos sistemas e das pessoas que sabem o que realmente fazer. Então agora há um desafio logístico para unificar todo esse conhecimento. Parte disso também se deve ao menor número de funcionários nos centros de dados devido às medidas contra a pandemia.

Portanto, o problema básico parece ser “BGP peering“, que é o pareamento entre os DNS dos serviços do Facebook, em explicação simples (ver Aspectos Técnicos, abaixo, para uma explicação mais técnica), além da distribuição física das equipes por muitos locais separados.

O post foi em seguida apagado, assim como diversas contas desse usuário em outros sites e canais.

Eu imagino que ele não foi autorizado a postar essas informações. Espero que ele não perca o emprego.

Do que o FB tem medo? Penso que desde que essas pessoas não estejam compartilhando informações internas/proprietárias da empresa, esse assunto não é particularmente sensível. Além disso, ter alguma transparência sobre o problema é bom para todos.

Quem gostaria de trabalhar para uma empresa que pode tomar medidas disciplinares drásticas porque um engenheiro postou um comentário no Reddit basicamente para dizer “BGP’s down lol” – Se eu estivesse no comando, daria a ele um modesto bônus, por ajudar a alcançar de forma direta o usuário e a comunidade em geral.

Por outro lado…

Compartilhar o status de um evento em andamento pode complicar a recuperação. Tais relatórios públicos em tempo real podem atrapalhar o fluxo de informação entre as equipes.

Conclusão

Tenho certeza de que acionistas e outros líderes de negócios da empresa ficarão muito mais confortáveis em relatar isso como uma série de falhas técnicas infelizes (que alegarão fazer parte do negócio), em vez de uma falha organizacional de toda a empresa. O fato de não poderem identificar fisicamente as pessoas que conhecem a configuração do roteador mostra uma organização que ainda não pensou em todos os seus modos de falha. Muita gente não vai gostar disso. Não é incomum ter técnicos de datacenter com acesso ao sistema e o pessoal de software real sendo barrado. Contudo, sendo esse o motivo pelo qual um dos serviços mais populares do mundo está desativado por quase 5 horas agora, levantará muitos questionamentos..

Pessoalmente eu também espero que isso não prejudique as perspectivas de aumento no trabalho remoto. Se eles tiverem problemas em colocar na sala de comando alguém que conheça a configuração, porque todos moram a uma viagem de avião dos datacenters, eu posso ver no futuro próximo gerentes de muitos ramos de atividade relutando em ter uma equipe completamente remota.

Fica a lição para os empreendedores, que ficaram reféns de um serviço sobre o qual eles não têm controle. Eu nunca perco a oportunidade de salientar o quanto é importante controlar seus próprios dados e os dados de sua empresa. Faça um site dedicado ao seu negócio em seu próprio domínio. Fale com seus clientes e parceiros através de blogs como este. Consulte uma empresa de sistemas [como a Vox Leone] para ver onde seu negócio pode melhorar. O custo-benefício é altamente compensador. Nunca se esqueça que a tal “nuvem” é apenas o computador de outra pessoa. Use as redes sociais apenas para o que elas foram criadas: falar com papai, mamãe e titia.

Aspectos Técnicos: Sobre o BGP

Como reportou ramenporn, no centro deste apagão está a tecnologia Border Gateway Protocol (BGP), que é o serviço postal da Internet. Quando alguém coloca uma carta no correio, o serviço postal processa a correspondência e escolhe um caminho rápido e eficiente para entregar a carta ao destinatário. Da mesma forma, quando alguém envia dados pela Internet, o BGP é responsável por examinar todos os caminhos disponíveis que os dados podem percorrer e escolher a melhor rota, o que geralmente significa pular entre sistemas autônomos.

BGP é o protocolo que faz a Internet funcionar. Ele faz isso habilitando o roteamento de dados. Quando um usuário em Cingapura acessa um site hospedado na Argentina, o BGP é o protocolo que permite que a comunicação aconteça de forma rápida e eficiente.


Abaixo um traceroute do meio da tarde, mostrando os serviços Facebook em downtime

> traceroute a.ns.facebook.com
      traceroute to a.ns.facebook.com (129.134.30.12), 30 hops max, 60 byte packets
      1  service.local.net (192.168.1.254)  0.484 ms  0.474 ms  0.422 ms
      2  107-131-124-1.lightspeed.sntcca.sbcglobal.net (107.131.124.1)  1.592 ms  1.657 ms  1.607 ms 
      3  71.148.149.196 (71.148.149.196)  1.676 ms  1.697 ms  1.705 ms
      4  12.242.105.110 (12.242.105.110)  11.446 ms  11.482 ms  11.328 ms
      5  12.122.163.34 (12.122.163.34)  7.641 ms  7.668 ms  11.438 ms
      6  cr83.sj2ca.ip.att.net (12.122.158.9)  4.025 ms  3.368 ms  3.394 ms
      7  * * *
      ...