La oss fortelle deg en kul historie om hvordan "tredjeparter" prøvde å forstyrre arbeidet til våre klienter, og hvordan dette problemet ble løst.
Hvordan det hele startet
Det hele startet om morgenen 31. oktober, den siste dagen i måneden, da mange sårt trenger å ha tid til å løse presserende og viktige saker.
En av partnerne, som holder flere virtuelle maskiner til klientene han betjener i skyen vår, rapporterte at fra 9:10 til 9:20 flere Windows-servere som kjørte på vår ukrainske side ikke godtok tilkoblinger til fjerntilgangstjenesten , brukere var ikke i stand til for å logge på skrivebordet, men etter noen minutter så problemet ut til å løse seg selv.
Vi hevet statistikken over drift av kommunikasjonskanaler, men fant ingen trafikkøkninger eller feil. Vi så på statistikken over belastningen på dataressurser – ingen avvik. Og hva var det?
Så rapporterte en annen partner, som er vert for omtrent hundre flere servere i skyen vår, de samme problemene som noen av klientene deres noterte, og det viste seg at serverne generelt var tilgjengelige (svarte riktig på ping-testen og andre forespørsler), men Tjenesten fjerntilgang på disse serverne aksepterer enten nye tilkoblinger eller avviser dem, og vi snakket om servere på forskjellige nettsteder, hvor trafikken kommer fra forskjellige dataoverføringskanaler.
La oss se på denne trafikken. En pakke med en tilkoblingsforespørsel kommer 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 mottar denne pakken, men avviser tilkoblingen:
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
Dette betyr at problemet tydeligvis ikke er forårsaket av problemer i driften av infrastrukturen, men av noe annet. Kanskje alle brukere har problemer med lisensiering av eksternt skrivebord? Kanskje en eller annen form for malware klarte å trenge inn i systemene deres, og i dag ble den aktivert, slik den var for et par år siden XData и Petya?
Mens vi ordnet opp, mottok vi lignende forespørsler fra flere kunder og partnere.
Hva skjer egentlig på disse maskinene?
Hendelsesloggene er fulle av meldinger om forsøk på å gjette passordet:
Vanligvis blir slike forsøk registrert på alle servere der standardporten (3389) brukes for fjerntilgangstjenesten og tilgang er tillatt fra alle steder. Internett er fullt av roboter som hele tiden skanner alle tilgjengelige tilkoblingspunkter og prøver å gjette passordet (det er derfor vi anbefaler på det sterkeste å bruke komplekse passord i stedet for "123"). Intensiteten på disse forsøkene den dagen var imidlertid for høy.
Hva skal jeg gjøre?
Vil du anbefale at kunder bruker mye tid på å endre innstillinger for at et stort antall sluttbrukere skal bytte til en annen port? Ikke en god idé, kundene vil ikke være fornøyde. Anbefale å tillate tilgang kun via VPN? I en hast og panikk, heve IPSec-forbindelser for de som ikke har dem hevet - kanskje en slik lykke smiler ikke til klientene heller. Selv om, jeg må si, dette er en gudfryktig ting i alle fall, anbefaler vi alltid å skjule serveren i et privat nettverk og er klare til å hjelpe med innstillingene, og for de som liker å finne ut av det på egen hånd, deler vi instruksjoner for å sette opp IPSec/L2TP i nettskyen vår i sted-til-sted eller veimodus -warrior, og hvis noen ønsker å sette opp en VPN-tjeneste på sin egen Windows-server, er de alltid klare til å dele tips om hvordan man setter opp en standard RAS eller OpenVPN. Men uansett hvor kule vi var, var ikke dette den beste tiden å drive pedagogisk arbeid blant klienter, siden vi trengte å fikse problemet så raskt som mulig med minimalt stress for brukerne.
Løsningen vi implementerte var som følger. Vi har satt opp en analyse av passerende trafikk på en slik måte at vi overvåker alle forsøk på å etablere en TCP-forbindelse til port 3389 og velger fra den adresser som innen 150 sekunder forsøker å etablere forbindelser med mer enn 16 forskjellige servere på nettverket vårt. - Dette er kildene til angrepet (Selvfølgelig, hvis en av klientene eller partnerne har et reelt behov for å etablere forbindelser med så mange servere fra samme kilde, kan du alltid legge til slike kilder til "hvitelisten." Dessuten, hvis det i ett klasse C-nettverk i disse 150 sekundene identifiseres mer enn 32 adresser, er det fornuftig å blokkere hele nettverket. Blokkeringen er satt til 3 dager, og hvis det i løpet av denne tiden ikke ble utført angrep fra en gitt kilde, denne kilden fjernes automatisk fra "svartelisten." Listen over blokkerte kilder oppdateres hvert 300. sekund.
Denne listen er tilgjengelig på denne adressen: , kan du bygge tilgangskontrollistene dine basert på den.
Vi er klare til å dele kildekoden til et slikt system; det er ikke noe altfor komplisert i det (dette er flere enkle skript kompilert på bokstavelig talt et par timer på kneet), og samtidig kan det tilpasses og ikke brukes bare for å beskytte mot et slikt angrep, men også for å oppdage og blokkere alle forsøk på å skanne nettverket:
I tillegg har vi gjort noen endringer i innstillingene til overvåkingssystemet, som nå overvåker reaksjonen til en kontrollgruppe av virtuelle servere i skyen vår på et forsøk på å etablere en RDP-forbindelse: hvis reaksjonen ikke følger innen en For det andre er dette en grunn til å være oppmerksom.
Løsningen viste seg å være ganske effektiv: det er ikke flere klager fra både kunder og partnere, og fra overvåkingssystemet. Nye adresser og hele nettverk legges jevnlig til svartelisten, noe som indikerer at angrepet fortsetter, men ikke lenger påvirker arbeidet til våre klienter.
Det er sikkerhet i tall
I dag fikk vi vite at andre operatører har støtt på et lignende problem. Noen tror fortsatt at Microsoft gjorde noen endringer i koden til fjerntilgangstjenesten (hvis du husker, mistenkte vi det samme den første dagen, men vi avviste denne versjonen veldig raskt) og lover å gjøre alt for å finne en løsning raskt . Noen mennesker ignorerer ganske enkelt problemet og råder klienter til å beskytte seg selv (endre tilkoblingsporten, gjemme serveren i et privat nettverk, og så videre). Og allerede den første dagen løste vi ikke bare dette problemet, men skapte også et grunnlag for et mer globalt trusseldeteksjonssystem som vi planlegger å utvikle.
Spesiell takk til klientene og partnerne som ikke forble stille og ikke satt på elvebredden og ventet på at liket av en fiende skulle flyte langs den en dag, men umiddelbart trakk vår oppmerksomhet til problemet, som ga oss muligheten til å eliminere det samme dag.
Kilde: www.habr.com