Wir erzählen Ihnen eine coole Geschichte darüber, wie „Dritte“ versucht haben, die Arbeit unserer Kunden zu stören, und wie dieses Problem gelöst wurde.
Wie alles begann
Alles begann am Morgen des 31. Oktober, am letzten Tag des Monats, an dem viele dringend dringende und wichtige Probleme lösen müssen.
Einer der Partner, der mehrere virtuelle Maschinen der von ihm bedienten Clients in unserer Cloud verwaltet, berichtete, dass von 9:10 bis 9:20 auf einmal mehrere Windows-Server, die auf unserer ukrainischen Site ausgeführt werden, keine Verbindungen mit dem RAS-Dienst akzeptiert haben Benutzer konnten nicht auf ihre Desktops zugreifen, aber nach einigen Minuten schien sich das Problem von selbst zu lösen.
Wir haben die Statistiken der Kommunikationskanäle erhöht, aber keine Verkehrsstöße oder Ausfälle festgestellt. Betrachtet die Statistiken über die Belastung der Rechenressourcen - keine Anomalien. Und was war das?
Dann berichtete ein anderer Partner, der weitere hundert Server in unserer Cloud hostet, über dieselben Probleme, die einige ihrer Clients festgestellt hatten, und es stellte sich heraus, dass die Server im Allgemeinen verfügbar sind (sie antworteten korrekt auf den Ping-Test und andere Anforderungen), jedoch auf den Dienst Der Remotezugriff auf diesen Servern akzeptiert entweder neue Verbindungen und lehnt sie dann ab, während es sich um Server an verschiedenen Standorten handelte, deren Datenverkehr von verschiedenen Datenübertragungskanälen stammt.
Und schauen wir uns diesen Verkehr an. Ein Paket mit einer Anforderung zum Herstellen einer Verbindung kommt auf dem Server an:
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 empfängt dieses Paket, die Verbindung lehnt jedoch 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
Dies bedeutet, dass das Problem eindeutig nicht durch einige Fehlfunktionen in der Infrastruktur, sondern durch etwas anderes verursacht wird. Möglicherweise haben alle Benutzer Probleme mit der Lizenzierung von Remote-Desktops? Vielleicht hat es eine Malware geschafft, ihre Systeme zu infiltrieren, aber heute wurde sie aktiviert, wie es vor
ein paar Jahren bei
XData und
Petya war ?
Während sie es aussortierten, erhielten sie ähnliche Anfragen von mehreren weiteren Kunden und Partnern.
Und was passiert auf diesen Maschinen?
Die Ereignisprotokolle enthalten viele Meldungen zum Versuch, ein Kennwort zu finden:
In der Regel werden solche Versuche auf allen Servern protokolliert, auf denen der Standardport (3389) für den RAS-Dienst verwendet wird und der Zugriff von überall aus zulässig ist. Das Internet ist voll von Bots, die ständig alle verfügbaren Verbindungspunkte scannen und versuchen, ein Passwort zu finden (aus diesem Grund empfehlen wir dringend, komplexe Passwörter anstelle von „123“ zu verwenden). Die Intensität dieser Versuche an diesem Tag war jedoch zu hoch.
Was zu tun
Empfehlen Sie Kunden, viel Zeit zu investieren, um die Einstellungen einer großen Anzahl von Endbenutzern zu ändern und auf einen anderen Port zu wechseln? Keine gute Idee, Kunden werden nicht glücklich sein. Empfehlen, den Zugriff nur über VPN zuzulassen? In Eile und Panik, um IPSec-Verbindungen herzustellen, von denen sie nicht stammen - vielleicht lächelt ein solches Glück den Kunden auch nicht zu. Obwohl dies auf jeden Fall eine wohltätige Angelegenheit ist, empfehlen wir immer, den Server in einem privaten Netzwerk zu verstecken und sind bereit, bei den Einstellungen zu helfen. Für diejenigen, die das Problem lösen möchten, geben wir unabhängig Anweisungen zum Einrichten von IPSec / L2TP in unserer Cloud im Site-to-Site- oder Road-Modus weiter -warrior, und wenn jemand einen VPN-Dienst auf seinem eigenen Windows-Server einrichten möchte, ist er immer bereit, Tipps zum Erhöhen eines Standard-RAS oder OpenVPN auszutauschen. Egal wie cool wir waren, dies war nicht der beste Zeitpunkt, um Schulungsarbeiten bei Kunden durchzuführen, da das Problem so schnell wie möglich mit minimaler Belastung für die Benutzer behoben werden musste.
Die von uns implementierte Lösung war wie folgt. Wir haben eine Analyse des vorbeifahrenden Datenverkehrs eingerichtet, um alle Versuche zu überwachen, eine TCP-Verbindung zu Port 3389 herzustellen, und Adressen auszuwählen, die innerhalb von 150 Sekunden versuchen, Verbindungen mit mehr als 16 verschiedenen Servern in unserem Netzwerk herzustellen. Dies sind die Quellen des Angriffs ( Wenn einer der Clients oder Partner wirklich Verbindungen zu so vielen Servern aus derselben Quelle herstellen muss, können Sie solche Quellen natürlich jederzeit zur „weißen Liste“ hinzufügen. Wenn Sie sich in einem Klasse-C-Netzwerk für diese 150 befinden Sekunden, mehr als 32 Adressen wurden erkannt, ist es sinnvoll, das gesamte Netzwerk zu blockieren. Die Blockierung ist auf 3 Tage eingestellt. Wenn während dieser Zeit keine Angriffe von dieser Quelle ausgeführt wurden, wird diese Quelle automatisch von der schwarzen Liste entfernt. Die Liste der blockierten Quellen wird alle 300 Sekunden aktualisiert.
Diese Liste finden Sie hier unter folgender Adresse:
https://secure.tucha.ua/global-filter/banned/rdp_ddos. Auf dieser Grundlage können Sie Ihre eigenen ACLs erstellen.
Wir sind bereit, den Quellcode eines solchen Systems zu teilen, es gibt nichts Super-Kompliziertes (dies sind ein paar einfache Skripte, die buchstäblich in ein paar Stunden „auf dem Knie“ geschrieben wurden), und gleichzeitig kann es angepasst und verwendet werden, um nicht nur vor einem solchen Angriff zu schützen, sondern auch zu identifizieren und Blockieren von Netzwerk-Scan-Versuchen:
Folgen Sie diesem Link.Darüber hinaus haben wir einige Änderungen an den Einstellungen des Überwachungssystems vorgenommen, das nun die Reaktion der Kontrollgruppe der virtuellen Server in unserer Cloud auf den Versuch, eine RDP-Verbindung herzustellen, genau überwacht. Wenn die Reaktion keine Sekunde lang folgte, ist dies eine Gelegenheit, Aufmerksamkeit zu schenken.
Die Lösung erwies sich als sehr effektiv: Es gibt keine Beschwerden mehr von Kunden und Partnern sowie vom Überwachungssystem. Die „schwarze Liste“ enthält regelmäßig neue Adressen und ganze Netzwerke, was darauf hinweist, dass der Angriff fortgesetzt wird, die Arbeit unserer Kunden jedoch nicht mehr beeinträchtigt.
Allein auf dem Feld ist kein Krieger
Heute haben wir erfahren, dass andere Betreiber mit einem ähnlichen Problem konfrontiert sind. Jemand glaubt immer noch, dass Microsoft einige Änderungen am RAS-Servicecode vorgenommen hat (wenn Sie sich erinnern, haben wir am ersten Tag dasselbe vermutet, aber diese Version sehr bald abgelehnt) und verspricht, alles Mögliche zu tun finde bald eine Lösung. Jemand ignoriert das Problem einfach und rät Kunden, sich selbst zu schützen (den Verbindungsport ändern, den Server in einem privaten Netzwerk verstecken usw.). Und am ersten Tag haben wir nicht nur dieses Problem gelöst, sondern auch einige Grundlagen für ein globaleres Bedrohungserkennungssystem geschaffen, das wir weiterentwickeln möchten.
Besonderer Dank geht an Kunden und Partner, die nicht geschwiegen haben und nicht am Flussufer gesessen haben, in der Erwartung, dass eines Tages die Leiche des Feindes darauf schweben würde, und unsere Aufmerksamkeit sofort auf das Problem gelenkt haben, das uns die Möglichkeit gab, es am selben Tag zu beseitigen.