Vi vil fortælle en interessant historie om, hvordan "tredjepart" forsøgte at forstyrre arbejdet for vores kunder, og hvordan dette problem blev løst.
Hvordan det hele begyndte
Det hele startede om morgenen den 31. oktober, den sidste dag i måneden, hvor mange absolut var nødt til at få lukket akutte og vigtige sager.
En af vores partnere, som har flere virtuelle maskiner for sine kunder i vores cloud, rapporterede, at fra kl. 9:10 til 9:20 kunne flere Windows-servere, der kørte på vores ukrainske lokation, ikke acceptere forbindelser til fjernadgangstjenesten, og brugerne kunne ikke logge ind på deres skriveborde, men efter et par minutter synes problemet at være blevet løst af sig selv.
Vi tjekkede statistikken for kommunikationskanalerne, men fandt hverken trafikspidser eller nedbrud. Vi kiggede på belastningsstatistikken for computere - ingen anomalier. Hvad kunne dette være?
Derefter rapporterede endnu en partner, som har næsten hundrede servere i vores cloud, om de samme problemer, som nogle af deres kunder havde bemærket. Det viste sig, at serverne generelt var tilgængelige (de svarede korrekt på ping-tests og andre anmodninger), men fjernadgangstjenesten på disse servere accepterede ind imellem nye forbindelser og afviste dem på andre tidspunkter, og det drejede sig om servere på forskellige lokationer, hvor trafikken kom fra forskellige dataoverførselskanaler.
Lad os tage et kig på denne trafik. En pakke med en anmodning om etablering af forbindelse 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 åbenbart ikke skyldes problemer i infrastrukturen, men noget andet. Måske har alle brugere problemer med licensering af fjernarbejdsstationer? Måske er der trængt skadelig software ind i deres systemer, og i dag er det blevet aktiveret, som det var for et par år siden med XData og Petya?
Mens vi undersøgte dette, modtog vi lignende henvendelser fra flere andre kunder og partnere.
Hvad sker der egentlig på disse maskiner?
I logfilerne er der mange meddelelser om forsøg på at knække adgangskoden:
Normalt registreres sådanne forsøg på alle servere, hvor standardporten (3389) anvendes til fjernadgangstjenesten, og hvor adgang fra alle steder er tilladt. Internettet er fyldt med bots, der konstant scanner alle tilgængelige tilslutningspunkter og forsøger at gætte adgangskoder (netop af denne grund anbefaler vi kraftigt at bruge komplekse adgangskoder i stedet for '123'). Ikke desto mindre var intensiteten af disse forsøg den dag alt for høj.
Hvad skal man gøre?
Er det en god idé at anbefale kunderne at bruge en masse tid på at ændre indstillingerne for et stort antal slutbrugere for at skifte til en anden port? Det er ikke særlig godt, kunderne bliver ikke glade. Anbefale at give adgang kun via VPN? At hastigt og panisk etablere IPSec-forbindelser for dem, der ikke har dem oprettet, vil nok heller ikke gøre kunderne glade. Selvom det skal siges, at det i hvert fald er en god gerning, anbefaler vi altid at skjule serveren i et privat netværk og er klar til at hjælpe med indstillingerne, og for dem der ønsker at finde ud af det selv, deler vi instruktioner til opsætning af IPSec/L2TP i vores cloud i site-to-site eller road-warrior tilstand, og hvis nogen ønsker at oprette en VPN-tjeneste på deres egen Windows-server - er vi altid klar til at dele tips til, hvordan man opsætter standard RAS eller OpenVPN. Men uanset hvor skønne vi end måtte være, var det ikke det bedste tidspunkt til at lave oplysende arbejde blandt kunderne, da problemet skulle løses så hurtigt som muligt med minimal belastning for brugerne.
Løsningen, vi implementerede, gik ud på følgende. Vi etablerede en analyse af den indkommende trafik for at spore alle forsøg på at oprette en TCP-forbindelse til port 3389 og udtrække adresser, der inden for 150 sekunder forsøger at oprette forbindelser til mere end 16 forskellige servere i vores netværk. Disse er angrebskilderne (selvfølgelig, hvis nogen af vores kunder eller partnere har et reelt behov for at etablere forbindelser til så mange servere fra én enkelt kilde, kan sådanne kilder altid tilføjes til 'whitelist'. Hvis der inden for disse 150 sekunder identificeres mere end 32 adresser i et C-klasse netværk, er det fornuftigt at blokere hele netværket. Blokaden sættes i 3 dage, og hvis der ikke er blevet udført angreb fra denne kilde i løbet af denne tid, fjernes kilden automatisk fra 'blacklisten'. Listen over blokerede kilder opdateres hver 300 sekund.
Denne liste er tilgængelig på følgende adresse: , du kan opbygge dine egne ACL'er på grundlag af den.
Vi er villige til at dele kildekoden til et sådan system; der er ikke noget særligt kompliceret ved det (det består af et par simple scripts, der blev sammensat på blot et par timer 'i en fart'), og det kan tilpasses og bruges ikke kun til at beskytte mod sådanne angreb, men også til at opdage og blokere enhver forsøg på netværksscanning:
Derudover har vi foretaget nogle ændringer i indstillingerne for overvågningssystemet, som nu mere nøje overvåger reaktionen fra kontrolgruppen af virtuelle servere i vores cloud på forsøg på at etablere en RDP-forbindelse: hvis reaktionen ikke følger i løbet af et sekund, er det en grund til at være opmærksom.
Løsningen viste sig at være ret effektiv: der er ikke længere klager fra hverken kunder eller partnere samt overvågningssystemet. Nye adresser og hele netværk bliver regelmæssigt tilføjet til 'blacklisten', hvilket indikerer, at angrebet fortsætter, men ikke længere påvirker vores kunders drift.
En alene gør ikke krig.
I dag har vi erfaret, at andre operatører også har stået over for et lignende problem. Nogle mener stadig, at Microsoft har foretaget ændringer i koden til fjernadgangstjenesten (hvis I kan huske, så mistænkte vi det samme den første dag, men vi afviste hurtigt denne teori) og lover at gøre alt, hvad der er muligt for hurtigt at finde en løsning. Nogle ignorerer blot problemet og anbefaler kunderne at beskytte sig selv (ændre forbindelsesport, skjule serveren i et privat netværk osv.). Men allerede den første dag løste vi ikke bare dette problem, men skabte også et grundlag for et mere globalt trusselsdetekteringssystem, som vi planlægger at udvikle.
En særlig tak til kunder og partnere, der ikke var stille og ikke sad på stranden og ventede på, at liget af fjenden skulle flyde forbi, men straks gjorde os opmærksomme på problemet, hvilket gav os mulighed for at løse det samme dag.
Kilde: habr.com
