Vamos contar uma história bacana sobre como “terceiros” tentaram interferir no trabalho de nossos clientes e como esse problema foi resolvido.
Como tudo começou
Tudo começou na manhã do dia 31 de outubro, último dia do mês, quando muitos precisam desesperadamente de tempo para resolver questões urgentes e importantes.
Um dos parceiros, que mantém em nossa nuvem diversas máquinas virtuais dos clientes que atende, relatou que das 9h10 às 9h20 vários servidores Windows rodando em nosso site ucraniano não aceitaram conexões com o serviço de acesso remoto, os usuários não conseguiram para fazer login em seus desktops, mas depois de alguns minutos o problema pareceu se resolver sozinho.
Levantamos as estatísticas de funcionamento dos canais de comunicação, mas não encontramos picos ou falhas de tráfego. Analisamos as estatísticas sobre a carga dos recursos de computação - sem anomalias. E o que foi isso?
Então outro parceiro, que hospeda cerca de mais cem servidores em nossa nuvem, relatou os mesmos problemas que alguns de seus clientes observaram, e descobriu-se que em geral os servidores estavam acessíveis (respondendo adequadamente ao teste de ping e outras solicitações), mas o serviço acesso remoto nesses servidores aceita novas conexões ou as rejeita, e estávamos falando de servidores em sites diferentes, cujo tráfego vem de diferentes canais de transmissão de dados.
Vejamos esse tráfego. Um pacote com uma solicitação de conexão chega ao servidor:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
O servidor recebe este pacote, mas rejeita a conexão:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Isto significa que o problema não é claramente causado por quaisquer problemas no funcionamento da infra-estrutura, mas por outra coisa. Talvez todos os usuários estejam tendo problemas com o licenciamento de desktop remoto? Talvez algum tipo de malware tenha conseguido penetrar em seus sistemas e hoje foi ativado, como foi há alguns anos XDataName и Petya?
Enquanto resolvíamos o problema, recebemos solicitações semelhantes de vários outros clientes e parceiros.
O que realmente acontece nessas máquinas?
Os logs de eventos estão cheios de mensagens sobre tentativas de adivinhar a senha:
Normalmente, tais tentativas são registradas em todos os servidores onde a porta padrão (3389) é utilizada para o serviço de acesso remoto e o acesso é permitido de qualquer lugar. A Internet está cheia de bots que verificam constantemente todos os pontos de conexão disponíveis e tentam adivinhar a senha (é por isso que recomendamos fortemente o uso de senhas complexas em vez de “123”). Contudo, a intensidade dessas tentativas naquele dia foi muito alta.
O que devo fazer?
Recomenda que os clientes gastem muito tempo alterando as configurações para que um grande número de usuários finais mudem para uma porta diferente? Não é uma boa ideia, os clientes não ficarão satisfeitos. Recomenda permitir acesso apenas via VPN? Com pressa e pânico, aumentando as conexões IPSec para quem não as tem - talvez essa felicidade também não sorria para os clientes. Embora, devo dizer, isso seja uma coisa divina em qualquer caso, sempre recomendamos esconder o servidor em uma rede privada e estamos prontos para ajudar com as configurações, e para quem gosta de descobrir por conta própria, compartilhamos instruções para configurar IPSec/L2TP em nossa nuvem em modo site-to-site ou road -warrior, e se alguém quiser configurar um serviço VPN em seu próprio servidor Windows, está sempre pronto para compartilhar dicas sobre como configurar um RAS padrão ou OpenVPN. Mas, por mais bacanas que fôssemos, este não era o melhor momento para realizar um trabalho educativo com os clientes, pois precisávamos resolver o problema o mais rápido possível e com o mínimo de estresse para os usuários.
A solução que implementamos foi a seguinte. Montamos uma análise do tráfego que passa de forma a monitorar todas as tentativas de estabelecer uma conexão TCP à porta 3389 e selecionar dela endereços que, em 150 segundos, tentam estabelecer conexões com mais de 16 servidores diferentes em nossa rede - estas são as fontes do ataque (Claro que, se um dos clientes ou parceiros tiver uma necessidade real de estabelecer ligações com tantos servidores da mesma fonte, pode sempre adicionar essas fontes à “lista branca”. Além disso, se em uma rede classe C durante esses 150 segundos forem identificados mais de 32 endereços, faz sentido bloquear toda a rede. O bloqueio é definido por 3 dias, e se durante esse tempo nenhum ataque foi realizado de uma determinada fonte, esta fonte é automaticamente removida da “lista negra”. A lista de fontes bloqueadas é atualizada a cada 300 segundos.
Esta lista está disponível neste endereço: , você poderá criar suas ACLs com base nela.
Estamos prontos para compartilhar o código-fonte de tal sistema; não há nada muito complexo nele (são vários scripts simples compilados literalmente em algumas horas no joelho) e, ao mesmo tempo, pode ser adaptado e usado não apenas para proteger contra tal ataque, mas também para detectar e bloquear qualquer tentativa de varredura da rede:
Além disso, fizemos algumas alterações nas configurações do sistema de monitoramento, que agora monitora mais de perto a reação de um grupo de controle de servidores virtuais em nossa nuvem a uma tentativa de estabelecer uma conexão RDP: se a reação não ocorrer dentro de um segundo, este é um motivo para prestar atenção.
A solução revelou-se bastante eficaz: já não existem reclamações tanto de clientes como de parceiros, bem como do sistema de monitorização. Novos endereços e redes inteiras são regularmente adicionados à lista negra, o que indica que o ataque continua, mas não afeta mais o trabalho dos nossos clientes.
Um no campo não é um guerreiro
Hoje soubemos que outras operadoras encontraram um problema semelhante. Alguém ainda acredita que a Microsoft fez algumas alterações no código do serviço de acesso remoto (se você se lembra, suspeitávamos da mesma coisa no primeiro dia, mas rapidamente rejeitamos esta versão) e promete fazer todo o possível para encontrar uma solução rapidamente . Algumas pessoas simplesmente ignoram o problema e aconselham os clientes a se protegerem por conta própria (alterar a porta de conexão, ocultar o servidor em uma rede privada e assim por diante). E logo no primeiro dia, não apenas resolvemos este problema, mas também criamos algumas bases para um sistema de detecção de ameaças mais global, que pretendemos desenvolver.
Um agradecimento especial aos clientes e parceiros que não ficaram calados e não ficaram sentados na margem do rio esperando que um dia o cadáver de um inimigo flutuasse por ele, mas imediatamente chamaram nossa atenção para o problema, o que nos deu a oportunidade de eliminar isso no mesmo dia.
Fonte: habr.com