Erzählen wir Ihnen eine coole Geschichte darüber, wie „Dritte“ versucht haben, sich in die Arbeit unserer Kunden einzumischen, und wie dieses Problem gelöst wurde.
Wie alles begann
Alles begann am Morgen des 31. Oktober, dem letzten Tag des Monats, an dem viele dringend Zeit brauchen, um dringende und wichtige Probleme zu lösen.
Einer der Partner, der mehrere virtuelle Maschinen der von ihm betreuten Kunden in unserer Cloud hält, berichtete, dass von 9:10 bis 9:20 Uhr mehrere Windows-Server, die auf unserer ukrainischen Website ausgeführt wurden, keine Verbindungen zum RAS-Dienst akzeptierten, Benutzer konnten dies nicht sich bei ihren Desktops anzumelden, aber nach ein paar Minuten schien sich das Problem von selbst zu lösen.
Wir haben die Statistiken zum Betrieb der Kommunikationskanäle erhoben, konnten jedoch keine Verkehrsspitzen oder Ausfälle feststellen. Wir haben uns die Statistiken zur Belastung der Rechenressourcen angesehen – keine Auffälligkeiten. Und was war das?
Dann meldete ein anderer Partner, der etwa hundert weitere Server in unserer Cloud hostet, die gleichen Probleme, die einige seiner Kunden festgestellt hatten, und es stellte sich heraus, dass die Server im Allgemeinen erreichbar waren (und ordnungsgemäß auf den Ping-Test und andere Anfragen reagierten), aber Der Fernzugriffsdienst auf diesen Servern akzeptiert entweder neue Verbindungen oder lehnt sie ab, und wir sprachen über Server an verschiedenen Standorten, deren Datenverkehr über unterschiedliche Datenübertragungskanäle erfolgt.
Schauen wir uns diesen Verkehr an. Beim Server kommt ein Paket mit einer Verbindungsanfrage 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, lehnt die Verbindung 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 Probleme im Betrieb der Infrastruktur verursacht wird, sondern durch etwas anderes. Vielleicht haben alle Benutzer Probleme mit der Remote-Desktop-Lizenzierung? Vielleicht ist es irgendeiner Art von Schadsoftware gelungen, in ihre Systeme einzudringen, und heute wurde sie wie vor ein paar Jahren aktiviert XDaten и Petya?
Während wir das Problem klärten, erhielten wir ähnliche Anfragen von mehreren weiteren Kunden und Partnern.
Was passiert eigentlich auf diesen Maschinen?
Die Ereignisprotokolle sind voll von Meldungen über Versuche, das Passwort zu erraten:
Typischerweise werden solche Versuche auf allen Servern registriert, auf denen der Standardport (3389) für den Fernzugriffsdienst verwendet wird und der Zugriff von überall erlaubt ist. Das Internet ist voller Bots, die ständig alle verfügbaren Verbindungspunkte scannen und versuchen, das Passwort zu erraten (aus diesem Grund empfehlen wir dringend, komplexe Passwörter anstelle von „123“ zu verwenden). Allerdings war die Intensität dieser Versuche an diesem Tag zu hoch.
Was soll ich tun?
Sollen Kunden viel Zeit damit verbringen, Einstellungen zu ändern, damit eine große Anzahl von Endbenutzern zu einem anderen Port wechseln kann? Keine gute Idee, die Kunden werden nicht zufrieden sein. Empfehlen Sie, den Zugriff nur über VPN zuzulassen? In Eile und Panik, IPSec-Verbindungen für diejenigen aufzubauen, die sie nicht aufgebaut haben – vielleicht lächelt ein solches Glück auch den Kunden nicht zu. Obwohl ich sagen muss, dass dies auf jeden Fall eine göttliche Sache ist, empfehlen wir immer, den Server in einem privaten Netzwerk zu verstecken und sind bereit, bei den Einstellungen zu helfen, und für diejenigen, die es gerne selbst herausfinden möchten, geben wir Anweisungen zum Einrichten von IPSec/L2TP in unserer Cloud im Site-to-Site- oder Road-Modus -Warrior, und wenn jemand einen VPN-Dienst auf seinem eigenen Windows-Server einrichten möchte, ist er jederzeit bereit, Tipps zum Einrichten eines VPN-Dienstes zu geben Standard-RAS oder OpenVPN. Aber so cool wir auch waren, dies war nicht der beste Zeitpunkt, um die Kunden aufzuklären, da wir das Problem so schnell wie möglich und mit minimalem Stress für die Benutzer beheben mussten.
Die von uns implementierte Lösung war wie folgt. Wir haben eine Analyse des weitergeleiteten Datenverkehrs so eingerichtet, dass alle Versuche, eine TCP-Verbindung zum Port 3389 aufzubauen, überwacht werden und daraus Adressen ausgewählt werden, die innerhalb von 150 Sekunden versuchen, Verbindungen zu mehr als 16 verschiedenen Servern in unserem Netzwerk aufzubauen - Dies sind die Quellen des Angriffs (Wenn einer der Kunden oder Partner tatsächlich einen echten Bedarf hat, Verbindungen zu so vielen Servern aus derselben Quelle herzustellen, können Sie solche Quellen natürlich jederzeit zur „weißen Liste“ hinzufügen). Wenn in einem Klasse-C-Netzwerk für diese 150 Sekunden mehr als 32 Adressen identifiziert werden, ist es sinnvoll, das gesamte Netzwerk zu sperren. Die Sperrung ist auf 3 Tage eingestellt, und wenn in dieser Zeit keine Angriffe von einer bestimmten Quelle aus durchgeführt wurden, Diese Quelle wird automatisch aus der „schwarzen Liste“ entfernt. Die Liste der blockierten Quellen wird alle 300 Sekunden aktualisiert.
Diese Liste ist unter dieser Adresse verfügbar: , können Sie darauf basierend Ihre ACLs erstellen.
Wir sind bereit, den Quellcode eines solchen Systems zu teilen; es enthält nichts übermäßig Komplexes (das sind mehrere einfache Skripte, die buchstäblich in ein paar Stunden auf dem Knie kompiliert wurden), und gleichzeitig kann es angepasst und nicht verwendet werden nur zum Schutz vor einem solchen Angriff, sondern auch zum Erkennen und Blockieren von Versuchen, das Netzwerk zu scannen:
Darüber hinaus haben wir einige Änderungen an den Einstellungen des Überwachungssystems vorgenommen, das nun die Reaktion einer Kontrollgruppe virtueller Server in unserer Cloud auf einen Versuch, eine RDP-Verbindung aufzubauen, genauer überwacht: Wenn die Reaktion nicht innerhalb einer Minute erfolgt Zweitens ist dies ein Grund, aufmerksam zu sein.
Die Lösung erwies sich als sehr effektiv: Es gibt keine Beschwerden mehr von Kunden und Partnern sowie vom Überwachungssystem. Regelmäßig werden neue Adressen und ganze Netzwerke zur Blacklist hinzugefügt, was darauf hinweist, dass der Angriff andauert, die Arbeit unserer Kunden jedoch nicht mehr beeinträchtigt wird.
Einer auf dem Gebiet ist kein Krieger
Heute haben wir erfahren, dass andere Betreiber auf ein ähnliches Problem gestoßen sind. Jemand glaubt immer noch, dass Microsoft einige Änderungen am Code des Fernzugriffsdienstes vorgenommen hat (wenn Sie sich erinnern, haben wir am ersten Tag das Gleiche vermutet, diese Version aber sehr schnell abgelehnt) und verspricht, alles zu tun, um schnell eine Lösung zu finden . Manche Leute ignorieren das Problem einfach und raten den Kunden, sich selbst zu schützen (den Verbindungsport ändern, den Server in einem privaten Netzwerk verstecken usw.). Und gleich am ersten Tag haben wir nicht nur dieses Problem gelöst, sondern auch die Grundlagen für ein globaleres Bedrohungserkennungssystem geschaffen, das wir entwickeln wollen.
Besonderer Dank gilt den Kunden und Partnern, die nicht schwiegen und nicht am Flussufer saßen und darauf warteten, dass eines Tages die Leiche eines Feindes entlangschwimmte, sondern uns sofort auf das Problem aufmerksam machten, was uns die Möglichkeit gab, es zu beseitigen es noch am selben Tag.
Source: habr.com