Wir erzählen Ihnen eine interessanter 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, als viele unbedingt dringende und wichtige Angelegenheiten abschließen mussten.
Einer der Partner, der in unserer Cloud mehrere virtuelle Maschinen von Kunden betreibt, die er unterstützt, berichtete, dass von 9:10 bis 9:20 mehrere Windows-Server, die auf unserer ukrainischen Plattform laufen, keine Verbindungen zum Remote-Desktop-Dienst akzeptierten. Die Benutzer konnten nicht auf ihre Arbeitsoberflächen zugreifen, doch nach wenigen Minuten schien sich das Problem von selbst zu lösen.
Wir haben die Statistiken der Kommunikationskanäle analysiert, fanden jedoch weder Traffic-Spitzen noch -Einbrüche. Wir haben die Statistiken der Rechenressourcenauslastung überprüft – keine Anomalien. Was könnte das gewesen sein?
Dann berichtete ein weiterer Partner, der in unserer Cloud noch fast hundert Server aufstellt, von ähnlichen Problemen, die einige ihrer Kunden festgestellt hatten. Dabei stellte sich heraus, dass die Server insgesamt erreichbar waren (sie reagierten ordnungsgemäß auf Ping-Tests und andere Anfragen), aber der Remote-Desktop-Dienst auf diesen Servern wechselhaft neue Verbindungen akzeptierte oder ablehnte, obwohl es sich um Server auf verschiedenen Plattformen handelte, deren Traffic aus verschiedenen Datenkanälen kam.
Lassen Sie uns diesen Traffic näher betrachten. Ein Paket mit der Anfrage zur установлении соединения kommt auf 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 empfängt dieses Paket, weiß jedoch das Verbindung abzulehnen:
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 durch irgendwelche Störungen in der Infrastruktur verursacht wird, sondern durch etwas anderes. Könnte es sein, dass alle Benutzer Probleme mit der Lizenzierung der Remote-Desktops hatten? Vielleicht hat sich irgendeine Malware in ihre Systeme eingeschlichen, und heute wurde sie aktiviert, wie vor ein paar Jahren bei XData und Petya?
Während wir uns umschauten, erhielten wir ähnliche Anfragen von mehreren anderen Kunden und Partnern.
Was passiert generell auf diesen Maschinen?
In den Ereignisprotokollen gibt es zahlreiche Meldungen über versuche, Passwörter zu knacken:
Solche Versuche werden normalerweise auf allen Servern registriert, bei denen der Standardport (3389) für den Remote-Zugriff verwendet wird und der Zugriff von überall erlaubt ist. Im Internet gibt es zahlreiche Bots, die ständig alle verfügbaren Verbindungspunkte scannen und versuchen, Passwörter zu erraten (genau aus diesem Grund empfehlen wir dringend, komplexe Passwörter anstelle von "123" zu verwenden). Dennoch war die Intensität dieser Versuche an diesem Tag einfach zu hoch.
Wie soll man vorgehen?
Empfehlen wir den Kunden, viel Zeit damit zu verbringen, die Einstellungen einer riesigen Anzahl von Endbenutzern zu ändern, um auf einen anderen Port umzuschalten? Keine besonders gute Idee, die Kunden werden nicht begeistert sein. Sollten wir empfehlen, den Zugriff nur über VPN zu erlauben? In der Eile und Panik IPSec-Verbindungen aufzubauen, wo sie nicht bereits bestehen, – das wird den Kunden auch nicht erfreuen. Obwohl, man muss sagen, das ist in jedem Fall eine lobenswerte Sache, wir empfehlen immer, den Server in ein privates Netzwerk zu verstecken und sind bereit, bei den Einstellungen zu helfen. Für diejenigen, die selbständig was anpacken wollen, teilen wir Anleitungen zur Einrichtung von IPSec/L2TP in unserer Cloud im Modus site-to-site oder road-warrior. Und falls jemand einen VPN-Dienst auf seinem eigenen Windows-Server einrichten möchte – sind wir immer bereit, Tipps zur Einrichtung eines Standard RAS oder OpenVPN zu geben. Aber, so großartig wir auch sein mögen, es war nicht die beste Zeit, um bei den Kunden aufklärerisch zu wirken, da das Problem so schnell wie möglich mit minimalem Aufwand für die Benutzer behoben werden musste.
Die Lösung, die wir implementiert haben, bestand darin, den Datenverkehr so zu analysieren, dass alle Versuche, eine TCP-Verbindung zu Port 3389 herzustellen, verfolgt werden. Dabei werden Adressen ermittelt, die innerhalb von 150 Sekunden versuchen, Verbindungen zu mehr als 16 verschiedenen Servern in unserem Netzwerk herzustellen. Diese sind die Angriffsquellen (natürlich, falls einer unserer Kunden oder Partner tatsächlich Bedarf hat, Verbindungen zu so vielen Servern von einer einzigen Quelle herzustellen, können solche Quellen jederzeit zur "Whitelist" hinzugefügt werden). Sollte innerhalb dieser 150 Sekunden in einem Class-C-Netzwerk mehr als 32 Adressen identifiziert werden, macht es Sinn, das gesamte Netzwerk zu blockieren. Die Blockierung wird für 3 Tage eingerichtet, und wenn in dieser Zeit von dieser Quelle keine Angriffe 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: , können Sie auf ihrer Grundlage Ihre eigenen ACLs erstellen.
Den Quellcode eines solchen Systems sind wir bereit, zu teilen. Es ist nichts besonders Komplexes (es sind ein paar einfache Skripte, die buchstäblich in ein paar Stunden "auf die Schnelle" erstellt wurden), und er kann sowohl zur Abwehr solcher Angriffe als auch zur Erkennung und Blockierung jeglicher Versuche zur Netzwerkscanning verwendet werden:
Zusätzlich haben wir einige Änderungen an den Systemeinstellungen zur Überwachung vorgenommen, die nun genauer die Reaktion einer Kontrollgruppe von virtuellen Servern in unserer Cloud auf den Versuch, eine RDP-Verbindung herzustellen, überwacht: Wenn innerhalb einer Sekunde keine Reaktion erfolgt, ist dies ein Grund zur Aufmerksamkeit.
Die Lösung erwies sich als recht effektiv: Beschwerden von Seiten der Kunden und Partner sowie des Überwachungssystems sind nicht mehr vorhanden. Neue Adressen und ganze Netzwerke landen regelmäßig auf der "Blacklist", was darauf hindeutet, dass der Angriff weiterhin stattfindet, jedoch keine Auswirkungen mehr auf die Arbeit unserer Kunden hat.
Allein im Feld ist kein Krieger.
Heute haben wir erfahren, dass auch andere Anbieter mit ähnlichen Problemen konfrontiert sind. Einige glauben immer noch, dass Microsoft Änderungen am Code des Remote-Access-Dienstes vorgenommen hat (wenn Sie sich erinnern, haben wir am ersten Tag dasselbe vermutet, aber diese Version haben wir sehr schnell verworfen) und versprechen, alles Mögliche zu tun, um so schnell wie möglich eine Lösung zu finden. Manche ignorieren einfach das Problem und raten den Kunden, sich selbst abzusichern (den Anschlussport zu ändern, den Server in ein privates Netzwerk zu verstecken usw.). Aber wir haben am ersten Tag nicht nur dieses Problem gelöst, sondern auch einen Grundstock für ein umfassenderes Bedrohungserkennungssystem geschaffen, das wir entwickeln wollen.
Ein besonderer Dank gilt den Kunden und Partnern, die nicht geschwiegen und nicht am Ufer des Flusses gesessen haben und darauf gewartet haben, dass die Leiche des Feindes einmal vorbeischwimmt, sondern sofort unsere Aufmerksamkeit auf das Problem gelenkt haben, was es uns ermöglicht hat, es noch am selben Tag zu beheben.
Quelle: habr.com
