Nous allons vous raconter une histoire intéressante 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é dans la matinée du 31 octobre, le dernier jour du mois, alors que beaucoup ont désespérément besoin de parvenir à régler des problèmes urgents et importants.
L'un des partenaires qui conserve dans notre cloud plusieurs machines virtuelles des clients qu'il sert, a indiqué que de 9h10 à 9h20 à la fois, plusieurs serveurs Windows exécutés sur notre site ukrainien n'ont pas accepté les connexions avec le service d'accès à distance , les utilisateurs ne pouvaient pas accéder à leurs bureaux, mais après quelques minutes, le problème semblait se résoudre lui-même.
Nous avons relevé les statistiques des canaux de communication, mais n'avons trouvé ni rafales de trafic ni pannes. Regardé les statistiques sur la charge des ressources informatiques - aucune anomalie. Et c'était quoi?
Ensuite, un autre partenaire, qui héberge une centaine de serveurs dans notre cloud, a signalé les mêmes problèmes que certains de leurs clients ont notés, et il s'est avéré qu'en général les serveurs sont disponibles (ils répondent correctement au test ping et à d'autres demandes), mais le service L'accès à distance sur ces serveurs accepte soit de nouvelles connexions, puis les rejette, alors qu'il s'agissait de serveurs sur différents sites, dont le trafic provient de différents canaux de transmission de données.
Et regardons ce trafic. Un paquet avec une demande d'établissement d'une 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 la connexion rejette:
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 est clairement causé non pas du tout par des dysfonctionnements de l'infrastructure, mais par autre chose. Peut-être que tous les utilisateurs ont des problèmes avec les licences des postes de travail distants? Peut-être que certains logiciels malveillants ont réussi à s'infiltrer dans leurs systèmes, mais aujourd'hui, il s'est activé, comme c'était le cas avec
XData et
Petya il y a quelques années?
Pendant le tri, ils ont reçu des demandes similaires de plusieurs autres clients et partenaires.
Et que se passe-t-il sur ces machines?
Les journaux d'événements regorgent de messages sur la recherche d'un mot de passe:
En règle générale, ces 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 n'importe où. Internet regorge de bots qui analysent constamment tous les points de connexion disponibles et essaient de trouver un mot de passe (pour cette raison, nous vous recommandons fortement d'utiliser des mots de passe complexes au lieu de «123»). Cependant, l'intensité de ces tentatives ce jour-là était trop élevée.
Que faire?
Recommander aux clients de consacrer beaucoup de temps à modifier les paramètres d'un grand nombre d'utilisateurs finaux pour passer à 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 hâte et la panique, pour augmenter les connexions IPSec, dont ils ne sont pas issus - peut-être, un tel bonheur ne sourit pas non plus aux clients. Bien que, je dois dire que c'est en tout cas une affaire caritative, nous recommandons toujours de cacher le serveur sur un réseau privé et sommes prêts à aider avec les paramètres, et pour ceux qui aiment trier, nous partagerons indépendamment les instructions pour configurer IPSec / L2TP dans notre cloud en mode site à site ou en mode route -warrior, et si quelqu'un veut augmenter un service VPN sur son propre serveur Windows, il est toujours prêt à partager des conseils sur la façon de monter un RAS standard ou OpenVPN. Mais peu importe à quel point nous étions cool, ce n'était pas le meilleur moment pour effectuer un travail éducatif auprès des clients, car il était nécessaire de résoudre le problème avec un minimum de pression pour les utilisateurs le plus rapidement possible.
La solution que nous avons implémentée était la suivante. Nous avons configuré une analyse du trafic passant de manière à surveiller toutes les tentatives d'établissement d'une connexion TCP au port 3389 et à sélectionner parmi celles-ci des adresses qui, dans les 150 secondes, tentent d'établir des connexions avec plus de 16 serveurs différents sur notre réseau - ce sont les sources de l'attaque ( Bien sûr, si l'un des clients ou partenaires a vraiment besoin d'établir des connexions avec autant de serveurs de la même source, vous pouvez toujours ajouter ces sources à la «liste blanche». De plus, si dans un réseau de classe C pour ces 150 secondes, plus de 32 adresses ont été détectées, il est logique de bloquer l'ensemble du réseau. Le blocage est défini sur 3 jours, et si aucune attaque de cette source n'a été effectuée pendant cette période, 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 ici à cette adresse:
https://secure.tucha.ua/global-filter/banned/rdp_ddos , vous pouvez construire vos propres ACL sur la base de celle-ci.
Nous sommes prêts à partager le code source d'un tel système, il n'y a rien de super compliqué (ce sont quelques scripts simples écrits littéralement en quelques heures "à genoux"), et en même temps il peut être adapté et utilisé non seulement pour se protéger contre une telle attaque, mais aussi pour identifier et bloquer toute tentative de scan du réseau:
suivez ce lien.De plus, nous avons apporté quelques modifications aux paramètres du système de surveillance, qui surveille désormais de près la réaction du groupe de contrôle des serveurs virtuels de notre cloud à une tentative d'établissement d'une connexion RDP: si la réaction n'a pas suivi pendant une seconde, c'est l'occasion de faire attention.
La solution s'est avérée assez efficace: il n'y a plus de plaintes des clients et partenaires, ainsi que du système de suivi. La «liste noire» comprend régulièrement de nouvelles adresses et des réseaux entiers, ce qui indique que l'attaque se poursuit, mais n'affecte plus le travail de nos clients.
Seul sur le terrain n'est pas un guerrier
Aujourd'hui, nous avons appris que d'autres opérateurs étaient confrontés à un problème similaire. Quelqu'un croit toujours que Microsoft a apporté des modifications au code du service d'accès à distance (si vous vous souvenez, nous avons soupçonné la même chose le premier jour, mais nous avons rejeté cette version très bientôt) et promet de faire tout son possible pour trouver une solution bientôt. Quelqu'un ignore simplement le problème et conseille aux clients de se protéger (changer le port de connexion, masquer le serveur sur un réseau privé, etc.). Et dès le premier jour, nous avons non seulement résolu ce problème, mais également créé des bases pour 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 prévision qu'un jour le cadavre de l'ennemi flotterait dessus et a immédiatement attiré notre attention sur le problème, ce qui nous a permis de l'éliminer le même jour.