Racontons une histoire sympa sur la façon dont des « tiers » ont tenté d'interférer avec le travail de nos clients et comment ce problème a été résolu.
Comment tout a commencé
Tout a commencé le matin du 31 octobre, le dernier jour du mois, alors que beaucoup ont désespérément besoin de temps pour résoudre des problèmes urgents et importants.
L'un des partenaires, qui conserve plusieurs machines virtuelles des clients qu'il sert dans notre cloud, a signalé que de 9h10 à 9h20, plusieurs serveurs Windows exécutés sur notre site ukrainien n'acceptaient pas les connexions au service d'accès à distance. pour se connecter à leur bureau, mais après quelques minutes, le problème a semblé se résoudre de lui-même.
Nous avons relevé des statistiques sur le fonctionnement des canaux de communication, mais n'avons constaté aucune augmentation ou panne de trafic. Nous avons examiné les statistiques sur la charge des ressources informatiques - aucune anomalie. Et qu'est-ce que c'était ?
Ensuite, un autre partenaire, qui héberge une centaine de serveurs supplémentaires dans notre cloud, a signalé les mêmes problèmes que certains de ses clients ont signalés, et il s'est avéré qu'en général les serveurs étaient accessibles (répondant correctement au test ping et à d'autres demandes), mais le service d'accès à distance sur ces serveurs soit accepte de nouvelles connexions, soit les rejette, et nous parlions de serveurs sur différents sites, dont le trafic provient de différents canaux de transmission de données.
Regardons ce trafic. Un paquet avec une demande de connexion arrive sur le serveur :
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
Le serveur reçoit ce paquet, mais rejette la connexion :
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
Cela signifie que le problème n’est clairement pas causé par des problèmes de fonctionnement de l’infrastructure, mais par autre chose. Peut-être que tous les utilisateurs rencontrent des problèmes avec les licences de bureau à distance ? Peut-être qu'une sorte de malware a réussi à pénétrer dans leurs systèmes, et aujourd'hui il a été activé, comme il y a quelques années. XData и Petya?
Pendant que nous faisions le tri, nous avons reçu des demandes similaires de la part de plusieurs autres clients et partenaires.
Que se passe-t-il réellement sur ces machines ?
Les journaux d'événements regorgent de messages sur les tentatives de deviner le mot de passe :
En règle générale, de telles tentatives sont enregistrées sur tous les serveurs sur lesquels le port standard (3389) est utilisé pour le service d'accès à distance et l'accès est autorisé de partout. Internet regorge de robots qui analysent en permanence tous les points de connexion disponibles et tentent de deviner le mot de passe (c'est pourquoi nous recommandons fortement d'utiliser des mots de passe complexes au lieu de « 123 »). Toutefois, l’intensité de ces tentatives ce jour-là était trop élevée.
Que devrais-je faire?
Recommandez-vous aux clients de passer beaucoup de temps à modifier les paramètres pour qu'un grand nombre d'utilisateurs finaux passent à un autre port ? Ce n’est pas une bonne idée, les clients ne seront pas contents. Recommander d'autoriser l'accès uniquement via VPN ? Dans la précipitation et la panique, augmenter les connexions IPSec pour ceux qui ne les ont pas augmentées - peut-être qu'un tel bonheur ne sourit pas non plus aux clients. Bien que, je dois dire, c'est une chose divine dans tous les cas, nous recommandons toujours de cacher le serveur dans un réseau privé et sommes prêts à vous aider avec les paramètres, et pour ceux qui aiment le découvrir par eux-mêmes, nous partageons des instructions pour configurer IPSec/L2TP dans notre cloud en mode site à site ou route -warrior, et si quelqu'un souhaite configurer un service VPN sur son propre serveur Windows, il est toujours prêt à partager des conseils sur la façon de configurer un RAS standard ou OpenVPN. Mais, aussi cool que nous soyons, ce n'était pas le meilleur moment pour mener un travail éducatif auprès des clients, car nous devions résoudre le problème le plus rapidement possible avec un minimum de stress pour les utilisateurs.
La solution que nous avons mise en œuvre était la suivante. Nous avons mis en place une analyse du trafic passant de manière à surveiller toutes les tentatives d'établissement d'une connexion TCP sur le port 3389 et à sélectionner parmi celles-ci les adresses qui, dans un délai de 150 secondes, tentent d'établir des connexions avec plus de 16 serveurs différents de notre réseau. - ce sont les sources de l'attaque (Bien entendu, si l'un des clients ou partenaires a un réel besoin d'établir des connexions avec autant de serveurs à partir de la même source, vous pouvez toujours ajouter ces sources à la « liste blanche ». De plus, si dans un réseau de classe C pendant ces 150 secondes, plus de 32 adresses sont identifiées, il est logique de bloquer l'ensemble du réseau. Le blocage est fixé pour 3 jours, et si pendant ce temps aucune attaque n'a été menée depuis une source donnée, cette source est automatiquement supprimée de la « liste noire ». La liste des sources bloquées est mise à jour toutes les 300 secondes.
Cette liste est disponible à cette adresse : , vous pouvez créer vos ACL sur cette base.
Nous sommes prêts à partager le code source d'un tel système; il n'y a rien de trop complexe (ce sont plusieurs scripts simples compilés en quelques heures à genoux), et en même temps, il peut être adapté et utilisé non non seulement pour se protéger contre une telle attaque, mais aussi pour détecter et bloquer toute tentative de scan du réseau :
De plus, nous avons apporté quelques modifications aux paramètres du système de surveillance, qui surveille désormais de plus près la réaction d'un groupe de contrôle de serveurs virtuels dans notre cloud à une tentative d'établissement d'une connexion RDP : si la réaction ne suit pas dans un délai deuxièmement, c'est une raison d'y prêter attention.
La solution s'est avérée assez efficace : il n'y a plus de plaintes tant de la part des clients que des partenaires, ainsi que du système de surveillance. De nouvelles adresses et des réseaux entiers sont régulièrement ajoutés à la liste noire, ce qui indique que l'attaque continue, mais n'affecte plus le travail de nos clients.
Un sur le terrain n'est pas un guerrier
Aujourd'hui, nous avons appris que d'autres opérateurs ont rencontré un problème similaire. Quelqu'un croit encore que Microsoft a apporté quelques modifications au code du service d'accès à distance (si vous vous en souvenez, on s'en doutait le premier jour, mais nous avons très vite rejeté cette version) et promet de tout mettre en œuvre pour trouver une solution rapidement . Certains ignorent tout simplement le problème et conseillent aux clients de se protéger eux-mêmes (changer le port de connexion, cacher le serveur dans un réseau privé, etc.). Et dès le premier jour, nous avons non seulement résolu ce problème, mais nous avons également jeté les bases d'un système de détection des menaces plus global que nous prévoyons de développer.
Un merci spécial aux clients et partenaires qui ne sont pas restés silencieux et ne se sont pas assis sur la rive du fleuve en attendant qu'un jour le cadavre d'un ennemi flotte dessus, mais ont immédiatement attiré notre attention sur le problème, ce qui nous a donné l'occasion d'éliminer le même jour.
Source: habr.com