Jeg har ofte lest oppfatningen om at det å holde en RDP-port (Remote Desktop Protocol) åpen til Internett er veldig utrygt og bør ikke gjøres. Men du må gi tilgang til RDP enten gjennom en VPN, eller bare fra visse "hvite" IP-adresser.
Jeg administrerer flere Windows-servere for små firmaer der jeg har fått i oppgave å gi ekstern tilgang til Windows Server for regnskapsførere. Dette er den moderne trenden - å jobbe hjemmefra. Ganske raskt innså jeg at det å plage VPN-regnskapsførere er en utakknemlig oppgave, og å samle alle IP-ene til hvitelisten vil ikke fungere, fordi folks IP-adresser er dynamiske.
Derfor tok jeg den enkleste ruten - videresendte RDP-porten til utsiden. For å få tilgang, må regnskapsførere nå kjøre RDP og skrive inn vertsnavnet (inkludert port), brukernavn og passord.
I denne artikkelen vil jeg dele mine erfaringer (positive og ikke så positive) og anbefalinger.
Risiko
Hva risikerer du ved å åpne RDP-porten?
1) Uautorisert tilgang til sensitive data
Hvis noen gjetter RDP-passordet, vil de kunne få data som du vil holde privat: kontostatus, saldoer, kundedata, ...
2) Datatap
For eksempel som følge av et løsepengevirus.
Eller en bevisst handling fra en angriper.
3) Tap av arbeidsstasjon
Arbeidere må jobbe, men systemet er kompromittert og må installeres/gjenopprettes/konfigureres på nytt.
4) Kompromittering av det lokale nettverket
Hvis en angriper har fått tilgang til en Windows-datamaskin, vil han fra denne datamaskinen kunne få tilgang til systemer som er utilgjengelige fra utsiden, fra Internett. For eksempel til fildelinger, til nettverksskrivere, etc.
Jeg hadde et tilfelle der Windows Server fanget en løsepengevare
og denne løsepengevaren krypterte først de fleste filene på C:-stasjonen og begynte deretter å kryptere filene på NAS-en over nettverket. Siden NAS-en var Synology, med øyeblikksbilder konfigurert, gjenopprettet jeg NAS-en på 5 minutter, og installerte Windows Server på nytt fra bunnen av.
Observasjoner og anbefalinger
Jeg overvåker Windows-servere ved hjelp av , som sender logger til ElasticSearch. Kibana har flere visualiseringer, og jeg setter også opp et tilpasset dashbord.
Overvåking i seg selv beskytter ikke, men det hjelper med å bestemme nødvendige tiltak.
Her er noen observasjoner:
a) RDP vil bli brutalt tvunget.
På en av serverne installerte jeg RDP ikke på standardporten 3389, men på 443 - vel, jeg vil forkle meg som HTTPS. Det er nok verdt å endre porten fra standarden, men det hjelper ikke mye. Her er statistikken fra denne serveren:
Det kan sees at det i løpet av en uke var nesten 400 000 mislykkede forsøk på å logge inn via RDP.
Det kan ses at det var forsøk på å logge inn fra 55 001 IP-adresser (noen IP-adresser var allerede blokkert av meg).
Dette antyder direkte konklusjonen om at du må sette fail2ban, men
Det er ikke noe slikt verktøy for Windows.
Det er et par forlatte prosjekter på Github som ser ut til å gjøre dette, men jeg har ikke engang prøvd å installere dem:
Det er også betalte verktøy, men jeg har ikke vurdert dem.
Hvis du kjenner et åpen kildekode-verktøy for dette formålet, vennligst del det i kommentarene.
Oppdater: Kommentarene antydet at port 443 er et dårlig valg, og det er bedre å velge høye porter (32000+), fordi 443 skannes oftere, og det er ikke noe problem å gjenkjenne RDP på denne porten.
b) Det er visse brukernavn som angripere foretrekker
Det kan ses at søket utføres i en ordbok med forskjellige navn.
Men her er det jeg la merke til: et betydelig antall forsøk bruker servernavnet som pålogging. Anbefaling: Ikke bruk samme navn for datamaskinen og brukeren. Noen ganger ser det dessuten ut som om de prøver å analysere servernavnet på en eller annen måte: for eksempel, for et system med navnet DESKTOP-DFTHD7C, er de fleste forsøkene på å logge på med navnet DFTHD7C:
Følgelig, hvis du har en DESKTOP-MARIA-datamaskin, vil du sannsynligvis prøve å logge på som MARIA-bruker.
En annen ting jeg la merke til fra loggene: på de fleste systemer er de fleste forsøk på å logge på med navnet "administrator". Og dette er ikke uten grunn, for i mange versjoner av Windows eksisterer denne brukeren. Dessuten kan den ikke slettes. Dette forenkler oppgaven for angripere: i stedet for å gjette et navn og passord, trenger du bare å gjette passordet.
Forresten, systemet som fanget løsepengevaren hadde brukeren Administrator og passordet Murmansk#9. Jeg er fortsatt ikke sikker på hvordan systemet ble hacket, fordi jeg begynte å overvåke like etter den hendelsen, men jeg tror det er sannsynlig at det er overdrevet.
Så hvis administratorbrukeren ikke kan slettes, hva bør du gjøre? Du kan gi det nytt navn!
Anbefalinger fra dette avsnittet:
- ikke bruk brukernavnet i datamaskinnavnet
- sørg for at det ikke er noen administratorbruker på systemet
- bruke sterke passord
Så jeg har sett flere Windows-servere under min kontroll bli brute-forced i omtrent et par år nå, og uten hell.
Hvordan vet jeg at det ikke lykkes?
For i skjermbildene ovenfor kan du se at det er logger over vellykkede RDP-anrop, som inneholder informasjonen:
- fra hvilken IP
- fra hvilken datamaskin (vertsnavn)
- Brukernavn
- GeoIP informasjon
Og jeg sjekker der regelmessig - ingen anomalier er funnet.
Forresten, hvis en bestemt IP blir brutt-forced spesielt hardt, kan du blokkere individuelle IP-er (eller subnett) som dette i PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockElastic har forresten, i tillegg til Winlogbeat, også , som kan overvåke filer og prosesser på systemet. Det er også en SIEM-applikasjon (Security Information & Event Management) i Kibana. Jeg prøvde begge, men så ikke mye nytte - det ser ut til at Auditbeat vil være mer nyttig for Linux-systemer, og SIEM har ikke vist meg noe forståelig ennå.
Vel, endelige anbefalinger:
- Lag regelmessige automatiske sikkerhetskopier.
- installer sikkerhetsoppdateringer i tide
Bonus: liste over 50 brukere som oftest ble brukt til RDP-påloggingsforsøk
"bruker.navn: Synkende"
Telle
dfthd7c (vertsnavn)
842941
winsrv1 (vertsnavn)
266525
ADMINISTRATOR
180678
administrator
163842
administrator
53541
Michael
23101
server
21983
steve
21936
John
21927
paul
21913
mottak
21909
mike
21899
kontor
21888
skanner
21887
skanne
21867
david
21865
chris
21860
eieren
21855
leder
21852
administrateur
21841
brian
21839
administrator
21837
merke
21824
ansatte
21806
ADMIN
12748
ROOT
7772
ADMINISTRADØR
7325
SUPPORT
5577
STØTTE
5418
BRUKER
4558
admin
2832
TEST
1928
MySql
1664
admin
1652
GJEST
1322
BRUKER1
1179
SKANNER
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RESEPSJON
490
BRUKER2
466
TEMP
452
SQLADMIN
450
BRUKER3
441
1
422
SJEF
418
EIER
410
Kilde: www.habr.com