Wir erzählen Ihnen eine interessante Geschichte darüber, wie "Dritte" versucht haben, die Arbeit unserer Kunden zu stören, und wie dieses Problem gelöst wurde.
Wie alles begann
Und es begann am Morgen des 31. Oktober, dem letzten Tag des Monats, an dem viele dringend wichtige Angelegenheiten klären mussten.
Ein Partner, der mehrere virtuelle Maschinen von Kunden in unserer Cloud betreut, berichtete, dass von 9:10 bis 9:20 mehrere Windows-Server, die auf unserem ukrainischen Standort liefen, keine Verbindungen zum Remote-Access-Dienst akzeptierten; die Benutzer konnten sich nicht auf ihren Desktops anmelden, aber nach ein paar Minuten schien das Problem von selbst behoben zu sein.
Wir haben die Statistiken der Kommunikationskanäle überprüft, fanden jedoch weder Verkehrsspitzen noch Ausfälle. Wir haben die Belastungsstatistik der Rechenressourcen angesehen – keine Anomalien. Und was war das?
Ein weiterer Partner, der in unserer Cloud rund hundert Server betreibt, berichtete von ähnlichen Problemen, die einige ihrer Kunden festgestellt hatten. Es stellte sich heraus, dass die Server insgesamt verfügbar sind (antworten ordnungsgemäß auf Ping-Tests und andere Anfragen), aber der Fernzugriffsdienst auf diesen Servern akzeptiert manchmal neue Verbindungen und lehnt sie dann wieder ab. Dabei handelte es sich um Server an verschiedenen Standorten, deren Traffic aus unterschiedlichen Datenübertragungskanälen kommt.
Schauen wir uns diesen Traffic an. Ein Paket mit einer Anfrage zur Verbindungsherstellung erreicht den Server:
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
Der Server erhält dieses Paket, lehnt jedoch die Verbindung ab:
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
Das bedeutet, dass das Problem offensichtlich nicht auf irgendwelche Störungen in der Infrastruktur zurückzuführen ist, sondern auf etwas anderes. Vielleicht hatten alle Benutzer Lizenzprobleme mit den Remote-Desktops? Vielleicht hat sich in ihre Systeme schadhafte Software eingeschlichen, die heute aktiviert wurde, wie vor ein paar Jahren mit XData und Petya?
Während wir uns damit beschäftigten, erhielten wir ähnliche Anfragen von mehreren anderen Kunden und Partnern.
Was passiert überhaupt auf diesen Maschinen?
In den Ereignisprotokollen gibt es zahlreiche Meldungen über Passwortversuche:
Solche Versuche werden normalerweise auf allen Servern protokolliert, bei denen der Remote-Access-Dienst den Standardport (3389) verwendet und der Zugriff von überall erlaubt ist. Im Internet tummeln sich unzählige Bots, die ständig alle verfügbaren Verbindungspunkte scannen und versuchen, Passwörter zu erraten (aus genau diesem Grund empfehlen wir dringend, komplexe Passwörter anstelle von "123" zu verwenden). Dennoch war die Intensität dieser Versuche an diesem Tag viel zu hoch.
Was tun?
Empfehlen Sie den Kunden nicht, viel Zeit damit zu verbringen, die Einstellungen einer großen Anzahl von Endnutzern zu ändern, um auf einen anderen Port zu wechseln? Das ist keine gute Idee, die Kunden werden damit nicht glücklich sein. Empfehlen Sie, den Zugang nur über ein VPN zu ermöglichen? In der Eile und Panik IPSec-Verbindungen aufbauen, wo sie nicht bestehen – das ist wohl auch kein Glücksfall für die Kunden. Dennoch muss gesagt werden, dass es in jedem Fall ein lobenswerter Ansatz ist, und wir empfehlen immer, den Server in ein privates Netzwerk zu verstecken und helfen gerne bei den Einstellungen. Für diejenigen, die selbst die Dinge in die Hand nehmen möchten, teilen wir Anleitungen zur Einrichtung von IPSec/L2TP in unserer Cloud im Site-to-Site- oder Road-Warrior-Modus. Und wenn jemand einen VPN-Dienst auf einem eigenen Windows-Server einrichten möchte, sind wir immer bereit, hilfreiche Tipps zur Einrichtung eines standardmäßigen RAS oder OpenVPN zu geben. Aber so nett wir auch sind, war dies nicht der beste Zeitpunkt, um Aufklärungsarbeit bei den Kunden zu leisten, da das Problem so schnell wie möglich mit minimalem Aufwand für die Nutzer behoben werden musste.
Die Lösung, die wir implementiert haben, bestand darin, den eingehenden Datenverkehr so zu analysieren, dass alle Versuche zur Herstellung einer TCP-Verbindung zu Port 3389 verfolgt werden. Wir ermitteln die Adressen, die innerhalb von 150 Sekunden versuchen, sich mit mehr als 16 verschiedenen Servern in unserem Netzwerk zu verbinden – das sind die Angriffsquellen. Falls ein Kunde oder Partner jedoch tatsächlich die Notwendigkeit hat, Verbindungen zu so vielen Servern aus derselben Quelle herzustellen, kann man solche Quellen jederzeit zur 'Whitelist' hinzufügen. Wenn in einem C-Class-Netzwerk in diesen 150 Sekunden mehr als 32 Adressen identifiziert wurden, macht es Sinn, das gesamte Netzwerk zu blockieren. Die Blockierung wird für 3 Tage eingerichtet, und wenn in dieser Zeit keine Angriffe von dieser Quelle erfolgen, wird diese Quelle automatisch aus der 'Blacklist' entfernt. Die Liste der blockierten Quellen wird alle 300 Sekunden aktualisiert.
Diese Liste ist unter folgender Adresse verfügbar: , Sie können darauf basierend Ihre eigenen ACLs erstellen.
Den Quellcode eines solchen Systems sind wir bereit, zu teilen. Es gibt nichts Übermäßig Schwieriges darin (es sind ein paar einfache Skripte, die buchstäblich in ein paar Stunden 'auf die Schnelle' zusammengestellt wurden), und trotzdem kann er angepasst und nicht nur zum Schutz gegen eine solche Attacke verwendet werden, sondern auch zur Erkennung und Blockierung jeglicher Versuche, das Netzwerk zu scannen.
Außerdem haben wir einige Änderungen an den Einstellungen des Überwachungssystems vorgenommen, das jetzt genauer die Reaktion der Kontrollgruppe virtueller Server in unserer Cloud auf den Versuch der RDP-Verbindung überwacht: Wenn innerhalb von einer Sekunde keine Reaktion erfolgt, ist das ein Grund zur Aufmerksamkeit.
Die Lösung hat sich als ausreichend effektiv erwiesen: Es gibt keine Beschwerden mehr sowohl von Seiten unserer Kunden und Partner als auch vonseiten des Überwachungssystems. Neue Adressen und ganze Netzwerke werden regelmäßig auf die ‚schwarze Liste‘ gesetzt, was darauf hinweist, dass der Angriff weiterhin besteht, aber bereits keine Auswirkungen mehr auf den Betrieb unserer Kunden hat.
Einer allein ist kein Krieger.
Heute erfuhren wir, dass auch andere Anbieter mit ähnlichen Problemen konfrontiert sind. Einige vermuten, dass Microsoft Änderungen am Code des Remote-Access-Dienstes vorgenommen hat (wenn Sie sich erinnern, hatten wir am ersten Tag denselben Verdacht, aber diese Theorie haben wir schnell verworfen) und versprechen, alles zu tun, um so schnell wie möglich eine Lösung zu finden. Andere ignorieren das Problem einfach und raten den Kunden, sich selbst zu schützen (den Anschlussport zu ändern, den Server in ein privates Netzwerk zu verstecken usw.). Wir hingegen haben am ersten Tag nicht nur dieses Problem gelöst, sondern auch die Basis für ein umfassenderes Bedrohungserkennungssystem geschaffen, das wir weiterentwickeln möchten.
Ein besonderes Dankeschön gilt unseren Kunden und Partnern, die nicht geschwiegen haben und nicht am Ufer gesessen sind, in der Erwartung, dass irgendwann die Leiche des Feindes vorbeischwimmt, sondern uns sofort auf das Problem aufmerksam gemacht haben, was uns die Möglichkeit gab, es am selben Tag zu beheben.
Quelle: habr.com
