Konta dezagun istorio polit bat nola "hirugarrenek" gure bezeroen lana oztopatzen saiatu ziren eta arazo hau nola konpondu zen.
Nola hasi zen dena
Urriaren 31ko goizean hasi zen dena, hileko azken egunean, askok premiazko eta garrantzitsuak diren gaiak konpontzeko denbora izan behar baitute.
Gure hodeian zerbitzatzen dituen bezeroen hainbat makina birtual gordetzen dituen bazkideetako batek jakinarazi zuen 9:10etik 9:20era gure Ukrainako gunean exekutatzen ari diren Windows zerbitzariek ez zutela urruneko sarbide zerbitzurako konexiorik onartzen, erabiltzaileek ezin izan zutela. beren mahaigainetan saioa hasteko, baina minutu gutxiren buruan arazoa konpontzen zela zirudien.
Komunikazio kanalen funtzionamenduari buruzko estatistikak planteatu ditugu, baina ez dugu trafiko gorakada edo hutsegiterik aurkitu. Baliabide informatikoen kargari buruzko estatistikak aztertu ditugu, anomaliarik ez. Eta zer zen hori?
Orduan, beste bazkide batek, gure hodeian ehun bat zerbitzari gehiago hartzen dituenak, bezero batzuek adierazitako arazo berberen berri eman zuen, eta zerbitzariak orokorrean eskuragarriak zirela ikusi zen (ping probari eta beste eskaerei behar bezala erantzuten zietela), baina zerbitzari horietan urruneko sarbideak konexio berriak onartzen ditu edo baztertzen ditu, eta gune ezberdinetako zerbitzariez ari ginen, trafiko hori datu-transmisio-kanal ezberdinetatik datorrena.
Ikus dezagun trafiko hau. Konexio-eskaera duen pakete bat iristen da zerbitzarira:
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
Zerbitzariak pakete hau jasotzen du, baina konexioa baztertzen du:
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
Horrek esan nahi du arazoa, argi eta garbi, ez dela azpiegituraren funtzionamenduko arazorik sortzen, beste zerbaitek baizik. Agian erabiltzaile guztiek arazoak dituzte urruneko mahaigaineko lizentziarekin? Agian malware motaren batek haien sistemetan sartzea lortu zuen, eta gaur aktibatu egin da, duela pare bat urte bezala. XData ΠΈ Petya?
Konpontzen ari ginen bitartean, hainbat bezero eta bazkide gehiagoren antzeko eskaerak jaso genituen.
Zer gertatzen da benetan makina hauetan?
Gertaeren erregistroak pasahitza asmatzeko saiakerei buruzko mezuz beteta daude:
Normalean, horrelako saiakerak zerbitzari guztietan erregistratzen dira, non ataka estandarra (3389) erabiltzen den urruneko sarbide-zerbitzurako eta sarbidea edonondik baimentzen den. Internet eskuragarri dauden konexio-puntu guztiak etengabe miatu eta pasahitza asmatzen saiatzen diren botz beteta dago (horregatik gomendatzen dugu "123"-ren ordez pasahitz konplexuak erabiltzea). Hala ere, saiakera horien intentsitatea handiegia zen egun hartan.
Zer egin behar dut?
Gomendatzen al duzu bezeroek denbora asko igarotzea azken erabiltzaile kopuru handi baten ezarpenak aldatzen beste portu batera aldatzeko? Ez da ideia ona, bezeroak ez dira pozik egongo. Gomendatzen al duzu sarbidea VPN bidez soilik baimentzea? Presaka eta izua, IPSec konexioak planteatu ez dituztenentzat - agian zoriontasun horrek ez die irribarre egiten bezeroei ere. Nahiz eta, esan beharra daukat, gauza jainkotiarra den edozein kasutan, zerbitzaria sare pribatu batean ezkutatzea gomendatzen dugu beti eta ezarpenetan laguntzeko prest gaude, eta bere kabuz asmatu nahi dutenentzat, argibideak partekatzen ditugu. IPSec/L2TP gure hodeian gunez gune edo errepide moduan konfiguratzeko - warrior, eta edonork VPN zerbitzu bat konfiguratu nahi badu bere Windows zerbitzarian, beti prest dago konfiguratzeko aholkuak partekatzeko. RAS edo OpenVPN estandarra. Baina, ez du axola nola politak ginen, ez zen momenturik onena bezeroen artean hezkuntza-lana egiteko, arazoa ahalik eta azkarren konpondu behar baikenuen erabiltzaileentzako estres minimoarekin.
Inplementatu genuen irtenbidea honakoa izan zen. Pasabideko trafikoaren analisia ezarri dugu, 3389 atakan TCP konexioa ezartzeko saiakera guztiak kontrolatzeko eta 150 segundoko epean gure sareko 16 zerbitzari ezberdin baino gehiagorekin konexioak ezartzen saiatzen diren helbideak hautatzeko. - hauek dira erasoaren iturriak ( Noski, bezero edo bazkideren batek iturri bereko hainbeste zerbitzariekin konexioak ezartzeko benetako beharra badu, beti gehi ditzakezu iturri horiek "zerrenda zurian". Gainera, 150 segundo horietan C klaseko sare batean 32 helbide baino gehiago identifikatzen badira, zentzuzkoa da sare osoa blokeatzea.Blokeoa 3 egunetarako ezartzen da, eta denbora horretan iturri jakin batetik erasorik egin ez bada. iturri hau automatikoki kentzen da "zerrenda beltzetik". Blokeatutako iturrien zerrenda 300 segundoz behin eguneratzen da.
Zerrenda hau helbide honetan dago eskuragarri: , zure ACLak eraiki ditzakezu bertan oinarrituta.
Prest gaude sistema horren iturburu-kodea partekatzeko; ez dago ezer konplexuegirik (hauek, literalki, ordu pare batean bildutako hainbat script soil dira), eta, aldi berean, egokitu daiteke eta ez erabil daiteke. eraso horietatik babesteko soilik, baina baita sarea eskaneatzeko saiakerak detektatzeko eta blokeatzeko ere:
Horrez gain, jarraipen-sistemaren ezarpenetan aldaketa batzuk egin ditugu, zeinak orain hurbilagotik kontrolatzen baitu gure hodeian zerbitzari birtualen kontrol-talde baten erreakzioa RDP konexioa ezartzeko saiakeraren aurrean: erreakzioa ez bada jarraitzen. bigarrena, hau arreta jartzeko arrazoia da.
Irtenbidea nahiko eraginkorra izan zen: ez dago bezeroen eta bazkideen kexa gehiago, eta jarraipen sistemaren aldetik. Helbide berriak eta sare osoak zerrenda beltzean gehitzen dira aldian-aldian, eta horrek adierazten du erasoak jarraitzen duela, baina jada ez duela gure bezeroen lana eragiten.
Zenbakietan segurtasuna dago
Gaur jakin dugu beste operadore batzuek antzeko arazo batekin topo egin dutela. Norbaitek oraindik uste du Microsoft-ek aldaketa batzuk egin zituela urruneko sarbide-zerbitzuaren kodean (gogoratzen bazara, gauza bera susmatu genuen lehen egunean, baina oso azkar baztertu genuen bertsio hau) eta konponbide bat azkar aurkitzeko ahal den guztia egingo duela agintzen du. . Batzuek arazoa alde batera uzten dute eta bezeroei beren kabuz babesteko gomendatzen diete (konexio ataka aldatu, zerbitzaria sare pribatu batean ezkutatu eta abar). Eta lehenengo egunean, arazo hau konpondu ez ezik, garatzeko asmoa dugun mehatxuak detektatzeko sistema globalago baterako oinarri batzuk ere sortu genituen.
Esker bereziak bezeroei eta bazkideei, isildu ez eta ibaiertzean eserita egon ez ziren etsaien gorpua egunen batean bertan flotatzeko zain, baina berehala atentzioa erakarri ziguten arazoari, eta horrek ezabatzeko aukera eman zigun. egun berean.
Iturria: www.habr.com