Kerrotaanpa sinulle hieno tarina siitä, kuinka "kolmannet osapuolet" yrittivät häiritä asiakkaidemme työtä ja kuinka tämä ongelma ratkesi.
Miten kaikki alkoi
Kaikki alkoi aamulla 31. lokakuuta, kuukauden viimeisenä päivänä, jolloin monet tarvitsevat kipeästi aikaa ratkaista kiireellisiä ja tärkeitä asioita.
Yksi kumppaneista, joka pitää pilvessämme palvelemiensa asiakkaiden useita virtuaalikoneita, kertoi, että useat ukrainalaisella sivustollamme toimivat Windows-palvelimet eivät hyväksyneet yhteyksiä etäkäyttöpalveluun klo 9–10. kirjautua työpöydälleen, mutta muutaman minuutin kuluttua ongelma näytti ratkeavan itsestään.
Nostimme viestintäkanavien toiminnan tilastoja, mutta emme löytäneet liikennepiikkiä tai -vikoja. Tarkastelimme tilastoja laskentaresurssien kuormituksesta - ei poikkeamia. Ja mikä se oli?
Sitten toinen kumppani, joka isännöi noin sataa palvelinta lisää pilvessämme, ilmoitti samoista ongelmista, joita jotkut heidän asiakkaistaan havaitsivat, ja kävi ilmi, että palvelimet olivat yleisesti saatavilla (vastasivat oikein ping-testiin ja muihin pyyntöihin), mutta palvelun etäkäyttö näillä palvelimilla joko ottaa vastaan uusia yhteyksiä tai hylkää ne, ja puhuttiin eri sivustojen palvelimista, joihin liikenne tulee eri tiedonsiirtokanavista.
Katsotaanpa tätä liikennettä. Yhteyspyynnön sisältävä paketti saapuu palvelimelle:
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
Palvelin vastaanottaa tämän paketin, mutta hylkää yhteyden:
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
Tämä tarkoittaa, että ongelma ei selvästikään johdu infrastruktuurin toiminnan ongelmista, vaan jostain muusta. Ehkä kaikilla käyttäjillä on ongelmia etätyöpöydän lisensoinnin kanssa? Ehkä jokin haittaohjelma onnistui tunkeutumaan heidän järjestelmiinsä, ja tänään se aktivoitiin, kuten pari vuotta sitten XData и Petya?
Lajittelumme aikana saimme samanlaisia pyyntöjä useilta muilta asiakkailta ja yhteistyökumppaneilta.
Mitä näissä koneissa oikein tapahtuu?
Tapahtumalokit ovat täynnä viestejä salasanan arvausyrityksistä:
Tyypillisesti tällaiset yritykset rekisteröidään kaikille palvelimille, joissa standardiporttia (3389) käytetään etäkäyttöpalveluun ja pääsy on sallittu kaikkialta. Internet on täynnä botteja, jotka jatkuvasti skannaavat kaikkia saatavilla olevia yhteyspisteitä ja yrittävät arvata salasanan (siksi suosittelemme monimutkaisten salasanojen käyttöä "123":n sijaan). Näiden yritysten intensiteetti sinä päivänä oli kuitenkin liian korkea.
Mitä minun pitäisi tehdä?
Suositteletko, että asiakkaat viettävät paljon aikaa asetusten muuttamiseen, jotta suuri määrä loppukäyttäjiä vaihtaa toiseen porttiin? Ei hyvä idea, asiakkaat eivät ole tyytyväisiä. Suositteletko pääsyn sallimista vain VPN:n kautta? Kiireessä ja paniikissa IPSec-yhteyksien nostamista niille, joilla niitä ei ole kasvatettu - ehkäpä sellainen onni ei hymyile asiakkaillekään. Vaikka minun on sanottava, että tämä on joka tapauksessa jumalallinen asia, suosittelemme aina piilottamaan palvelimen yksityiseen verkkoon ja olemme valmiita auttamaan asetuksissa, ja niille, jotka haluavat selvittää sen itse, jaamme ohjeita IPSec/L2TP:n määrittämiseen pilvessämme sivustosta-sivustoon tai tietilassa -soturi, ja jos joku haluaa perustaa VPN-palvelun omalle Windows-palvelimelleen, hän on aina valmis jakamaan vinkkejä vakio RAS tai OpenVPN. Mutta vaikka olimme kuinka viileitä, tämä ei ollut paras aika tehdä koulutustyötä asiakkaiden kesken, koska meidän piti korjata ongelma mahdollisimman nopeasti ja käyttäjille mahdollisimman vähän stressiä.
Toteuttamamme ratkaisu oli seuraava. Olemme määrittäneet kulkevan liikenteen analyysin siten, että voimme valvoa kaikkia yrityksiä muodostaa TCP-yhteys porttiin 3389 ja valita siitä osoitteet, jotka yrittävät 150 sekunnin sisällä muodostaa yhteyden yli 16 eri palvelimeen verkossamme. - nämä ovat hyökkäyksen lähteitä ( Tietysti, jos jollakin asiakkaista tai kumppaneista on todellinen tarve luoda yhteyksiä niin moneen palvelimeen samasta lähteestä, voit aina lisätä tällaiset lähteet "valkoiselle listalle." Lisäksi, jos yhdessä luokan C verkossa näiden 150 sekunnin aikana tunnistetaan yli 32 osoitetta, on järkevää estää koko verkko. Esto on asetettu 3 päiväksi, ja jos tänä aikana ei ole tehty hyökkäyksiä tietystä lähteestä, tämä lähde poistetaan automaattisesti "mustalta listalta". Estettyjen lähteiden luettelo päivitetään 300 sekunnin välein.
Tämä luettelo on saatavilla tästä osoitteesta: , voit rakentaa ACL-luettelosi sen perusteella.
Olemme valmiita jakamaan tällaisen järjestelmän lähdekoodin, siinä ei ole mitään liian monimutkaista (nämä ovat useita yksinkertaisia skriptejä, jotka on koottu kirjaimellisesti parissa tunnissa polveen), ja samalla sitä voidaan mukauttaa ja käyttää ilman vain suojatakseen tällaista hyökkäystä, mutta myös havaitakseen ja estääkseen kaikki verkon skannausyritykset:
Lisäksi olemme tehneet joitain muutoksia valvontajärjestelmän asetuksiin, joka nyt tarkkailee entistä tarkemmin pilvessämme olevien virtuaalipalvelimien ohjausryhmän reaktiota yritykseen muodostaa RDP-yhteys: jos reaktio ei seuraa toiseksi tämä on syy kiinnittää huomiota.
Ratkaisu osoittautui varsin tehokkaaksi: ei enää valituksia asiakkailta, kumppaneilta eikä seurantajärjestelmältä. Uusia osoitteita ja kokonaisia verkkoja lisätään säännöllisesti mustalle listalle, mikä osoittaa, että hyökkäys jatkuu, mutta ei enää vaikuta asiakkaidemme työhön.
Yksi kentällä ei ole soturi
Tänään saimme tietää, että muut operaattorit ovat kohdanneet samanlaisen ongelman. Joku uskoo edelleen, että Microsoft teki joitain muutoksia etäkäyttöpalvelun koodiin (jos muistat, epäilimme samaa ensimmäisenä päivänä, mutta hylkäsimme tämän version hyvin nopeasti) ja lupaa tehdä kaikkensa löytääksemme ratkaisun nopeasti . Jotkut ihmiset yksinkertaisesti jättävät huomioimatta ongelman ja neuvovat asiakkaita suojaamaan itseään (vaihtamaan yhteysporttia, piilottamaan palvelimen yksityiseen verkkoon ja niin edelleen). Ja aivan ensimmäisenä päivänä emme vain ratkaisseet tätä ongelmaa, vaan loimme myös pohjaa globaalimmalle uhkien havaitsemisjärjestelmälle, jota aiomme kehittää.
Erityiset kiitokset asiakkaille ja yhteistyökumppaneille, jotka eivät pysyneet hiljaa eivätkä istuneet joen rannalla odottamassa vihollisen ruumista jonakin päivänä kelluvan sitä pitkin, vaan kiinnittivät heti huomiomme ongelmaan, mikä antoi meille mahdollisuuden eliminoida se samana päivänä.
Lähde: will.com