Räägime teile laheda loo sellest, kuidas "kolmandad osapooled" üritasid meie klientide tööd segada ja kuidas see probleem lahenes.
Kuidas see kõik algas
Kõik sai alguse 31. oktoobri hommikul, kuu viimasel päeval, mil paljud vajavad hädasti aega pakiliste ja oluliste küsimuste lahendamiseks.
Üks partneritest, kes hoiab meie pilves mitut tema teenindatavate klientide virtuaalmasinaid, teatas, et kella 9–10 ei aktsepteerinud mitu meie Ukraina saidil töötavat Windowsi serverit kaugjuurdepääsuteenusega ühendusi, kasutajad ei saanud oma töölaudadesse sisse logida, kuid mõne minuti pärast näis probleem lahenevat iseenesest.
Tõstasime sidekanalite toimimise statistikat, kuid liiklushoogusid ega rikkeid ei leidnud. Vaatasime arvutusressursside koormuse statistikat – anomaaliaid pole. Ja mis see oli?
Siis teatas teine partner, kes majutab meie pilves veel umbes sadat serverit, samadest probleemidest, mida märkisid ka mõned nende kliendid, ning selgus, et üldiselt on serverid ligipääsetavad (vastab korralikult pingi testile ja muudele päringutele), kuid teenuste kaugjuurdepääs nendel serveritel kas võtab vastu uusi ühendusi või lükkab need tagasi ning jutt oli erinevatel saitidel asuvatest serveritest, mille liiklus tuleb erinevatest andmeedastuskanalitest.
Vaatame seda liiklust. Ühendustaotlusega pakett saabub serverisse:
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
Server võtab selle paketi vastu, kuid lükkab ühenduse tagasi:
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
See tähendab, et probleem ei ole ilmselgelt põhjustatud mitte mingitest probleemidest infrastruktuuri toimimises, vaid millestki muust. Võib-olla on kõigil kasutajatel probleeme kaugtöölaua litsentsimisega? Võib-olla õnnestus mingi pahavara nende süsteemidesse tungida ja täna see aktiveeriti, nagu paar aastat tagasi XData и Petja?
Seda sorteerimise ajal saime sarnaseid soove veel mitmelt kliendilt ja partnerilt.
Mis nendes masinates tegelikult toimub?
Sündmuste logid on täis sõnumeid parooli äraarvamise katsete kohta:
Tavaliselt registreeritakse sellised katsed kõigis serverites, kus kaugjuurdepääsuteenuse jaoks kasutatakse standardset porti (3389) ja juurdepääs on lubatud kõikjalt. Internet on täis roboteid, mis skannivad pidevalt kõiki saadaolevaid ühenduspunkte ja üritavad parooli ära arvata (sellepärast soovitame tungivalt kasutada keerulisi paroole “123” asemel). Nende katsete intensiivsus oli tol päeval aga liiga kõrge.
Mida teha?
Kas soovitate klientidel kulutada palju aega seadete muutmisele, et paljud lõppkasutajad saaksid teisele pordile lülituda? Pole hea mõte, kliendid ei jää rahule. Kas soovitate lubada juurdepääsu ainult VPN-i kaudu? Kiirustades ja paanikas IPSec-ühenduste tõstmine neile, kel neid kasvatada pole - ehk ei naerata selline õnn ka klientidele. Kuigi pean ütlema, et see on igal juhul jumalakartlik asi, soovitame alati serveri privaatvõrku peita ja oleme valmis seadistustega abistama ning neile, kellele meeldib see ise välja mõelda, jagame juhiseid IPSec/L2TP seadistamiseks meie pilves saidipõhises või maanteerežiimis – sõdalane ja kui keegi soovib oma Windowsi serveris VPN-teenust seadistada, on ta alati valmis jagama näpunäiteid, kuidas seadistada standardne RAS või OpenVPN. Kuid hoolimata sellest, kui lahedad me olime, ei olnud see parim aeg klientide seas hariva töö tegemiseks, kuna meil oli vaja probleem võimalikult kiiresti lahendada, tekitades kasutajatele minimaalse stressi.
Meie rakendatud lahendus oli järgmine. Oleme seadistanud läbiva liikluse analüüsi selliselt, et jälgida kõiki katseid luua TCP-ühendus pordiga 3389 ja valida sealt aadressid, mis 150 sekundi jooksul üritavad luua ühendust enam kui 16 erineva meie võrgu serveriga. - need on rünnaku allikad ( Muidugi, kui ühel klientidest või partneritest on reaalne vajadus luua ühendusi nii paljude samast allikast pärit serveritega, saate sellised allikad alati "valgesse nimekirja" lisada. kui ühes C-klassi võrgus tuvastatakse nende 150 sekundi jooksul rohkem kui 32 aadressi, on mõttekas blokeerida kogu võrk. Blokeerimine määratakse 3 päevaks ja kui selle aja jooksul antud allikast rünnakuid ei sooritatud, see allikas eemaldatakse automaatselt "mustast nimekirjast". Blokeeritud allikate loendit uuendatakse iga 300 sekundi järel.
See nimekiri on saadaval järgmisel aadressil: , saate selle põhjal luua oma ACL-id.
Oleme valmis jagama sellise süsteemi lähtekoodi, selles pole midagi üleliia keerulist (need on mitmed lihtsad skriptid, mis on koostatud sõna otseses mõttes paari tunniga) ning samas saab seda kohandada ja mitte kasutada. ainult selleks, et kaitsta sellise rünnaku eest, aga ka tuvastada ja blokeerida kõik võrgu skannimiskatsed:
Lisaks oleme teinud mõningaid muudatusi seiresüsteemi seadistustes, mis nüüd jälgib täpsemalt meie pilves olevate virtuaalserverite kontrollrühma reaktsiooni katsele luua RDP-ühendus: kui reaktsioon ei järgne teiseks on see põhjus tähelepanu pöörata.
Lahendus osutus üsna tõhusaks: enam ei ole kaebusi nii klientidelt, partneritelt kui ka monitooringusüsteemilt. Musta nimekirja lisatakse regulaarselt uusi aadresse ja terveid võrke, mis näitab, et rünnak jätkub, kuid ei mõjuta enam meie klientide tööd.
Turvalisus peitub numbrites
Täna saime teada, et sarnase probleemiga on kokku puutunud ka teised operaatorid. Keegi usub endiselt, et Microsoft tegi kaugjuurdepääsuteenuse koodis mõningaid muudatusi (kui mäletate, kahtlustasime juba esimesel päeval sama asja, kuid lükkasime selle versiooni väga kiiresti tagasi) ja lubab teha kõik võimaliku, et kiiresti lahendus leida . Mõned inimesed lihtsalt ignoreerivad probleemi ja soovitavad klientidel end ise kaitsta (muuta ühendusporti, peita server privaatvõrku jne). Ja kohe esimesel päeval me mitte ainult ei lahendanud seda probleemi, vaid lõime ka aluse globaalsemale ohutuvastussüsteemile, mida plaanime edasi arendada.
Erilised tänud klientidele ja koostööpartneritele, kes ei vaikinud ega istunud jõe kaldal ega oodanud, et vaenlase surnukeha ühel päeval mööda seda hõljuks, vaid juhtisid kohe meie tähelepanu probleemile, mis andis võimaluse kõrvaldada. seda samal päeval.
Allikas: www.habr.com