Laten we u een leuk verhaal vertellen over hoe "derden" zich probeerden te bemoeien met het werk van onze klanten, en hoe dit probleem werd opgelost.
Hoe het allemaal begon
Het begon allemaal op de ochtend van 31 oktober, de laatste dag van de maand, toen velen wanhopig tijd nodig hadden om dringende en belangrijke problemen op te lossen.
Een van de partners, die verschillende virtuele machines van de klanten die hij bedient in onze cloud bewaart, meldde dat tussen 9 en 10 uur verschillende Windows-servers die op onze Oekraïense site draaien geen verbindingen met de dienst voor externe toegang accepteerden. om in te loggen op hun desktops, maar na een paar minuten leek het probleem zichzelf op te lossen.
We hebben de statistieken over de werking van communicatiekanalen verhoogd, maar hebben geen verkeerspieken of -storingen gevonden. We hebben gekeken naar de statistieken over de belasting van computerbronnen - geen afwijkingen. En wat was dat?
Vervolgens meldde een andere partner, die nog zo'n honderd servers in onze cloud host, dezelfde problemen die sommige van hun klanten opmerkten, en het bleek dat de servers over het algemeen toegankelijk waren (goed reageerden op de ping-test en andere verzoeken), maar de dienst externe toegang op deze servers accepteert nieuwe verbindingen of weigert ze, en we hadden het over servers op verschillende sites, waar het verkeer naartoe komt van verschillende datatransmissiekanalen.
Laten we eens kijken naar dit verkeer. Een pakket met een verbindingsverzoek arriveert bij de 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
De server ontvangt dit pakket, maar weigert de verbinding:
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 wordt veroorzaakt door problemen in de werking van de infrastructuur, maar door iets anders. Misschien hebben alle gebruikers problemen met licentieverlening op afstand? Misschien is een of andere vorm van malware erin geslaagd hun systemen binnen te dringen en werd deze vandaag geactiveerd, net als een paar jaar geleden XGegevens и Petya?
Terwijl we dit aan het uitzoeken waren, ontvingen we soortgelijke verzoeken van nog meer klanten en partners.
Wat gebeurt er eigenlijk op deze machines?
De gebeurtenislogboeken staan vol met berichten over pogingen om het wachtwoord te raden:
Normaal gesproken worden dergelijke pogingen geregistreerd op alle servers waar de standaardpoort (3389) wordt gebruikt voor de service voor externe toegang en toegang overal vandaan is toegestaan. Het internet staat vol met bots die voortdurend alle beschikbare verbindingspunten scannen en proberen het wachtwoord te raden (daarom raden we ten zeerste aan complexe wachtwoorden te gebruiken in plaats van “123”). De intensiteit van deze pogingen die dag was echter te hoog.
Wat moet ik doen?
Beveelt u aan dat klanten veel tijd besteden aan het wijzigen van instellingen zodat een groot aantal eindgebruikers naar een andere poort kan overstappen? Geen goed idee, klanten zullen niet blij zijn. Aanbevelen om alleen toegang via VPN toe te staan? In haast en paniek IPSec-verbindingen opzetten voor degenen die ze niet hebben - misschien lacht dergelijk geluk ook niet naar klanten. Hoewel ik moet zeggen dat dit in ieder geval iets goddelijks is, raden we altijd aan de server in een particulier netwerk te verbergen en staan we klaar om te helpen met de instellingen, en voor degenen die het graag zelf willen uitzoeken, delen we instructies voor het opzetten van IPSec/L2TP in onze cloud in site-to-site of road-modus -warrior, en als iemand een VPN-service op zijn eigen Windows-server wil opzetten, staat hij altijd klaar om tips te delen over hoe je een VPN-service kunt opzetten standaard RAS of OpenVPN. Maar hoe cool we ook waren, dit was niet het beste moment om educatief werk onder klanten uit te voeren, omdat we het probleem zo snel mogelijk moesten oplossen met minimale stress voor de gebruikers.
De oplossing die wij hebben geïmplementeerd was als volgt. We hebben een analyse van passerend verkeer zo opgezet dat we alle pogingen om een TCP-verbinding tot stand te brengen met poort 3389 monitoren en daaruit adressen selecteren die binnen 150 seconden proberen verbindingen tot stand te brengen met meer dan 16 verschillende servers op ons netwerk - dit zijn de bronnen van de aanval (als een van de clients of partners echt behoefte heeft om verbindingen tot stand te brengen met zoveel servers van dezelfde bron, kun je dergelijke bronnen natuurlijk altijd toevoegen aan de ‘witte lijst’. als in één klasse C-netwerk gedurende deze 150 seconden meer dan 32 adressen worden geïdentificeerd, is het zinvol om het hele netwerk te blokkeren. De blokkering wordt ingesteld voor 3 dagen, en als er gedurende deze tijd geen aanvallen vanuit een bepaalde bron zijn uitgevoerd, deze bron wordt automatisch verwijderd van de “zwarte lijst”. De lijst met geblokkeerde bronnen wordt elke 300 seconden bijgewerkt.
Deze lijst is beschikbaar op dit adres: , kunt u uw ACL's daarop baseren.
We zijn bereid om de broncode van een dergelijk systeem te delen; er zit niets overdreven ingewikkelds in (dit zijn verschillende eenvoudige scripts die letterlijk in een paar uur op de knie zijn samengesteld), en tegelijkertijd kan het worden aangepast en niet worden gebruikt alleen om bescherming te bieden tegen een dergelijke aanval, maar ook om pogingen om het netwerk te scannen te detecteren en te blokkeren:
Daarnaast hebben we enkele wijzigingen aangebracht in de instellingen van het monitoringsysteem, dat nu nauwlettender de reactie van een controlegroep van virtuele servers in onze cloud op een poging om een RDP-verbinding tot stand te brengen in de gaten houdt: als de reactie niet volgt binnen een ten tweede is dit een reden om op te letten.
De oplossing bleek behoorlijk effectief: er zijn geen klachten meer van zowel klanten als partners, en van het monitoringsysteem. Regelmatig worden er nieuwe adressen en hele netwerken aan de zwarte lijst toegevoegd, wat aangeeft dat de aanval doorgaat, maar geen invloed meer heeft op het werk van onze klanten.
Een in het veld is geen krijger
Vandaag hebben we vernomen dat andere operators een soortgelijk probleem zijn tegengekomen. Iemand gelooft nog steeds dat Microsoft enkele wijzigingen heeft aangebracht in de code van de dienst voor externe toegang (als je het je herinnert, vermoedden we hetzelfde op de eerste dag, maar we hebben deze versie zeer snel afgewezen) en belooft al het mogelijke te doen om snel een oplossing te vinden . Sommige mensen negeren het probleem eenvoudigweg en adviseren klanten om zichzelf zelf te beschermen (de verbindingspoort wijzigen, de server in een particulier netwerk verbergen, enzovoort). En op de allereerste dag hebben we niet alleen dit probleem opgelost, maar ook de basis gelegd voor een meer mondiaal systeem voor detectie van bedreigingen, dat we van plan zijn te ontwikkelen.
Speciale dank aan de klanten en partners die niet zwegen en niet op de oever van de rivier zaten te wachten tot het lijk van een vijand er op een dag langs zou drijven, maar onmiddellijk onze aandacht op het probleem vestigden, waardoor we de kans kregen om het probleem op te lossen het op dezelfde dag.
Bron: www.habr.com