Vamos contar uma história interessante 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ã de 31 de outubro, o último dia do mês, quando muitas pessoas precisavam urgentemente resolver questões importantes.
Um dos parceiros, que hospeda várias máquinas virtuais de clientes em nossa nuvem, informou que entre 9:10 e 9:20, vários servidores Windows em nossa plataforma ucraniana não estavam aceitando conexões do serviço de acesso remoto, e os usuários não conseguiam acessar suas áreas de trabalho, mas, após alguns minutos, o problema pareceu se resolver por si só.
Analisamos as estatísticas dos canais de comunicação, mas não encontramos picos de tráfego ou falhas. Verificamos as estatísticas de carga nos recursos computacionais – sem anomalias. E o que estava acontecendo?
Depois, outro parceiro, que hospeda cerca de uma centena de servidores em nossa nuvem, relatou problemas semelhantes que alguns de seus clientes estavam enfrentando. Constatou-se que, no geral, os servidores estavam acessíveis (respondendo corretamente ao ping test e a outras solicitações), mas o serviço de acesso remoto nesses servidores estava aceitando novos cones e, em seguida, os rejeitando. Vale ressaltar que isso ocorreu em servidores em diferentes plataformas, recebendo tráfego de diferentes canais de transmissão de dados.
Vamos dar uma olhada nesse tráfego. Um pacote de solicitação para estabelecer uma 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 esse 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
Isso significa que o problema não está relacionado a falhas na infraestrutura, mas a algo mais. Será que todos os usuários enfrentaram problemas com a licença dos desktops remotos? Talvez algum malware tenha conseguido se infiltrar em seus sistemas, e hoje ele ativou, como aconteceu há alguns anos com XData e Petya?
Enquanto investigávamos, recebemos relatos semelhantes de mais alguns clientes e parceiros.
E o que está acontecendo nesses máquinas?
Os registros de eventos estão cheios de mensagens sobre tentativas de adivinhação de senhas:
Normalmente, essas tentativas são registradas em todos os servidores onde o serviço de acesso remoto utiliza a porta padrão (3389) e o acesso é permitido de qualquer lugar. Na internet, há uma infinidade de bots que estão constantemente escaneando todos os pontos de conexão disponíveis e tentando adivinhar senhas (é por essa razão que recomendamos fortemente o uso de senhas complexas em vez de '123'). No entanto, a intensidade dessas tentativas naquele dia foi extremamente alta.
O que fazer?
Recomendar aos clientes gastar um tempo considerável alterando as configurações de um grande número de usuários finais para mudar para outra porta? Não é uma boa ideia, os clientes não ficarão satisfeitos. Recomendar permitir o acesso apenas via VPN? Com a pressa e o pânico de configurar conexões IPSec para aqueles que ainda não as têm - provavelmente, essa não é uma boa notícia para os clientes também. Embora, é justo dizer que, de qualquer forma, é um dever louvável, sempre recomendamos esconder o servidor em uma rede privada e estamos prontos para ajudar nas configurações, e para os que gostam de resolver por conta própria, compartilhamos instruções para configurar IPSec/L2TP na nossa nuvem no modo site-to-site ou road-warrior, e se alguém desejar criar um serviço de VPN em seu próprio servidor Windows - sempre estamos prontos para compartilhar dicas sobre como configurar RAS ou OpenVPN. Mas, por mais legais que sejamos, não era o melhor momento para fazer trabalhos de conscientização entre os clientes, já que era necessário 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 consistia no seguinte. Estabelecemos uma análise do tráfego recebido de forma a monitorar todas as tentativas de estabelecer uma conexão TCP à porta 3389, selecionando aqueles endereços que, durante 150 segundos, tentam se conectar a mais de 16 servidores diferentes em nossa rede, que são as fontes do ataque (naturalmente, se algum dos nossos clientes ou parceiros tiver uma necessidade real de se conectar a esse número de servidores a partir da mesma fonte, é possível sempre adicionar essas fontes à lista de permissões. Ao mesmo tempo, se mais de 32 endereços forem identificados em uma mesma rede de classe C nesses 150 segundos, é razoável bloquear toda a rede. O bloqueio é estabelecido por 3 dias, e se durante esse período não houver novos ataques dessa fonte, ela é removida automaticamente da lista negra. A lista de fontes bloqueadas é atualizada a cada 300 segundos.
Essa lista está disponível neste endereço: , você pode construir suas ACL com base nela.
Estamos prontos para compartilhar o código-fonte desse sistema, não há nada excessivamente complexo nele (são alguns scripts simples, elaborados literalmente em algumas horas 'na correria'), e pode ser adaptado e utilizado não só para proteção contra esse tipo de ataque, mas também para identificar e bloquear quaisquer tentativas de escaneamento da rede:
Além disso, fizemos algumas alterações nas configurações do sistema de monitoramento, que agora observa mais atentamente a reação do grupo de controle de servidores virtuais na nossa nuvem às tentativas de estabelecer uma conexão RDP: se a reação não ocorrer em um segundo, isso é um sinal de alerta.
A solução se mostrou bastante eficaz: não recebemos mais reclamações tanto de clientes e parceiros quanto do sistema de monitoramento. Novos endereços e redes inteiras estão sendo regularmente adicionados à lista negra, o que indica que o ataque continua, mas já não afeta o funcionamento dos nossos clientes.
Um homem só não é guerreiro.
Hoje, descobrimos que outros provedores também enfrentaram um problema semelhante. Alguns ainda acreditam que a Microsoft fez mudanças no código do serviço de acesso remoto (se lembram, nós suspeitamos disso no primeiro dia, mas rapidamente descartamos essa versão) e prometem fazer o possível para encontrar uma solução rapidamente. Outros simplesmente ignoram o problema e aconselham os clientes a se protegerem por conta própria (mudando a porta de conexão, ocultando o servidor em uma rede privada, e assim por diante). E, no primeiro dia, não apenas resolvemos esse problema, mas também criamos uma base 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 em silêncio e não esperaram à margem do rio, esperando que um corpo do inimigo aparecesse, mas imediatamente chamaram nossa atenção para o problema, o que nos deu a oportunidade de resolvê-lo no mesmo dia.
Fonte: habr.com
