Contaremos 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, no último dia do mês, quando muitos precisam desesperadamente resolver questões urgentes e importantes.
Um dos parceiros que mantém em nossa nuvem várias máquinas virtuais dos clientes que atende, relatou que, das 9h10 às 21h20, vários servidores Windows em execução no site ucraniano não aceitaram conexões com o serviço de acesso remoto , os usuários não conseguiam acessar seus desktops, mas após alguns minutos o problema parecia se resolver.
Aumentamos as estatísticas dos canais de comunicação, mas não encontramos nenhuma explosão de tráfego ou falhas. Olhou para as estatísticas sobre a carga em recursos de computação - sem anomalias. E o que foi aquilo?
Em seguida, outro parceiro, que hospeda outras centenas de servidores em nossa nuvem, relatou os mesmos problemas que alguns de seus clientes observaram e, em geral, os servidores estão disponíveis (eles respondem corretamente ao teste de ping e a outras solicitações), mas o serviço O acesso remoto a esses servidores aceita novas conexões e as rejeita, enquanto se tratava de servidores em sites diferentes, cujo tráfego é proveniente de diferentes canais de transmissão de dados.
E vamos olhar para esse tráfego. Um pacote com uma 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 este pacote, mas a conexão rejeita:
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 é claramente causado não de maneira alguma por alguns problemas na infraestrutura, mas por outra coisa. Talvez todos os usuários tenham problemas com o licenciamento de áreas de trabalho remotas? Talvez algum malware tenha conseguido se infiltrar em seus sistemas, mas hoje ele foi ativado, como aconteceu com o
XData e o
Petya há alguns anos?
Enquanto eles estavam resolvendo o problema, eles receberam solicitações semelhantes de vários outros clientes e parceiros.
E o que acontece nessas máquinas?
Os logs de eventos estão cheios de mensagens sobre como tentar encontrar uma senha:
Normalmente, essas tentativas são registradas em todos os servidores em que a porta padrão (3389) é usada para o serviço de acesso remoto e o acesso é permitido de qualquer lugar. A Internet está cheia de bots que examinam constantemente todos os pontos de conexão disponíveis e tentam encontrar uma senha (por esse motivo, recomendamos enfaticamente o uso de senhas complexas em vez de "123"). No entanto, a intensidade dessas tentativas naquele dia foi muito alta.
O que fazer?
Recomende que os clientes dediquem muito tempo para alterar 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 serão felizes. Recomende permitir acesso apenas através da VPN? Com pressa e pânico, para aumentar as conexões IPSec, das quais elas não são criadas - talvez essa felicidade também não sorria para os clientes. Embora, devo dizer, isso seja de qualquer forma uma questão de caridade, sempre recomendamos ocultar o servidor em uma rede privada e estamos prontos para ajudar com as configurações; para aqueles que gostam de resolver, compartilharemos independentemente instruções para configurar o IPSec / L2TP em nossa nuvem no modo site a site ou rodoviário -warrior, e se alguém quiser aumentar um serviço VPN em seu próprio servidor Windows, estará sempre pronto para compartilhar dicas sobre como aumentar um RAS ou OpenVPN padrão. Porém, por mais legais que fôssemos, não era o melhor momento para realizar um trabalho educacional entre os clientes, pois era necessário eliminar o problema com o mínimo de esforço dos usuários o mais rápido possível.
A solução que implementamos foi a seguinte. Configuramos uma análise do tráfego de passagem de maneira a monitorar todas as tentativas de estabelecer uma conexão TCP com a porta 3389 e selecionar endereços dela que, em 150 segundos, tentam estabelecer conexões com mais de 16 servidores diferentes em nossa rede - essas são as fontes do ataque ( Obviamente, se um dos clientes ou parceiros tiver uma necessidade real de estabelecer conexões com tantos servidores da mesma fonte, você sempre poderá adicionar essas fontes à "lista branca". Além disso, se em uma rede de classe C para essas 150 segundos, mais de 32 endereços foram detectados, faz sentido bloquear toda a rede. O bloqueio é definido por 3 dias e, se nenhum ataque foi feito a partir dessa fonte durante esse período, essa fonte será removida automaticamente da lista negra. A lista de fontes bloqueadas é atualizada a cada 300 segundos.
Esta lista está disponível aqui neste endereço:
https://secure.tucha.ua/global-filter/banned/rdp_ddos , você pode criar suas próprias ACLs com base nela.
Estamos prontos para compartilhar o código-fonte de tal sistema, não há nada super complicado (esses são alguns scripts simples escritos literalmente em algumas horas "no joelho") e, ao mesmo tempo, ele pode ser adaptado e usado não apenas para proteger contra um ataque, mas também para identificar e bloquear qualquer tentativa de verificação de rede:
siga este link.Além disso, fizemos algumas alterações nas configurações do sistema de monitoramento, que agora monitora de perto a reação do grupo de controle de servidores virtuais em nossa nuvem a uma tentativa de estabelecer uma conexão RDP: se a reação não se seguiu por um segundo, é uma ocasião para prestar atenção.
A solução acabou sendo bastante eficaz: não há mais reclamações de clientes e parceiros, nem do sistema de monitoramento. A "lista negra" inclui regularmente novos endereços e redes inteiras, o que indica que o ataque continua, mas não afeta mais o trabalho de nossos clientes.
Sozinho no campo não é um guerreiro
Hoje descobrimos que outros operadores enfrentaram 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, suspeitamos a mesma coisa no primeiro dia, mas rejeitamos esta versão muito em breve) e promete fazer todo o possível para encontre uma solução em breve. Alguém simplesmente ignora o problema e aconselha os clientes a se protegerem (alterar a porta de conexão, ocultar o servidor em uma rede privada e assim por diante). E no primeiro dia, não apenas resolvemos esse problema, mas também criamos algumas bases para um sistema de detecção de ameaças mais global, que planejamos desenvolver.
Agradecimentos especiais a clientes e parceiros que não ficaram em silêncio e não sentaram na margem do rio, antecipando que um dia o cadáver do inimigo flutuaria sobre ele e imediatamente voltamos nossa atenção para o problema, que nos deu a oportunidade de eliminá-lo no mesmo dia.