We vertellen je een interessant verhaal over hoe "derde partijen" probeerden de werkzaamheden van onze klanten te verstoren, en hoe dit probleem werd opgelost.
Hoe het allemaal begon
Het begon op de ochtend van 31 oktober, de laatste dag van de maand, wanneer velen dringend belangrijke kwesties moesten afhandelen.
Een van de partners, die verschillende virtuele machines van klanten in onze cloud exploiteert, meldde dat verschillende Windows-servers op onze Oekraïense locatie van 9:10 tot 9:20 geen verbinding konden maken met de remote desktop-service, gebruikers konden niet inloggen op hun werkdesktop, maar na enkele minuten leek het probleem vanzelf te zijn opgelost.
We hebben de statistieken van de communicatielijnen gecontroleerd, maar vonden geen verkeerspieken of uitval. We keken naar de belastingstatistieken van de rekenbronnen - geen anomalieën. Wat was dit?
Vervolgens meldde een andere partner, die nog eens bijna honderd servers in onze cloud heeft, vergelijkbare problemen die sommige van hun klanten opmerkten. Het bleek dat de servers over het algemeen beschikbaar waren (ze reageerden correct op ping-tests en andere aanvragen), maar de remote desktop-service op deze servers accepteerde afwisselend nieuwe verbindingen en wees ze af, waarbij het ging om servers op verschillende locaties, waarvan het verkeer uit verschillende dataverbindingen kwam.
Laten we deze verkeersdata eens bekijken. Een pakket met een verzoek om verbinding op te zetten komt op de server binnen:
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
De server ontvangt dit pakket, maar de verbinding wordt afgewezen:
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
Dit betekent dat het probleem duidelijk niet veroorzaakt wordt door storingen in de infrastructuur, maar door iets anders. Misschien hebben alle gebruikers problemen met de licenties voor de remote desktops? Misschien heeft er zich kwaadaardige software in hun systemen genesteld, dat vandaag is geactiveerd, zoals enkele jaren geleden met XData en Petya?
Terwijl we het uitzochten, ontvingen we soortgelijke verzoeken van nog een paar klanten en partners.
Wat gebeurt er eigenlijk op deze machines?
In de logboeken van gebeurtenissen staan veel berichten over pogingen om wachtwoorden te raden:
Dergelijke pogingen worden meestal geregistreerd op alle servers waar de standaardpoort (3389) wordt gebruikt voor de externe toegang en waar toegang vanaf overal is toegestaan. Het internet zit vol bots die continu alle beschikbare aansluitpunten scannen en proberen wachtwoorden te raden (precies om deze reden raden we aan om complexe wachtwoorden te gebruiken in plaats van '123'). Desondanks was de intensiteit van deze pogingen op die dag veel te hoog.
Wat te doen?
Onze klanten aanraden om veel tijd te besteden aan het wijzigen van de instellingen van een groot aantal eindgebruikers om over te schakelen naar een andere poort? Geen goed idee, klanten zullen daar niet blij mee zijn. Aanbevelen om toegang alleen via VPN toe te staan? In de haast en paniek IPSec-verbindingen opzetten, waar die niet zijn opgezet, zal onze klanten ook geen geluk brengen. Hoewel, het moet gezegd worden, dat het in alle gevallen een nobele zaak is, raden we altijd aan om de server in een privé netwerk te verbergen en we zijn bereid om te helpen met de instellingen. Voor degenen die het zelfstandig willen uitzoeken delen we instructies voor het instellen van IPSec/L2TP in onze cloud in site-to-site of road-warrior modus, en als iemand de VPN-service op zijn eigen Windows-server wil opzetten, zijn we altijd bereid om tips te delen over het opzetten van standaard RAS of OpenVPN. Maar hoe geweldig we ook zijn, dit was niet het beste moment voor voorlichting aan klanten, omdat het belangrijk was om het probleem zo snel mogelijk op te lossen met een minimale belasting voor de gebruikers.
De oplossing die we hebben geïmplementeerd, bestond uit het volgende. We hebben de analyse van het inkomende verkeer zodanig ingericht dat we alle pogingen om een TCP-verbinding met poort 3389 te maken, kunnen volgen en adressen selecteren die binnen 150 seconden verbindingen proberen te leggen met meer dan 16 verschillende servers in ons netwerk - dit zijn de bronnen van de aanval (uiteraard, als een van onze klanten of partners een echte behoefte heeft om verbindingen met zoveel servers vanaf dezelfde bron te maken, kunnen we dergelijke bronnen altijd aan de 'witte lijst' toevoegen). Als in één C-klasse netwerk meer dan 32 adressen zijn vastgesteld, is het zinnig om het hele netwerk te blokkeren. De blokkade wordt ingesteld voor 3 dagen en als er in deze tijd geen aanvallen vanuit deze bron zijn geweest, wordt deze bron automatisch uit de 'zwarte lijst' verwijderd. De lijst met geblokkeerde bronnen wordt elke 300 seconden bijgewerkt.
Deze lijst is toegankelijk via het volgende adres: , u kunt er uw eigen ACL op baseren.
We zijn bereid om de broncode van zo'n systeem te delen, er is niets bovenmatig ingewikkeld (dit zijn een paar eenvoudige scripts, samengesteld in slechts enkele uren 'op de knieën'), en bovendien kan het worden aangepast en gebruikt, niet alleen voor bescherming tegen een dergelijke aanval, maar ook voor het identificeren en blokkeren van elke poging om het netwerk te scannen:
Bovendien hebben we enkele aanpassingen gedaan in de instellingen van het monitoringsysteem, dat nu nauwlettender toeziet op de reactie van de controlegroep van virtuele servers in onze cloud op pogingen om een RDP-verbinding tot stand te brengen: als er binnen een seconde geen reactie was, is dat een reden om aandacht te besteden.
De oplossing bleek behoorlijk effectief te zijn: er zijn geen klachten meer, zowel van klanten en partners als van het monitoringsysteem. Nieuwe adressen en hele netwerken komen regelmatig op de 'zwarte lijst', wat aangeeft dat de aanval doorgaat, maar al geen invloed meer heeft op de werking van onze klanten.
Één in het veld is geen krijger
Vandaag kwamen we erachter dat andere providers ook met een vergelijkbaar probleem kampen. Sommigen geloven nog steeds dat Microsoft wijzigingen in de code van de Remote Access-dienst heeft aangebracht (als je het je herinnert, vermoeden we op de eerste dag hetzelfde, maar die versie hebben we al snel verworpen) en beloven alles te doen om zo snel mogelijk een oplossing te vinden. Anderen negeren simpelweg het probleem en adviseren klanten om zelf maatregelen te nemen (de poort te wijzigen, de server in een privénetwerk te verbergen, enzovoorts). Maar op de eerste dag hebben we niet alleen dit probleem opgelost, maar ook de basis gelegd voor een meer geavanceerd bedreigingsdetectiesysteem, dat we willen ontwikkelen.
Een speciale dank aan de klanten en partners die niet zwijgen en niet aan de zijlijn wachten tot het lichaam van de vijand eens voorbij drijft, maar ons meteen op het probleem attenderen, wat ons de mogelijkheid gaf om het dezelfde dag nog op te lossen.
Bron: habr.com
