Lad os fortælle dig en cool historie om, hvordan "tredjeparter" forsøgte at blande sig i vores kunders arbejde, og hvordan dette problem blev løst.
Hvordan det hele startede
Det hele startede om morgenen den 31. oktober, den sidste dag i måneden, hvor mange desperat har brug for at have tid til at løse akutte og vigtige spørgsmål.
En af partnerne, som har adskillige virtuelle maskiner for de klienter, han betjener i vores sky, rapporterede, at fra 9:10 til 9:20 adskillige Windows-servere, der kørte på vores ukrainske websted, ikke accepterede forbindelser til fjernadgangstjenesten, brugere var ude af stand til at logge ind på deres desktops, men efter et par minutter så problemet ud til at løse sig selv.
Vi hævede statistikken over driften af kommunikationskanaler, men fandt ingen trafikstigninger eller fejl. Vi så på statistikken over belastningen af computerressourcer - ingen uregelmæssigheder. Og hvad var det?
Så rapporterede en anden partner, som er vært for omkring hundrede flere servere i vores sky, de samme problemer, som nogle af deres klienter bemærkede, og det viste sig, at serverne generelt var tilgængelige (svarede korrekt på ping-testen og andre anmodninger), men tjenesten fjernadgang på disse servere accepterer enten nye forbindelser eller afviser dem, og vi talte om servere på forskellige websteder, hvor trafikken kommer fra forskellige datatransmissionskanaler.
Lad os se på denne trafik. En pakke med en forbindelsesanmodning ankommer til serveren:
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
Serveren modtager denne pakke, men afviser forbindelsen:
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
Det betyder, at problemet tydeligvis ikke er forårsaget af problemer i driften af infrastrukturen, men af noget andet. Måske har alle brugere problemer med fjernskrivebordslicenser? Måske lykkedes det en eller anden form for malware at trænge ind i deres systemer, og i dag blev den aktiveret, som den var med for et par år siden XData и Petya?
Mens vi ordnede det, modtog vi lignende anmodninger fra flere kunder og partnere.
Hvad sker der egentlig på disse maskiner?
Hændelsesloggene er fulde af beskeder om forsøg på at gætte adgangskoden:
Typisk registreres sådanne forsøg på alle servere, hvor standardporten (3389) bruges til fjernadgangstjenesten, og adgang er tilladt overalt. Internettet er fyldt med bots, der konstant scanner alle tilgængelige forbindelsespunkter og forsøger at gætte adgangskoden (det er derfor, vi anbefaler kraftigt at bruge komplekse adgangskoder i stedet for "123"). Imidlertid var intensiteten af disse forsøg den dag for høj.
Hvad skal jeg gøre?
Vil du anbefale, at kunder bruger meget tid på at ændre indstillinger, så et stort antal slutbrugere skifter til en anden port? Ikke en god idé, kunder vil ikke være glade. Vil du anbefale kun at tillade adgang via VPN? I en fart og panik, hæve IPSec-forbindelser for dem, der ikke har dem hævet - måske smiler sådan en lykke heller ikke til klienterne. Selvom, jeg må sige, det er en gudfrygtig ting under alle omstændigheder, anbefaler vi altid at skjule serveren i et privat netværk og er klar til at hjælpe med indstillingerne, og for dem, der kan lide at finde ud af det på egen hånd, deler vi instruktioner til opsætning af IPSec/L2TP i vores sky i site-to-site eller road mode -warrior, og hvis nogen ønsker at opsætte en VPN-tjeneste på deres egen Windows-server, er vi altid klar til at dele tips til, hvordan man opsætter en standard RAS eller OpenVPN. Men uanset hvor seje vi var, var dette ikke det bedste tidspunkt at udføre pædagogisk arbejde blandt kunderne, da vi skulle løse problemet så hurtigt som muligt med minimal stress for brugerne.
Løsningen vi implementerede var som følger. Vi har opsat en analyse af forbipasserende trafik på en sådan måde, at vi overvåger alle forsøg på at etablere en TCP-forbindelse til port 3389 og udvælger adresser fra den, der inden for 150 sekunder forsøger at etablere forbindelser med mere end 16 forskellige servere på vores netværk - disse er kilderne til angrebet (Selvfølgelig, hvis en af klienterne eller partnerne har et reelt behov for at etablere forbindelser med så mange servere fra den samme kilde, kan du altid tilføje sådanne kilder til den "hvide liste." Desuden, hvis der i et klasse C-netværk i disse 150 sekunder identificeres mere end 32 adresser, giver det mening at blokere hele netværket. Blokeringen er sat til 3 dage, og hvis der i løbet af denne tid ikke blev udført angreb fra en given kilde, denne kilde fjernes automatisk fra "den sorte liste". Listen over blokerede kilder opdateres hvert 300. sekund.
Denne liste er tilgængelig på denne adresse: , kan du bygge dine ACL'er baseret på det.
Vi er klar til at dele kildekoden til et sådant system; der er intet alt for komplekst i det (dette er flere simple scripts, der er kompileret på bogstaveligt talt et par timer på knæet), og samtidig kan det tilpasses og bruges ikke kun for at beskytte mod et sådant angreb, men også for at opdage og blokere ethvert forsøg på at scanne netværket:
Derudover har vi lavet nogle ændringer i indstillingerne af overvågningssystemet, som nu nøjere overvåger reaktionen fra en kontrolgruppe af virtuelle servere i vores sky på et forsøg på at etablere en RDP-forbindelse: hvis reaktionen ikke sker inden for en for det andet er dette en grund til at være opmærksom.
Løsningen viste sig at være ret effektiv: Der er ikke flere klager fra både kunder og partnere og fra overvågningssystemet. Nye adresser og hele netværk tilføjes jævnligt til sortlisten, hvilket indikerer, at angrebet fortsætter, men ikke længere påvirker vores klienters arbejde.
Der er sikkerhed i tal
I dag erfarede vi, at andre operatører er stødt på et lignende problem. Nogen mener stadig, at Microsoft har foretaget nogle ændringer i koden til fjernadgangstjenesten (hvis du husker, havde vi mistanke om det samme den første dag, men vi afviste meget hurtigt denne version) og lover at gøre alt for hurtigt at finde en løsning . Nogle mennesker ignorerer simpelthen problemet og råder klienter til at beskytte sig selv (ændre forbindelsesporten, skjul serveren i et privat netværk og så videre). Og på den allerførste dag løste vi ikke kun dette problem, men skabte også noget grundlag for et mere globalt trusselsdetektionssystem, som vi planlægger at udvikle.
Særlig tak til kunderne og partnerne, som ikke forblev stille og ikke sad på flodbredden og ventede på, at liget af en fjende skulle flyde langs den en dag, men straks henledte vores opmærksomhed på problemet, hvilket gav os muligheden for at eliminere det samme dag.
Kilde: www.habr.com